Partilhar via

Criar um cluster do Serviço Kubernetes do Azure com integração de VNet do Servidor de API (Visualização)

  • Artigo

Um cluster do Serviço Kubernetes do Azure (AKS) configurado com a Integração VNet do Servidor de API projeta o ponto de extremidade do servidor de API diretamente em uma sub-rede delegada na rede virtual onde o AKS é implantado. A integração de VNet do Servidor de API permite a comunicação de rede entre o servidor de API e os nós do cluster sem a necessidade de um link ou túnel privado. O servidor de API está disponível atrás de um VIP de balanceador de carga interno na sub-rede delegada, que os nós estão configurados para utilizar. Usando a Integração de VNet do Servidor de API, você pode garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça apenas na rede privada.

Conectividade do servidor de API

O plano de controle ou o servidor de API está em uma assinatura do Azure gerenciada pelo AKS. Seu cluster ou pool de nós está em sua assinatura do Azure. O servidor e as máquinas virtuais que compõem os nós do cluster podem se comunicar entre si por meio dos IPs VIP e pod do servidor de API projetados na sub-rede delegada.

A integração de VNet do API Server é suportada para clusters públicos ou privados. Você pode adicionar ou remover o acesso público após o provisionamento do cluster. Ao contrário dos clusters integrados não VNet, os nós do agente sempre se comunicam diretamente com o endereço IP privado do IP do ILB (balanceador de carga interno) do servidor de API sem usar DNS. Todo o tráfego de nó para servidor de API é mantido em rede privada e nenhum túnel é necessário para a conectividade do servidor de API para o nó. Os clientes fora do cluster que precisam se comunicar com o servidor de API podem fazê-lo normalmente se o acesso à rede pública estiver habilitado. Se o acesso à rede pública estiver desativado, você deverá seguir a mesma metodologia de configuração de DNS privado que os clusters privados padrão.

Disponibilidade da região

A Integração VNet do Servidor de API está disponível em todas as regiões globais do Azure.

Pré-requisitos

  • CLI do Azure com extensão aks-preview 0.5.97 ou posterior.
  • Se estiver usando ARM ou a API REST, a versão da API AKS deve ser 2022-04-02-preview ou posterior.

Instalar a extensão aks-preview da CLI do Azure

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

  • Instale a extensão aks-preview usando o az extension add comando.

    az extension add --name aks-preview

  • Atualize para a versão mais recente da extensão lançada usando o az extension update comando.

    az extension update --name aks-preview

Registre o sinalizador de recurso 'EnableAPIServerVnetIntegrationPreview'

  1. Registre o EnableAPIServerVnetIntegrationPreview sinalizador de recurso usando o az feature register comando.

    az feature register --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"

    Leva alguns minutos para que o status mostre Registrado.

  2. Verifique o status do registro usando o az feature show comando:

    az feature show --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"

  3. Quando o status refletir Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o az provider register comando.

    az provider register --namespace Microsoft.ContainerService

Criar um cluster AKS com integração de VNet do Servidor de API usando VNet gerenciada

Você pode configurar seus clusters AKS com a integração de VNet do API Server em VNet gerenciada ou trazer seu próprio modo VNet. Você pode criá-los como clusters públicos (com acesso ao servidor de API disponível por meio de um IP público) ou clusters privados (onde o servidor de API só é acessível por meio de conectividade VNet privada). Você também pode alternar entre um estado público e privado sem reimplantar o cluster.

Criar um grupo de recursos

  • Crie um grupo de recursos usando o az group create comando.

    az group create --location westus2 --name <resource-group>

Implantar um cluster público

  • Implante um cluster AKS público com integração de VNet do API Server para VNet gerenciada usando o az aks create comando com o --enable-api-server-vnet-integration sinalizador.

    az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-apiserver-vnet-integration \
    --generate-ssh-keys

Implantar um cluster privado

  • Implante um cluster AKS privado com integração de VNet do API Server para VNet gerenciada usando o az aks create comando com os --enable-api-server-vnet-integration sinalizadores e --enable-private-cluster .

    az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-private-cluster \
    --enable-apiserver-vnet-integration \
    --generate-ssh-keys

Crie um cluster AKS privado com a integração de VNet do API Server usando traga sua própria VNet

Ao usar traga sua própria VNet, você deve criar e delegar uma sub-rede do servidor API ao Microsoft.ContainerService/managedClusters, que concede ao serviço AKS permissões para injetar os pods do servidor API e o balanceador de carga interno nessa sub-rede. Você não pode usar a sub-rede para outras cargas de trabalho, mas pode usá-la para vários clusters AKS localizados na mesma rede virtual. O tamanho mínimo suportado da sub-rede do servidor API é / 28.

A identidade do cluster precisa de permissões para a sub-rede do servidor de API e para a sub-rede do nó. A falta de permissões na sub-rede do servidor de API pode causar uma falha de provisionamento.

Aviso

Um cluster AKS reserva pelo menos 9 IPs no espaço de endereço da sub-rede. A falta de endereços IP pode impedir o dimensionamento do servidor de API e causar uma interrupção do servidor de API.

Criar um grupo de recursos

az group create --location <location> --name <resource-group>

Criar uma rede virtual

  1. Crie uma rede virtual usando o az network vnet create comando.

    az network vnet create --name <vnet-name> \
--resource-group <resource-group> \
--location <location> \
--address-prefixes 172.19.0.0/16

  2. Crie uma sub-rede do servidor de API usando o az network vnet subnet create comando.

    az network vnet subnet create --resource-group <resource-group> \
