Gerenciamento de nós e pool de nós do Kubernetes

A arquitetura do Kubernetes é baseada em duas camadas: O plano de controle e um ou mais nós em pools de nós. Este artigo descreve e compara como o Amazon Elastic Kubernetes Service (Amazon EKS) e o Azure Kubernetes Service (AKS) gerenciam nós de agente ou de trabalho.

No Amazon EKS e no AKS, a plataforma de nuvem fornece e gerencia a camada do plano de controle, e o cliente gerencia a camada do nó. O diagrama a seguir mostra a relação entre o plano de controle e os nós na arquitetura Kubernetes do AKS.

Grupos de nós gerenciados pelo Amazon EKS

Os grupos de nós gerenciados pelo Amazon EKS automatizam o provisionamento e o gerenciamento do ciclo de vida dos nós de trabalho do Amazon Elastic Compute Cloud (EC2) para clusters do Amazon EKS. Os usuários da Amazon Web Services (AWS) podem usar o utilitário de linha de comando eksctl para criar, atualizar ou encerrar nós para seus clusters EKS. As atualizações e terminações de nós automaticamente canalizam e drenam nós para garantir que os aplicativos permaneçam disponíveis.

Cada nó gerenciado é provisionado como parte de um grupo do Amazon EC2 Auto Scaling que o Amazon EKS opera e controla. O autoscaler de cluster do Kubernetes ajusta automaticamente o número de nós de trabalho em um cluster quando os pods falham ou são reagendados para outros nós. Cada grupo de nós pode ser configurado para ser executado em várias zonas de disponibilidade dentro de uma região.

Para obter mais informações sobre nós gerenciados do Amazon EKS, consulte Criar um grupo de nós gerenciados e Atualizar um grupo de nós gerenciados.

Você também pode executar pods do Kubernetes no AWS Fargate. A Fargate fornece capacidade de computação sob demanda e de tamanho certo para contêineres. Para obter mais informações sobre como usar o Fargate com o Amazon EKS, consulte AWS Fargate.

Nós AKS e pools de nós

A criação de um cluster AKS cria e configura automaticamente um plano de controle, que fornece serviços principais do Kubernetes e orquestração da carga de trabalho do aplicativo. A plataforma Azure fornece o plano de controle AKS sem custo como um recurso gerenciado do Azure. O plano de controle e seus recursos existem apenas na região onde você criou o cluster.

Os nós, também chamados nós de agente ou nós de trabalho, hospedam as cargas de trabalho e os aplicativos. No AKS, os clientes gerenciam e pagam totalmente pelos nós do agente conectados ao cluster do AKS.

Para executar aplicativos e serviços de suporte, um cluster AKS precisa de pelo menos um nó: uma máquina virtual (VM) do Azure para executar os componentes do nó Kubernetes e o tempo de execução do contêiner. Cada cluster AKS deve conter pelo menos um pool de nós do sistema com pelo menos um nó.

O AKS agrupa nós da mesma configuração em pools de nós de VMs que executam cargas de trabalho do AKS. Os pools de nós do sistema servem o objetivo principal de hospedar pods críticos do sistema, como o CoreDNS. Os pools de nós de usuário têm o objetivo principal de hospedar pods de carga de trabalho. Se você quiser ter apenas um pool de nós em seu cluster AKS, por exemplo, em um ambiente de desenvolvimento, poderá agendar pods de aplicativos no pool de nós do sistema.

Você também pode criar vários pools de nós de usuário para segregar cargas de trabalho diferentes em nós diferentes para evitar o problema do vizinho barulhento ou para dar suporte a aplicativos com diferentes demandas de computação ou armazenamento.

Cada nó de agente de um sistema ou pool de nós de usuário é uma VM provisionada como parte dos Conjuntos de Escala de Máquina Virtual do Azure e gerenciada pelo cluster AKS. Para obter mais informações, consulte Nós e pools de nós.

