Compartilhar via

Criar um cluster do Serviço de Kubernetes do Azure com a Integração de VNet do Servidor de API (Versão prévia)

  • Artigo

Um cluster do Serviço de Kubernetes do Azure (AKS) configurado com a Integração da VNet do Servidor de API projeta o ponto de extremidade do servidor de API diretamente em uma sub-rede delegada na VNet em que o AKS está 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 de cluster, sem a necessidade de um túnel ou um link privado. O servidor de API está disponível por trás de um balanceador de carga interno VIP na sub-rede delegada, que os nós estão configurados para utilizar. Ao usar a integração de VNet do Servidor de API, é possível garantir que o tráfego de rede entre o servidor de API e os pools de nós permaneça somente 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á na sua assinatura do Azure. O servidor e as máquinas virtuais que compõem os nós de cluster podem se comunicar entre si por meio do VIP do servidor de API e dos IPs de pod projetados na sub-rede delegada.

A Integração da VNet do Servidor API é compatível com 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 que não são da VNet, os nós do agente sempre se comunicam diretamente com o endereço IP privado do IP do balanceador de carga interno (ILB) do servidor de API sem usar o DNS. Todo o tráfego entre o nó e o servidor de API é mantido em uma rede privada, de modo que nenhum túnel é necessário para a conectividade entre o servidor de API e o nó. Clientes fora do cluster que precisam se comunicar com o servidor de API podem fazer isso normalmente se o acesso à rede pública estiver habilitado. Se o acesso à rede pública estiver desabilitado, você deve seguir a mesma metodologia de configuração do DNS privado usada nos clusters privados padrão.

Disponibilidade de região

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

Pré-requisitos

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

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

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

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

    az extension add --name aks-preview

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

    az extension update --name aks-preview

Registrar o sinalizador de recurso 'EnableAPIServerVnetIntegrationPreview'

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

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

    Demora alguns minutos para o status exibir Registrado.

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

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

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

    az provider register --namespace Microsoft.ContainerService

Criar um cluster do AKS com a Integração da VNet do Servidor API usando a VNet gerenciada

Você pode configurar seus clusters do AKS com a integração da VNet do Servidor de API no modo de VNet gerenciada ou de VNet própria. Você pode criá-los como clusters públicos (com acesso ao servidor de API disponível via IP público) ou clusters privados (onde o servidor de API está acessível apenas por meio de conectividade privada da VNet). 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 comando az group create.

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

Implantar um cluster público

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

    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 do AKS privado com integração da VNet do Servidor de API para a VNet gerenciada usando o comando az aks create com os sinalizadores --enable-api-server-vnet-integration 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 do AKS privado com a Integração da VNet do Servidor de API usando a VNet do tipo traga sua própria rede

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

A identidade do cluster precisa ter permissões na sub-rede do servidor de API e na sub-rede do nó. A falta de permissões na sub-rede do servidor de API poderá causar uma falha no provisionamento.

Aviso

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

Criar um grupo de recursos

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

Criar uma rede virtual

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

    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 no servidor de API usando o comando az network vnet subnet create.

    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. Criar uma sub-rede de cluster usando o comando az network vnet subnet create.

    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 conceder a ela permissões na rede virtual

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

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

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

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

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

    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 do AKS público com integração da VNet do Servidor de API usando o comando az aks create com o sinalizador --enable-api-server-vnet-integration.

    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 do AKS privado com integração da VNet do Servidor de API usando o comando az aks create com os sinalizadores --enable-api-server-vnet-integration 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 na Integração de VNet do Servidor de API

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

Esse upgrade executa uma atualização de versão de imagem do 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 na Integração de VNet do Servidor de API 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 poderão precisar ser atualizadas.

  • Atualize seu cluster para a Integração da VNet do Servidor API usando o comando az aks update com o sinalizador --enable-apiserver-vnet-integration.

    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 VNet do Servidor de API

Os clusters do AKS configurados com a Integração de VNet do Servidor de API podem ter o modo de acesso à rede pública/cluster privado habilitado ou desabilitado sem reimplantar o cluster. O nome do host do servidor de API não é alterado, mas as entradas de DNS público são modificadas ou removidas, se necessário.

Observação

O --disable-private-cluster está em versão prévia no momento. Para obter mais informações, confira Níveis de referência e suporte.

Habilitar o modo de cluster privado

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

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

Desabilitar o modo de cluster privado

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

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

Conectar-se ao cluster usando o kubectl

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

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

Regras de segurança do NSG

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

Destino Origem Protocolo Porta Use
CIDR de sub-rede do APIServer Sub-rede de cluster TCP 443 e 4443 Necessário para habilitar a comunicação entre nós e o servidor de API.
CIDR de sub-rede do APIServer Azure Load Balancer TCP 9988 Necessário para habilitar a comunicação entre o Azure Load Balancer e o servidor de API. Você também pode habilitar todos os comunicados entre o Azure Load Balancer e o CIDR da Sub-rede do Servidor de API.

Próximas etapas

Para as melhores práticas associadas, consulte Melhores práticas conectividade e segurança da rede no AKS.