--vnet-name <vnet-name> \
--name <apiserver-subnet-name> \
--delegations Microsoft.ContainerService/managedClusters \
--address-prefixes 172.19.0.0/28

  3. Crie uma sub-rede de cluster usando o az network vnet subnet create comando.

    az network vnet subnet create --resource-group <resource-group> \
--vnet-name <vnet-name> \
--name <cluster-subnet-name> \
--address-prefixes 172.19.1.0/24

Criar uma identidade gerenciada e dar-lhe permissões na rede virtual

  1. Crie uma identidade gerenciada usando o az identity create comando.

    az identity create --resource-group <resource-group> --name <managed-identity-name> --location <location>

  2. Atribua a função de Colaborador de Rede à sub-rede do servidor de API usando o az role assignment create comando.

    az role assignment create --scope <apiserver-subnet-resource-id> \
--role "Network Contributor" \
--assignee <managed-identity-client-id>

  3. Atribua a função de Colaborador de Rede à sub-rede do cluster usando o az role assignment create comando.

    az role assignment create --scope <cluster-subnet-resource-id> \
--role "Network Contributor" \
--assignee <managed-identity-client-id>

Implantar um cluster público

  • Implante um cluster AKS público com integração VNet do API Server usando o az aks create comando com o --enable-api-server-vnet-integration sinalizador.

    az aks create --name <cluster-name> \
    --resource-group <resource-group> \
    --location <location> \
    --network-plugin azure \
    --enable-apiserver-vnet-integration \
    --vnet-subnet-id <cluster-subnet-resource-id> \
    --apiserver-subnet-id <apiserver-subnet-resource-id> \
    --assign-identity <managed-identity-resource-id> \
    --generate-ssh-keys

Implantar um cluster privado

  • Implante um cluster AKS privado com integração VNet do API Server usando o az aks create comando com os --enable-api-server-vnet-integration sinalizadores e --enable-private-cluster .

    az aks create --name <cluster-name> \
--resource-group <resource-group> \
--location <location> \
--network-plugin azure \
--enable-private-cluster \
--enable-apiserver-vnet-integration \
--vnet-subnet-id <cluster-subnet-resource-id> \
--apiserver-subnet-id <apiserver-subnet-resource-id> \
--assign-identity <managed-identity-resource-id> \
--generate-ssh-keys

Converter um cluster AKS existente em integração de VNet do Servidor de API

Você pode converter clusters AKS públicos/privados existentes em clusters de integração de VNet do Servidor de API fornecendo uma sub-rede de servidor de API que atenda aos requisitos listados anteriormente. Esses requisitos incluem: na mesma VNet que os nós do cluster, permissões concedidas para a identidade do cluster AKS, não usadas por outros recursos, como ponto de extremidade privado, e tamanho de pelo menos /28. A conversão do cluster é uma migração unidirecional. Os clusters não podem ter a integração de VNet do Servidor de API desabilitada depois de habilitada.

Essa atualização executa uma atualização de versão de imagem de nó em todos os pools de nós e reinicia todas as cargas de trabalho enquanto elas passam por uma atualização de imagem contínua.

Aviso

A conversão de um cluster para a integração de rede virtual do API Server resulta em uma alteração do endereço IP do servidor de API, embora o nome do host permaneça o mesmo. Se o endereço IP do servidor de API tiver sido configurado em quaisquer firewalls ou regras de grupo de segurança de rede, essas regras talvez precisem ser atualizadas.

  • Atualize seu cluster para API Server VNet Integration usando o az aks update comando com o --enable-apiserver-vnet-integration sinalizador.

    az aks update --name <cluster-name> \
--resource-group <resource-group> \
--enable-apiserver-vnet-integration \
--apiserver-subnet-id <apiserver-subnet-resource-id>

Habilitar ou desabilitar o modo de cluster privado em um cluster existente com a integração de rede virtual do API Server

Os clusters AKS configurados com a integração de rede virtual do API Server podem ter o modo de acesso à rede pública/cluster privado ativado ou desativado sem reimplantar o cluster. O nome de host do servidor de API não é alterado, mas as entradas DNS públicas são modificadas ou removidas, se necessário.

Nota

--disable-private-cluster está atualmente em pré-visualização. Para obter mais informações, consulte Níveis de referência e suporte.

Ativar o modo de cluster privado

  • Habilite o modo de cluster privado usando o az aks update comando com o --enable-private-cluster sinalizador.

    az aks update --name <cluster-name> \
--resource-group <resource-group> \
--enable-private-cluster

Desativar o modo de cluster privado

  • Desative o modo de cluster privado usando o az aks update comando com o --disable-private-cluster sinalizador.

    az aks update --name <cluster-name> \
--resource-group <resource-group> \
--disable-private-cluster

Ligar ao cluster com o kubectl

  • Configure kubectl para se conectar ao cluster usando o az aks get-credentials comando.

    az aks get-credentials --resource-group <resource-group> --name <cluster-name>

Regras de segurança NSG

Todo o tráfego dentro da VNet é permitido por padrão. Mas se você adicionou regras do NSG para restringir o tráfego entre sub-redes diferentes, certifique-se de que as regras de segurança do NSG permitam os seguintes tipos de comunicação:

Destino Origem Protocolo Porta Utilizar
APIServer Sub-rede CIDR Sub-rede de cluster TCP 443.º e 4443.º Necessário para habilitar a comunicação entre nós e o servidor de API.
APIServer Sub-rede CIDR Balanceador de Carga do Azure TCP 9988 Necessário para habilitar a comunicação entre o Azure Load Balancer e o servidor de API. Você também pode habilitar todas as comunicações entre o Balanceador de Carga do Azure e o CIDR de Sub-rede do Servidor de API.

Próximos passos

Para obter as melhores práticas associadas, consulte Práticas recomendadas para conectividade de rede e segurança no AKS.