Você pode definir o número e o tamanho iniciais dos nós de trabalho ao criar um cluster AKS ou ao adicionar novos nós e pools de nós a um cluster AKS existente. Se você não especificar um tamanho de VM, o tamanho padrão será Standard_D2s_v3 para pools de nós do Windows e Standard_DS2_v2 para pools de nós do Linux.

Criação de pool de nós

Você pode adicionar um pool de nós a um cluster AKS novo ou existente usando o portal do Azure, a CLI do Azure, a API REST do AKS ou ferramentas de infraestrutura como código (IaC), como Bicep, modelos do Azure Resource Manager ou Terraform. Para obter mais informações sobre como adicionar pools de nós a um cluster AKS existente, consulte Criar e gerenciar vários pools de nós para um cluster no Serviço Kubernetes do Azure (AKS).

Quando você cria um novo pool de nós, o conjunto de escala de máquina virtual associado é criado no grupo de recursos de nó, um grupo de recursos do Azure que contém todos os recursos de infraestrutura para o cluster AKS. Esses recursos incluem os nós do Kubernetes, recursos de rede virtual, identidades gerenciadas e armazenamento.

Por padrão, o grupo de recursos do nó tem um nome como MC_<resourcegroupname>_<clustername>_<location>. O AKS exclui automaticamente o grupo de recursos do nó ao excluir um cluster, portanto, você deve usar esse grupo de recursos apenas para recursos que compartilham o ciclo de vida do cluster.

Adicionar um conjunto de nós

O exemplo de código a seguir usa o comando Azure CLI az aks nodepool add para adicionar um pool de nós nomeado mynodepool com três nós a um cluster AKS existente chamado myAKSCluster no myResourceGroup grupo de recursos.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

Pools de nós spot

Um pool de nós spot é um pool de nós apoiado por um conjunto de escala de máquina virtual spot. O uso de máquinas virtuais spot para nós com seu cluster AKS aproveita a capacidade não utilizada do Azure com uma economia de custos significativa. A quantidade de capacidade disponível não utilizada varia com base em muitos fatores, incluindo o tamanho do nó, a região e a hora do dia.

Ao implantar um pool de nós spot, o Azure aloca os nós spot se houver capacidade disponível. Mas não há acordo de nível de serviço (SLA) para os nós spot. Um conjunto de escala spot que apoia o pool de nós spot é implantado em um único domínio de falha e não oferece garantias de alta disponibilidade. Quando o Azure precisa da capacidade de volta, a infraestrutura do Azure remove nós spot e você recebe no máximo um aviso de 30 segundos antes da remoção. Lembre-se de que um pool de nós spot não pode ser o pool de nós padrão do cluster. Um pool de nós spot pode ser usado apenas para um pool secundário.

Os nós spot destinam-se a cargas de trabalho que podem lidar com interrupções, terminações antecipadas ou remoções. Por exemplo, trabalhos de processamento em lote, ambientes de desenvolvimento e teste e grandes cargas de trabalho de computação são bons candidatos para agendamento em um pool de nós locais. Para obter mais detalhes, consulte as limitações da instância spot.

O comando a seguir az aks nodepool add adiciona um pool de nós spot a um cluster existente com o dimensionamento automático habilitado.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

Para obter mais informações sobre pools de nós spot, consulte Adicionar um pool de nós spot a um cluster do Serviço Kubernetes do Azure (AKS).

Discos de SO Efémeros

Por padrão, o Azure replica automaticamente o disco do sistema operacional (SO) da VM para o Armazenamento do Azure para evitar a perda de dados se a VM precisar ser realocada para outro host. Mas como os contêineres não são projetados para persistir o estado local, manter o disco do sistema operacional no armazenamento oferece um valor limitado para o AKS. Há algumas desvantagens, como provisionamento de nó mais lento e maior latência de leitura/gravação.

