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 ou pools de nós. Este artigo descreve e compara como o Amazon Elastic Kubernetes Service (Amazon EKS) e o Serviço de Kubernetes do Azure (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 em uma arquitetura AKS Kubernetes.

Grupos de nós gerenciados pelo Amazon EKS

Os grupos de nós gerenciados do 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 do EKS. As atualizações e terminações de nó automaticamente isolam e drenam os nós para garantir que os aplicativos permaneçam disponíveis.

Cada nó gerenciado é provisionado como parte de um grupo de dimensionamento automático do Amazon EC2 que o Amazon EKS opera e controla. O dimensionador automático 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 em 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. O Fargate fornece capacidade de computação sob demanda e do tamanho certo para contêineres. Para obter mais informações sobre como usar o Fargate com o Amazon EKS, consulte AWS Fargate.

Nós do AKS e pools de nós

A criação de um cluster do AKS cria e configura automaticamente um plano de controle, que fornece serviços principais do Kubernetes e orquestração de carga de trabalho de 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 em que você criou o cluster.

Os nós, também chamados de 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 de agente conectados ao cluster AKS.

Para executar aplicativos e serviços de suporte, um cluster do AKS precisa de pelo menos um nó: uma VM (máquina virtual) do Azure para executar os componentes do nó do Kubernetes e o runtime do contêiner. Cada cluster do AKS precisa conter pelo menos um pool de nós do sistema com no mínimo 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 atendem à principal finalidade de hospedar pods críticos do sistema, como CoreDNS. Os pools de nós de usuário atendem à finalidade primária 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 de vizinhos barulhentos ou para oferecer suporte a aplicativos com demandas de computação ou armazenamento diferentes.

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

Você pode definir o número e o tamanho iniciais para nós de trabalho ao criar um cluster do AKS ou ao adicionar novos nós e pools de nós a um cluster do 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 do pool de nós

Você pode adicionar um pool de nós a um cluster do 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 do AKS existente, consulte Criar e gerenciar vários pools de nós para um cluster no Serviço de Kubernetes do Azure (AKS).

Quando você cria um novo pool de nós, o conjunto de dimensionamento de máquina virtual associado é criado no grupo de recursos do nó, um grupo de recursos do Azure que contém todos os recursos de infraestrutura para o cluster do 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 de nó quando o cluster é excluído e, portanto, só deve ser usado para os recursos que compartilham o ciclo de vida do cluster.

Adicionar um pool de nós

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

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 é apoiado por um conjunto de dimensionamento de máquinas virtuais. Usar máquinas virtuais spot para nós com seu cluster do AKS aproveita a capacidade não utilizada do Azure com uma poupança de custos significativa. A quantidade de capacidade disponível não utilizada varia com base em muitos fatores, como região, hora do dia e tamanho do nó.

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

Os nós spot são ótimos para cargas de trabalho que podem lidar com interrupções, encerramentos antecipados ou remoções. Por exemplo, trabalhos de processamento em lotes, ambientes de desenvolvimento e teste e grandes cargas de trabalho de computação podem ser boas candidatas a serem agendadas em um pool de nós spot. 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 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 locais, consulte Adicionar um pool de nós spot a um cluster do Serviço de Kubernetes do Azure (AKS).

Discos do SO Efêmero

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

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

Para usar o SO efêmero, o disco do SO 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 GiB (gibibytes).

Por exemplo, o tamanho padrão da VM Standard_DS2_v2 AKS com o tamanho padrão de disco do sistema operacional de 100 GB oferece suporte a sistema operacional efêmero, mas tem apenas 86 GB de tamanho de cache. Essa configuração seria padronizada para discos gerenciados se você não especificasse explicitamente. Se você solicitar explicitamente o sistema operacional efêmero para esse tamanho, receberá um erro de validação.

Se você solicitar a mesma VM Standard_DS2_v2 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 é menor que o tamanho máximo do cache de 86 GB.

Standard_D8s_v3 com um disco 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 SO, o pool de nós receberá o SO efêmero por padrão.

O comando az aks nodepool add a seguir mostra como adicionar um novo pool de nós a um cluster existente com um disco de SO efêmero. O parâmetro --node-osdisk-type define o tipo de disco do SO como Ephemeral, e o parâmetro --node-osdisk-size 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 efêmeros do SO, consulte SO efêmeros.

Nós virtuais

Você pode usar nós virtuais para aumentar rapidamente as cargas de trabalho do aplicativo em um cluster do 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 dimensionador automático do cluster implante novos nós de trabalho para executar mais réplicas de pod. Os nós virtuais só têm suporte com os pods e nós do Linux. O complemento de nós virtuais para AKS é baseado no projeto de código aberto Kubelet virtual.

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 de Kubernetes do Azure (AKS) para usar nós virtuais.

Taints, etiquetas e marcações

Ao criar um pool de nós, você pode adicionar taints e etiquetas do Kubernetes e marcações do Azure a esse pool de nós. Quando você adiciona um taint, um rótulo ou uma marcação, todos os nós nesse pool recebem esse taint, esse rótulo ou essa marcação.

Para criar um pool de nós com um taint, você pode usar o comando az aks nodepool add com o parâmetro --node-taints. Para rotular os nós em um pool de nós, você pode usar o parâmetro --labels e especificar uma lista de etiquetas, 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 saber mais, confira Especificar um taint, um rótulo ou uma marca para um pool de nós.

Rótulos de sistema reservados

O Amazon EKS adiciona etiquetas automatizadas do Kubernetes 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 etiquetas do sistema aos nós do agente.

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

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

Para outros prefixos reservados, consulte Etiquetas, anotações e taints conhecidos do Kubernetes.

A tabela a seguir lista as etiquetas que são reservadas para uso do AKS e não podem ser usadas para nenhum nó. Na tabela, a coluna Uso do nó virtual especifica se a etiqueta tem suporte em nós virtuais.

Na coluna Uso do nó virtual:

• N/A significa que a propriedade não se aplica a nós virtuais porque seria necessário modificar o host.
• Same significa que os valores esperados são os mesmos para um pool de nós virtuais como 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.
• A versão do nó virtual refere-se à versão atual da versão virtual do conector Kubelet-ACI.
• Nome da sub-rede do nó virtual é o nome da 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 de 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 do CNI (adaptador de rede de contêineres) do Azure. Para planejar os intervalos de sub-rede e as considerações de rede necessários, consulte Configurar a rede de CNI do Azure.

O comando az aks nodepool add a seguir 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 de cluster de AKS. Para obter mais informações sobre como criar um cluster do 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 considerações e limitações a seguir se aplicam quando você cria e gerencia vários pools de nós:

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

• Os pools de sistemas devem conter pelo menos um nó. É possível excluir os pools de nós do sistema, desde que tenha outro pool de nós do sistema para assumir o lugar no cluster do AKS. Os pools de nós do usuário podem conter zero ou mais nós.

• Você não pode alterar o tamanho da VM de um pool de nós depois de criá-la.

• Para vários pools de nós, o cluster do AKS deve usar os balanceadores de carga de SKU Standard. Os balanceadores de carga SKU Básico não oferecem suporte a vários pools de nós.

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

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

Escala do pool de nós

À medida que a carga de trabalho do aplicativo muda, talvez seja necessário dimensionar o número de nós em um pool. Você pode dimensionar horizontal e verticalmente o número de nós de forma manual usando o comando az aks nodepool scale. O exemplo a seguir dimensiona o número de nós em mynodepool para 5:

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

Dimensionar pools de nós automaticamente usando o dimensionador automático de cluster

O AKS oferece suporte ao dimensionamento automático de pools de nós com o dimensionador automático 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 az aks nodepool add a seguir adiciona um novo pool de nós chamado mynodepool a um cluster existente. O parâmetro --enable-cluster-autoscaler habilita o dimensionador automático do cluster no novo pool de nós e os parâmetros --min-count 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 pool de nós mynewnodepool.

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

Você pode desabilitar o dimensionador automático do cluster com az aks nodepool update enviando o parâmetro --disable-cluster-autoscaler.

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

Para reativar o dimensionador automático de cluster em um cluster existente, use az aks nodepool update especificando os parâmetros --enable-cluster-autoscaler, --min-count e --max-count.

Para obter mais informações sobre como usar o dimensionador automático de cluster para pools de nós individuais, consulte Dimensionar automaticamente um cluster para atender às demandas de aplicativos no Serviço de 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 patch de componentes de software no ambiente de hospedagem e atualização de componentes de rede até o encerramento 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 de AKS existentes. Para atualizações que afetam VMs hospedadas, o Azure minimiza os casos que exigem reinicializações pausando a VM durante a atualização do host ou migrando em tempo real 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 manutenção automática normalmente é de 35 dias para computadores host, 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 CLI do Azure, PowerShell ou o portal do Azure. A manutenção planejada detectará se você está usando a atualização automática de cluster e agendará as atualizações automaticamente durante a janela de manutenção. 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 de Kubernetes do Azure (AKS).

Atualizações do Kubernetes

Parte do ciclo de vida do cluster do AKS envolve a execução de atualizações periódicas para a última versão do Kubernetes. É importante aplicar atualizações para obter os lançamentos e recursos de segurança mais recentes. Para atualizar a versão do Kubernetes das VMs de pool de nós existentes, você deve isolar e esgotar os nodes e substituí-los por novos nós baseados em uma imagem de disco do Kubernetes atualizada.

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

Por exemplo, um valor de max-surge de 100% proporciona 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 esvaziados simultaneamente. Talvez você queira usar esse valor alto para testes, mas para pools de nós de produção, uma configuração max-surge de 33% é melhor.

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

Durante uma atualização, o valor de max-surge pode ser de, no mínimo, 1 e, no 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 o 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ós ú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ções de imagens de nós do AKS (Serviço de Kubernetes do Azure)
• 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 do AKS.

• É recomendável atualizar todos os pools de nós em um cluster do 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, confira Atualizar um cluster do AKS (Serviço de Kubernetes do Azure).

• O comando az aks upgrade com o sinalizador --control-plane-only 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 Kubernetes no comando az aks nodepool upgrade.

• Uma atualização do cluster do AKS dispara o isolamento e esvaziamento de seus nós. Se você tiver uma cota de computação baixa 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 parâmetro max-surge com base em suas necessidades usando um valor inteiro ou percentual. Para pools de nós de produção, use uma configuração max-surge de 33%. Para saber mais, confira Personalizar a atualização de sobretensão de nó.

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

• Se os pools de nós de cluster abrangerem várias zonas de disponibilidade em uma região, o processo de atualização poderá causar temporariamente uma configuração de zona desbalanceada. 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ós

Ao criar um novo cluster ou adicionar um novo pool de nós a um cluster existente, você especifica a ID de recurso de uma sub-rede dentro da rede virtual do cluster onde implanta os nós do agente. Uma carga de trabalho pode exigir que os nós de um cluster sejam divididos em pools 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 VM do pool de nós obtém um endereço IP privado de sua sub-rede associada.

AKS suporta dois plug-ins de rede:

• Kubenet é um plugin de rede básico e simples para Linux. Com o kubenet, os nós obtêm um endereço IP privado de uma 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 principal do nó. Essa abordagem reduz o número de endereços IP que você precisa reservar no espaço de rede para pods.

• A Interface de Rede de Contêiner (CNI) 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 de rede. Cada nó tem um parâmetro de configuração para o número máximo de pods aos quais ele dá suporte. O número equivalente de endereços IP por nó é então reservado para esse nó. Essa abordagem exige mais planejamento e leva à exaustão do endereço IP ou à necessidade de recriar os clusters em uma sub-rede maior conforme as demandas de aplicativo aumentam.

  Ao criar um novo cluster ou adicionar um novo pool de nós a um cluster que usa a CNI do Azure, 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 a CNI do Azure obtêm endereços IP privados de uma sub-rede do pool de nós de hospedagem. A alocação dinâmica de IP da 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. Esse recurso oferece os seguintes benefícios:

• A sub-rede do pod aloca dinamicamente IPs aos pods. Isso leva a uma melhor utilização de IPs em comparação com a solução de CNI tradicional, que faz a 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 pods separada para um pool de nós.

• Como os pods têm IPs privados de rede virtual, eles têm conectividade direta com outros recursos e pods de cluster na rede virtual. Essa capacidade oferece suporte a 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ó. Isso permite muitos cenários úteis, como permitir a conectividade com a Internet apenas para pods e não para nós, corrigir o IP de origem para o pod em um pool de nós usando um Gateway da NAT do Azure e usar Grupos de Segurança de Rede (NSGs) para filtrar o tráfego entre pools de nós.

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

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

• Paolo Salvatori | Engenheiro-chefe de Sistemas

Outros colaboradores:

• Laura Nicolas | Engenheira sênior de software
• Chad Kittel | Engenheiro de Software Principal
• Ed Price | Gerente sênior de programa de conteúdo
• Theano Petersen | Escritor técnico

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

Próximas etapas

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

Recursos relacionados

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