Compartilhar via


Criar um cluster do Serviço de Kubernetes do Azure com a Integração VNet do Servidor de API

Um cluster do AKS (Serviço de Kubernetes do Azure) 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 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á em 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.

Pré-requisitos

  • Você deve ter a CLI do Azure versão 2.73.0 ou posterior instalada. Você pode verificar sua versão usando o az --version comando.

Disponibilidade limitada

Importante

A Integração VNet do Servidor de API tem disponibilidade e capacidade limitadas em determinadas regiões.
Ao criar ou atualizar um cluster com a Integração VNet do Servidor de API habilitada, você pode receber o seguinte erro:

API Server VNet Integration is currently unavailable in region (_region_) due to high demand and limited capacity. AKS is actively expanding support for this feature. Check for other available regions at aka.ms/AksVnetIntegration.

Essa mensagem indica que a região selecionada atingiu temporariamente a capacidade de Integração VNet do Servidor de API.

Para continuar, você pode:

  • Repita sua solicitação posteriormente, pois a capacidade pode ficar disponível.
  • Selecione uma região alternativa em que esse recurso tem suporte no momento.

A Integração VNet do Servidor de API está disponível nas seguintes regiões:

australiacentral, australiacentral2, australiaeast, australiasoutheast, austriaeast, brazilsouth, brazilsoutheast, canadacentral, canadaeast, centralindia, centralus, centraluseuap, chilecentral, eastasia, eastus, eastus2euap, francecentral, francesouth, germanynorth, germanywestcentral, indonesiacentral, israelcentral, israelnorthwest, italynorth, japaneast, japanwest, jioindiacentral, jioindiawest, koreacentral, koreacentral, malaysiawest, mexicocentral, newzealandnorth, northcentralus, northeurope, norwayeast, norwaywest,polandcentral, southafricanorth, southafricawest, southcentralus, southcentralus2, southeastasia, southeastus, southeastus3, southeastus5, southindia, southwestus, spaincentral, swedencentral, swedensouth, switzerlandnorth, switzerlandwest, taiwannorth, taiwannorthwest, uaecentral, uaenorth, uksouth, ukwest, usgovtexas, westcentralus, westeurope, westus, westus2, westus3

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

Você pode configurar seus clusters do AKS com a Integração 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 a Integração VNet do Servidor de API para 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 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 do AKS existente na Integração VNet do Servidor de API

Aviso

A Integração de VNet do Servidor de API é um recurso unidirecional e sensível à capacidade.

  • Reinicialização manual necessária.
    Depois de habilitar a Integração VNet do Servidor de API usando az aks update --enable-apiserver-vnet-integration, você deve reiniciar imediatamente o cluster para que a alteração entre em vigor. Essa reinicialização não é automatizada. Atrasar a reinicialização aumenta o risco de a capacidade ficar indisponível, o que pode impedir que o servidor de API seja iniciado.

  • A capacidade é validada, mas não reservada.
    O AKS valida a capacidade regional quando você habilita o recurso em um cluster existente, mas essa validação não reserva capacidade. Se a reinicialização estiver atrasada e a capacidade ficar indisponível enquanto isso, o cluster poderá falhar ao iniciar após uma parada ou reinicialização. Os clusters que habilitaram esse recurso antes da GA (disponibilidade geral) ou que ainda não foram reiniciados desde a habilitação não passarão por validação de capacidade.

  • O recurso não pode ser desabilitado.
    Depois de habilitado, o recurso é permanente. Não é possível desabilitar a Integração VNet do Servidor de API.

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 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>
    

Você pode expor o endpoint do API Server de um cluster privado com a Integração VNet do API Server usando o Azure Private Link. As etapas a seguir mostram como criar um PLS (Serviço de Link Privado) na VNet do cluster e conectar-se a ele de outra VNet ou assinatura usando um ponto de extremidade privado.

Criar um cluster privado de integração de VNet do servidor de API

  • Crie um cluster AKS privado com a 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> \
        --enable-private-cluster \
        --enable-apiserver-vnet-integration
    

Para obter mais diretrizes sobre como configurar o link privado com a integração VNet do servidor de API, confira Link privado com a integração VNet do servidor de API.

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 Fonte Protocolo Porta Utilização
CIDR de sub-rede do APIServer Sub-rede do 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 todas as comunicações entre o Azure Load Balancer e o CIDR da Sub-rede do Servidor de API.

Próximas etapas