Por outro lado, os discos efêmeros do sistema operacional são armazenados apenas na máquina host, como um disco temporário, e fornecem menor latência de leitura/gravação e escalonamento de nó e atualizações de cluster mais rápidos. Como um disco temporário, um disco de sistema operacional efêmero está incluído no preço da VM, portanto, você não incorre em custos extras de armazenamento.

Para usar um sistema operacional efêmero, o disco do sistema operacional deve caber no cache da VM. A documentação da VM do Azure mostra o tamanho do cache da VM entre parênteses ao lado da taxa de transferência de E/S como tamanho do cache em gibibytes (GiB).

Por exemplo, o tamanho padrão da VM Standard_DS2_v2 AKS com o tamanho de disco padrão do sistema operacional de 100 GB suporta sistema operacional efêmero, mas tem apenas 86 GB de tamanho de cache. O padrão dessa configuração é o disco gerenciado se você não especificar explicitamente o contrário. Se você solicitar explicitamente um sistema operacional efêmero para esse tamanho, receberá um erro de validação.

Se você solicitar o mesmo Standard_DS2_v2 VM com um disco de sistema operacional de 60 GB, obterá um sistema operacional efêmero por padrão. O tamanho do SO de 60 GB solicitado é menor do que o tamanho máximo de cache de 86 GB.

Standard_D8s_v3 com um disco de SO de 100 GB suporta SO efémero e tem 200 GB de espaço em cache. Se um usuário não especificar o tipo de disco do sistema operacional, um pool de nós receberá um sistema operacional efêmero por padrão.

O comando a seguir az aks nodepool add mostra como adicionar um novo pool de nós a um cluster existente com um disco de sistema operacional efêmero. O --node-osdisk-type parâmetro define o tipo de disco do sistema operacional como Ephemeral, e o --node-osdisk-size parâmetro define o tamanho do disco do sistema operacional.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

Para obter mais informações sobre discos de SO efêmeros, consulte SO efêmero.

Nós virtuais

Você pode usar nós virtuais para expandir rapidamente cargas de trabalho de aplicativos em um cluster AKS. Os nós virtuais oferecem provisionamento rápido de pods e você paga apenas por segundo pelo tempo de execução. Você não precisa esperar que o autoscaler do cluster implante novos nós de trabalho para executar mais réplicas de pod. Os nós virtuais são suportados apenas com pods e nós Linux. O complemento de nós virtuais para AKS é baseado no projeto de código aberto Virtual Kubelet .

A funcionalidade do nó virtual depende das Instâncias de Contêiner do Azure. Para obter mais informações sobre nós virtuais, consulte Criar e configurar um cluster dos Serviços Kubernetes do Azure (AKS) para usar nós virtuais.

Manchas, rótulos e tags

Ao criar um pool de nós, você pode adicionar manchas e rótulos do Kubernetes e marcas do Azure a esse pool de nós. Quando você adiciona uma mancha, rótulo ou marca, todos os nós dentro desse pool de nós obtêm essa mancha, rótulo ou marca.

Para criar um pool de nós com um taint, você pode usar o az aks nodepool add comando com o --node-taints parâmetro. Para rotular os nós em um pool de nós, você pode usar o --labels parâmetro e especificar uma lista de rótulos, conforme mostrado no código a seguir:

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

Para obter mais informações, consulte Especificar uma mancha, rótulo ou marca para um pool de nós.

Etiquetas de sistema reservadas

O Amazon EKS adiciona rótulos Kubernetes automatizados a todos os nós em um grupo de nós gerenciados, como eks.amazonaws.com/capacityType, que especifica o tipo de capacidade. O AKS também adiciona automaticamente rótulos do sistema aos nós do agente.

Os seguintes prefixos são reservados para uso do AKS e não podem ser usados para nenhum nó:

• kubernetes.azure.com/
• kubernetes.io/

Para outros prefixos reservados, consulte Rótulos, anotações e manchas conhecidos do Kubernetes.

A tabela a seguir lista os rótulos reservados para uso do AKS e que não podem ser usados para nenhum nó. Na tabela, a coluna Uso do nó virtual especifica se o rótulo é suportado em nós virtuais.

Na coluna Uso do nó virtual:

• N/D significa que a propriedade não se aplica a nós virtuais porque exigiria modificar o host.
• O mesmo significa que os valores esperados são os mesmos para um pool de nós virtuais e para um pool de nós padrão.
• Virtual substitui os valores de SKU da VM, porque os pods de nó virtual não expõem nenhuma VM subjacente.
• Versão do nó virtual refere-se à versão atual da versão do conector Kubelet-ACI virtual.
• O nome da sub-rede do nó virtual é a sub-rede que implanta pods de nó virtual nas Instâncias de Contêiner do Azure.
• Rede virtual de nó virtual é a rede virtual que contém a sub-rede do nó virtual.

Pools de nós do Windows

O AKS dá suporte à criação e ao uso de pools de nós de contêiner do Windows Server por meio do plug-in de rede CNI (interface de rede de contêiner) do Azure. Para planejar os intervalos de sub-rede necessários e as considerações de rede, consulte Configurar a rede CNI do Azure.

O comando a seguir az aks nodepool add adiciona um pool de nós que executa contêineres do Windows Server.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

O comando anterior usa a sub-rede padrão na rede virtual do cluster AKS. Para obter mais informações sobre como criar um cluster AKS com um pool de nós do Windows, consulte Criar um contêiner do Windows Server no AKS.

Considerações sobre o pool de nós

As seguintes considerações e limitações se aplicam quando você cria e gerencia pools de nós e pools de vários nós:

• Cotas, restrições de tamanho de VM e disponibilidade de região se aplicam a pools de nós AKS.

• Os pools de sistemas devem conter pelo menos um nó. Você pode excluir um pool de nós do sistema se tiver outro pool de nós do sistema para ocupar seu lugar no cluster AKS. Os pools de nós de usuário podem conter zero ou mais nós.

• Não é possível alterar o tamanho da VM de um pool de nós depois de criá-lo.

• Para pools de vários nós, o cluster AKS deve usar os balanceadores de carga SKU padrão. Os balanceadores de carga SKU básicos não suportam vários pools de nós.

• Todos os pools de nós de cluster devem estar na mesma rede virtual e todas as sub-redes atribuídas a qualquer pool de nós devem estar na mesma rede virtual.

• Se você criar vários pools de nós no momento da criação do cluster, as versões do Kubernetes para todos os pools de nós deverão corresponder à versão do plano de controle. Você pode atualizar versões após o cluster ter sido provisionado usando operações por pool de nós.

Dimensionamento do pool de nós

À medida que a carga de trabalho do aplicativo muda, talvez seja necessário alterar o número de nós em um pool de nós. Você pode dimensionar o número de nós para cima ou para baixo manualmente usando o comando az aks nodepool scale . O exemplo a seguir dimensiona o número de nós em mynodepool cinco:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

Dimensionar pools de nós automaticamente usando o autoscaler de cluster

O AKS suporta o dimensionamento automático de pools de nós com o autoscaler de cluster. Você habilita esse recurso em cada pool de nós e define um número mínimo e máximo de nós.

O comando a seguir az aks nodepool add adiciona um novo pool de nós chamado mynodepool a um cluster existente. O --enable-cluster-autoscaler parâmetro habilita o autoscaler de cluster no novo pool de nós e os --min-count parâmetros e --max-count especificam o número mínimo e máximo de nós no pool.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

O comando az aks nodepool update a seguir atualiza o número mínimo de nós de um para três para o mynewnodepool pool de nós.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

Você pode desativar o autoscaler do cluster passando az aks nodepool update o --disable-cluster-autoscaler parâmetro.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

Para reativar o autodimensionador de cluster em um cluster existente, use az aks nodepool update, especificando os --enable-cluster-autoscalerparâmetros , --min-counte --max-count .

Para obter mais informações sobre como usar o autoscaler de cluster para pools de nós individuais, consulte Dimensionar automaticamente um cluster para atender às demandas de aplicativos no Serviço Kubernetes do Azure (AKS).

Atualizações e upgrades

O Azure atualiza periodicamente sua plataforma de hospedagem de VM para melhorar a confiabilidade, o desempenho e a segurança. Essas atualizações vão desde a aplicação de patches em componentes de software no ambiente de hospedagem até a atualização de componentes de rede ou desativação de hardware. Para obter mais informações sobre como o Azure atualiza VMs, consulte Manutenção para máquinas virtuais no Azure.

As atualizações de infraestrutura de hospedagem de VM geralmente não afetam VMs hospedadas, como nós de agente de clusters AKS existentes. Para atualizações que afetam VMs hospedadas, o Azure minimiza os casos que exigem reinicializações pausando a VM enquanto atualiza o host ou migrando ao vivo a VM para um host já atualizado.

Se uma atualização exigir uma reinicialização, o Azure fornecerá notificação e uma janela de tempo para que você possa iniciar a atualização quando ela funcionar para você. A janela de automanutenção para máquinas host normalmente é de 35 dias, a menos que a atualização seja urgente.

Você pode usar a Manutenção Planejada para atualizar VMs e gerenciar notificações de manutenção planejada com a CLI do Azure, o PowerShell ou o portal do Azure. A Manutenção Planejada deteta se você está usando a Atualização Automática de Cluster e agenda atualizações durante a janela de manutenção automaticamente. Para obter mais informações sobre a Manutenção Planejada, consulte o comando az aks maintenanceconfiguration e Usar a Manutenção Planejada para agendar janelas de manutenção para seu cluster do Serviço Kubernetes do Azure (AKS).

Atualizações do Kubernetes

Parte do ciclo de vida do cluster AKS é atualizar periodicamente para a versão mais recente do Kubernetes. É importante aplicar atualizações para obter as versões e recursos de segurança mais recentes. Para atualizar a versão do Kubernetes das VMs do pool de nós existentes, você deve conectar e drenar nós e substituí-los por novos nós baseados em uma imagem de disco atualizada do Kubernetes.

Por padrão, o AKS configura as atualizações para aumentar com um nó extra. Um valor padrão de um para as configurações minimiza a max-surge interrupção da carga de trabalho criando um nó extra para substituir nós com versões mais antigas antes de cortar ou drenar aplicativos existentes. Você pode personalizar o valor por pool de nós para permitir uma compensação entre a velocidade de atualização e a max-surge interrupção da atualização. Aumentar o max-surge valor conclui o processo de atualização mais rapidamente, mas um grande valor para max-surge pode causar interrupções durante o processo de atualização.

Por exemplo, um max-surge valor de 100% fornece o processo de atualização mais rápido possível duplicando a contagem de nós, mas também faz com que todos os nós no pool de nós sejam drenados simultaneamente. Talvez você queira usar esse alto valor para testes, mas para pools de nós de produção, uma max-surge configuração de 33% é melhor.

O AKS aceita valores inteiros e percentuais para max-surge. Um número inteiro como 5 indica cinco nós extras a serem aumentados. Os valores percentuais para max-surge podem ser um mínimo de 1% e um máximo de 100%, arredondados para a contagem de nós mais próxima. Um valor de indica um valor de 50% aumento de metade da contagem de nós atual no pool.

Durante uma atualização, o max-surge valor pode ser mínimo e 1 máximo igual ao número de nós no pool de nós. Você pode definir valores maiores, mas o número máximo de nós usados para max-surge não será maior do que o número de nós no pool.

Atualizar pools de nós

Para ver as atualizações disponíveis, use az aks get-upgrades.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

Para ver o status dos pools de nós, use az aks nodepool list.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

O comando a seguir usa az aks nodepool upgrade para atualizar um pool de nó único.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

Para obter mais informações sobre como atualizar a versão do Kubernetes para um plano de controle de cluster e pools de nós, consulte:

• Atualização da imagem do nó do Azure Kubernetes Service (AKS)
• Atualizar um plano de controle de cluster com vários pools de nós

Considerações sobre atualização

Observe estas práticas recomendadas e considerações para atualizar a versão do Kubernetes em um cluster AKS.

• É melhor atualizar todos os pools de nós em um cluster AKS para a mesma versão do Kubernetes. O comportamento padrão de az aks upgrade atualiza todos os pools de nós e o plano de controle.

• Atualize manualmente ou defina um canal de atualização automática no cluster. Se você usar a Manutenção Planejada para corrigir VMs, as atualizações automáticas também serão iniciadas durante a janela de manutenção especificada. Para obter mais informações, veja Atualizar um cluster do Azure Kubernetes Service (AKS).

• O az aks upgrade comando com o --control-plane-only sinalizador atualiza apenas o plano de controle do cluster e não altera nenhum dos pools de nós associados no cluster. Para atualizar pools de nós individuais, especifique o pool de nós de destino e a versão do az aks nodepool upgrade Kubernetes no comando.

• Uma atualização do cluster do AKS aciona um cordão e esvaziamento dos seus nós. Se você tiver baixa cota de computação disponível, a atualização poderá falhar. Para obter mais informações sobre como aumentar sua cota, consulte Aumentar cotas regionais de vCPU.

• Configure o max-surge parâmetro com base em suas necessidades, usando um inteiro ou um valor percentual. Para pools de nós de produção, use uma max-surge configuração de 33%. Para obter mais informações, consulte Personalizar atualização de aumento de aumento de nó.

• Ao atualizar um cluster AKS que usa rede CNI, verifique se a sub-rede tem endereços IP privados disponíveis suficientes para os nós extras criados pelas max-surge configurações. Para obter mais informações, consulte Configurar a rede CNI do Azure no Serviço Kubernetes do Azure (AKS).

• Se os pools de nós do cluster abrangerem várias zonas de disponibilidade dentro de uma região, o processo de atualização poderá causar temporariamente uma configuração de zona desequilibrada. Para obter mais informações, consulte Considerações especiais para pools de nós que abrangem várias zonas de disponibilidade.

Redes virtuais de nó

Ao criar um novo cluster ou adicionar um novo pool de nós a um cluster existente, você especifica a ID do recurso de uma sub-rede dentro da rede virtual do cluster onde implanta os nós do agente. Uma carga de trabalho pode exigir a divisão dos nós de um cluster em pools de nós separados para isolamento lógico. Você pode obter esse isolamento com sub-redes separadas, cada uma dedicada a um pool de nós separado. Cada uma das VMs do pool de nós obtém um endereço IP privado de sua sub-rede associada.

O AKS suporta dois plugins de rede:

• Kubenet é um plugin de rede básico e simples para Linux. Com kubeneto , os nós obtêm um endereço IP privado da sub-rede da Rede Virtual do Azure. Os pods obtêm um endereço IP de um espaço de endereço logicamente diferente. A conversão de endereços de rede (NAT) permite que os pods alcancem recursos na rede virtual do Azure convertendo o endereço IP do tráfego de origem para o endereço IP primário do nó. Essa abordagem reduz o número de endereços IP que você precisa reservar em seu espaço de rede para pods.

• A CNI (Container Networking Interface) do Azure fornece a cada pod um endereço IP para chamar e acessar diretamente. Esses endereços IP devem ser exclusivos em todo o espaço da rede. Cada nó tem um parâmetro de configuração para o número máximo de pods suportados. O número equivalente de endereços IP por nó é então reservado para esse nó. Essa abordagem requer planejamento antecipado e pode levar ao esgotamento do endereço IP ou à necessidade de reconstruir clusters em uma sub-rede maior à medida que as demandas de aplicativos crescem.

  Ao criar um novo cluster ou adicionar um novo pool de nós a um cluster que usa o Azure CNI, você pode especificar a ID de recurso de duas sub-redes separadas, uma para os nós e outra para os pods. Para obter mais informações, consulte Alocação dinâmica de IPs e suporte avançado a sub-redes.

Alocação dinâmica de IP

Os pods que usam o Azure CNI obtêm endereços IP privados de uma sub-rede do pool de nós de hospedagem. A alocação de IP dinâmico CNI do Azure pode alocar endereços IP privados para pods de uma sub-rede separada da sub-rede de hospedagem do pool de nós. Este recurso oferece as seguintes vantagens:

• A sub-rede pod aloca dinamicamente IPs para pods. A alocação dinâmica fornece melhor utilização de IP em comparação com a solução CNI tradicional, que faz alocação estática de IPs para cada nó.

• Você pode dimensionar e compartilhar sub-redes de nó e pod de forma independente. Você pode compartilhar uma única sub-rede de pod em vários pools de nós ou clusters implantados na mesma rede virtual. Você também pode configurar uma sub-rede de pod separada para um pool de nós.

• Como os pods têm IPs privados de rede virtual, eles têm conectividade direta com outros pods de cluster e recursos na rede virtual. Essa capacidade suporta um melhor desempenho para clusters muito grandes.

• Se os pods tiverem uma sub-rede separada, você poderá configurar políticas de rede virtual para pods diferentes das políticas de nó. Políticas separadas permitem muitos cenários úteis, como permitir conectividade com a Internet apenas para pods e não para nós, corrigir o IP de origem de um pod em um pool de nós usando o NAT Gateway e usar NSGs (Network Security Groups) para filtrar o tráfego entre pools de nós.

• Tanto a Política de Rede quanto as políticas de rede do Calico Kubernetes funcionam com alocação dinâmica de IP.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

• Paolo Salvatori - Brasil | Engenheiro de Sistemas Principal

Outros contribuidores:

• Laura Nicolas - Brasil | Engenheiro de Software Sênior
• Chade Kittel - Brasil | Engenheiro de Software Principal
• Ed Preço | Gerente de Programa de Conteúdo Sênior
• Theano Petersen - Brasil | Redator Técnico

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

• AKS para profissionais do Amazon EKS
• Gerenciamento de identidade e acesso do Kubernetes
• Monitoramento e registro em log do Kubernetes
• Acesso seguro à rede do Kubernetes
• Opções de armazenamento para um cluster Kubernetes
• Gestão de custos para Kubernetes
• Governança de cluster
• Jornada da solução do Serviço Kubernetes do Azure (AKS)
• Guia de operações do dia 2 dos Serviços Kubernetes do Azure (AKS)
• Escolha uma opção de computação do Kubernetes na borda
• Serviço GitOps para Kubernetes do Azure

Recursos relacionados

• Práticas recomendadas do cluster AKS
• Criar um cluster AKS privado com uma zona DNS pública
• Criar um cluster privado do Serviço Kubernetes do Azure usando o Terraform e o Azure DevOps
• Criar um cluster de Serviço Kubernetes do Azure público ou privado com o Azure NAT Gateway e o Azure Application Gateway
• Usar pontos de extremidade privados com um cluster privado do AKS
• Criar um cluster do Serviço Kubernetes do Azure com o Application Gateway Ingress Controller
• Introdução ao Kubernetes
• Introdução ao Kubernetes no Azure
• Implementar o Serviço Kubernetes do Azure (AKS)
• Desenvolver e implantar aplicativos no Kubernetes
• Otimizar os custos de computação no Serviço Kubernetes do Azure (AKS)