Partilhar via

Gerir os nós e pools de nós do Kubernetes

A arquitetura do Kubernetes consiste em duas camadas: o plano de controle e pelo menos um nó em um pool de nós. Este artigo descreve e compara como o Amazon Elastic Kubernetes Service (EKS) e o Azure Kubernetes Service (AKS) gerenciam nós de agente e nós de trabalho.

Observação

Este artigo faz parte de uma série de artigos que ajudam os profissionais familiarizados com o Amazon EKS a entender o Serviço Kubernetes do Azure (AKS).

Tanto no Amazon EKS como no AKS, a plataforma de nuvem fornece e gestiona a camada do plano de controlo, e o cliente gestiona 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.

Diagrama que mostra o plano de controle e os nós na arquitetura 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 conectam e drenam nós para ajudar a 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 é operado e controlado pelo Amazon EKS. O autoscaler de clusters do Kubernetes ajusta automaticamente o número de nós trabalhadores num cluster quando os pods falham ou são reagendados para outros nós. Você pode configurar cada grupo de nós para ser executado em várias zonas de disponibilidade dentro de uma região.

Para obter mais informações, 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, consulte Simplificar o gerenciamento de computação.

Karpenter

Karpenter é um projeto de código aberto que ajuda a melhorar no gerenciamento do ciclo de vida dos nós em clusters Kubernetes. Ele automatiza o provisionamento e desaprovisionamento de nós com base nas necessidades específicas de escalonamento dos pods, o que melhora o dimensionamento e a otimização de custos. Use Karpenter para as seguintes funções principais:

  • Monitore pods que o agendador do Kubernetes não consegue agendar devido a restrições de recursos.

  • Avalie os requisitos de agendamento, como solicitações de recursos, seletores de nós, afinidades e tolerâncias dos pods não agendáveis.

  • Configure novos nós que atendam aos requisitos dos pods não escalonáveis.

  • Remova os nós quando não precisar mais deles.

Você pode usar o Karpenter para definir pools de nós que tenham restrições no provisionamento de nós, como taints, rótulos, requisitos (tipos de instância e zonas) e limites no total de recursos provisionados. Ao implementar cargas de trabalho, especifique várias limitações de agendamento nas especificações do pod. Por exemplo, você pode especificar solicitações ou limites de recursos, seletores de nós, afinidades de nó ou pod, tolerâncias e restrições de propagação de topologia. Em seguida, Karpenter configura nós de tamanho certo com base nessas especificações.

Antes do lançamento do Karpenter, os usuários do Amazon EKS dependiam principalmente dos grupos de auto scaling do Amazon EC2 e do autoscaler de cluster do Kubernetes para ajustar dinamicamente a capacidade de computação de seus clusters. Você não precisa criar dezenas de grupos de nós para alcançar a flexibilidade e a diversidade que o Karpenter oferece. Ao contrário do autoscaler de cluster do Kubernetes, o Karpenter é menos dependente das versões do Kubernetes e não requer transições entre as APIs da AWS e do Kubernetes.

Karpenter consolida as responsabilidades de orquestração de instâncias em um único sistema, que é mais simples, mais estável e mais sensível a clusters. A Karpenter ajuda a superar os desafios do autoscaler de cluster, fornecendo maneiras simplificadas de:

  • Configure nós com base nos requisitos de carga de trabalho.

  • Crie diferentes configurações de nós por tipo de instância usando opções flexíveis de pools de nós. Em vez de gerenciar vários grupos de nós personalizados específicos, use o Karpenter para gerenciar a capacidade de carga de trabalho diversificada usando um único pool de nós flexível.

  • Obtenha um melhor agendamento de pods em escala lançando rapidamente nós e agendando pods.

Em comparação com grupos de dimensionamento automático e grupos de nós gerenciados, o Karpenter integra o gerenciamento de dimensionamento mais de perto com APIs nativas do Kubernetes. Grupos de dimensionamento automático e grupos de nós gerenciados são abstrações nativas da AWS que acionam o dimensionamento com base em métricas de nível da AWS, como a carga da CPU do EC2. Embora o autoscaler de cluster faça a ponte entre abstrações do Kubernetes e abstrações da AWS, ele sacrifica alguma flexibilidade, como o agendamento para uma zona de disponibilidade específica.

O Karpenter simplifica o gerenciamento de nós eliminando componentes específicos da AWS, o que proporciona maior flexibilidade diretamente no Kubernetes. Use o Karpenter para clusters que executam cargas de trabalho que encontram períodos de alta e intensa demanda ou têm diversos requisitos de computação. Use grupos de nós gerenciados e grupos de dimensionamento automático para clusters que executam cargas de trabalho mais estáticas e consistentes. Dependendo de suas necessidades, você pode usar uma combinação de nós gerenciados dinamicamente e estaticamente.

Contentores Kata

Kata Containers é um projeto de código aberto que fornece um tempo de execução de contêiner altamente seguro. Ele combina a natureza leve dos contêineres com os benefícios de segurança das máquinas virtuais (VMs). O Kata Containers melhora o isolamento e a segurança da carga de trabalho iniciando cada contêiner com um sistema operacional convidado diferente, ao contrário dos contêineres tradicionais que compartilham o mesmo kernel Linux entre cargas de trabalho. O Kata Containers executa contêineres em uma VM compatível com Open Container Initiative (OCI), que fornece isolamento estrito entre contêineres na mesma máquina host. Kata Containers fornece os seguintes recursos:

  • Isolamento aprimorado da carga de trabalho: Cada contêiner é executado em sua própria VM leve para ajudar a garantir o isolamento no nível de hardware.

  • Segurança melhorada: O uso da tecnologia VM fornece uma camada extra de segurança, o que reduz o risco de fuga de contêineres.

  • Compatibilidade com as normas da indústria: O Kata Containers integra-se a ferramentas padrão do setor, como o formato de contêiner OCI e a Interface de Tempo de Execução de Contêiner do Kubernetes.

  • Suporte para várias arquiteturas e hipervisores: O Kata Containers suporta arquiteturas AMD64 e ARM, e você pode usá-lo com hipervisores como Cloud Hypervisor e Firecracker.

  • Fácil implementação e gestão: O Kata Containers simplifica a orquestração da carga de trabalho porque usa o sistema de orquestração do Kubernetes.

Para configurar e executar o Kata Containers na AWS, configure um cluster do Amazon EKS para usar o Firecracker. O Firecracker é uma tecnologia de virtualização de código aberto da Amazon que ajuda você a criar e gerenciar serviços seguros, multilocatários baseados em contêineres e em funções. Use o Firecracker para implantar cargas de trabalho em VMs leves, chamadas microVMs, que fornecem segurança aprimorada e isolamento de carga de trabalho em comparação com VMs tradicionais. As microVMs também melhoram a velocidade e a eficiência de recursos dos contêineres. Siga as etapas para executar o Kata Containers no AWS EKS.

Anfitriões dedicados

Ao usar o Amazon EKS para implantar e executar contêineres, você pode executar os contêineres em hosts dedicados do Amazon EC2. No entanto, esse recurso só está disponível para grupos de nós autogerenciados. Portanto, você deve criar manualmente um modelo de inicialização e grupos de dimensionamento automático. Em seguida, registe os hosts dedicados, o modelo de lançamento e os grupos de dimensionamento automático com o cluster EKS. Para criar esses recursos, use o mesmo método do dimensionamento automático geral do EC2.

Para obter mais informações sobre como usar o AWS EKS para executar contêineres em hosts dedicados do EC2, consulte os seguintes recursos:

Nós de AKS e grupos de nós

Quando você cria um cluster AKS automaticamente, ele cria e configura 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ê cria 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, você gerencia e paga totalmente pelos nós do agente que estão conectados ao cluster AKS.

Para executar aplicações e serviços de suporte, um cluster AKS precisa de pelo menos um nó, que é uma VM do Azure que executa os componentes do nó Kubernetes e o runtime de contêiner. Cada cluster AKS deve conter no mínimo um pool de nós do sistema que tenha pelo menos um nó.

O AKS agrupa nós com a mesma configuração em agrupamentos de máquinas virtuais que executam as cargas de trabalho do AKS. Use pools de nós do sistema para hospedar pods críticos do sistema, como CoreDNS. Use pools de nós de usuário para hospedar pods de carga de trabalho. Se pretender apenas um pool de nós no seu cluster AKS, por exemplo, num ambiente de desenvolvimento, poderá agendar pods de aplicações no pool de nós do sistema.

Diagrama que mostra um nó único do Kubernetes.

Você também pode criar diversos pools de nós de usuário para segregar cargas de trabalho distintas em nós diferentes. Essa abordagem ajuda a evitar o problema do vizinho barulhento e oferece suporte a aplicativos que têm diferentes demandas de computação ou armazenamento.

Cada nó de agente dentro de um sistema ou pool de nós de usuário é essencialmente uma VM. Os Conjuntos de Escala de Máquina Virtual do Azure configuram as VMs e o cluster AKS as gerencia. Para obter mais informações, consulte Agrupamentos 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.

Importante

Para fornecer melhor latência para chamadas de nó interno e comunicações com serviços de plataforma, escolha a série de VMs que ofereça suporte a Rede Acelerada.

Criar um pool de nós

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ó. Este grupo de recursos do Azure 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ó quando exclui um cluster. Você deve usar esse grupo de recursos somente para recursos que compartilham o ciclo de vida do cluster.

Para obter mais informações, consulte Criar pools de nós para um cluster no AKS.

Adicionar um agrupamento de nós

Para adicionar um pool de nós a um cluster AKS novo ou existente, use o portal do Azure, a CLI do Azure ou a API REST do AKS. Você também pode usar a infraestrutura como ferramentas de código (IaC), como Bicep, modelos do Azure Resource Manager ou Terraform.

O exemplo de código a seguir usa o comando Azure CLI az aks nodepool add para adicionar um pool de nós chamado mynodepool que tem três nós. Ele adiciona um pool de nós a um cluster 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 em regime spot

O pool de nós spot é um pool de nós que um conjunto de dimensionamento de máquina virtual spot suporta. Utilize VMs spot para nodes no seu cluster AKS para aproveitar a capacidade não utilizada do Azure a um custo reduzido. A quantidade de capacidade disponível não utilizada varia com base em fatores, como tamanho do nó, região e hora do dia.

Quando você implanta um pool de nós spot, o Azure aloca os nós spot se houver capacidade disponível. Mas os nós spot não têm um contrato de nível de serviço (SLA). Um conjunto de escala spot que suporta o pool de nós spot é implantado em um único domínio de falha e não fornece garantias de alta disponibilidade. Quando o Azure precisa de capacidade, a infraestrutura do Azure expulsa nós spot. Você recebe um aviso até 30 segundos antes do despejo. Não é possível usar um pool de nós spot como o pool de nós padrão do cluster. Use um pool de nós spot apenas como um pool secundário.

Use nós preemptivos para cargas de trabalho que podem lidar com interrupções, encerramentos antecipados ou remoções. Por exemplo, agende num pool de nós "spot" para tarefas de processamento em lote, ambientes de desenvolvimento e teste e grandes cargas computacionais. Para obter mais informações, consulte Limitações de instância spot.

O comando a seguir az aks nodepool add adiciona um pool de nós spot a um cluster existente que tem 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, consulte Adicionar um pool de nós spot a um cluster AKS.

Discos Efémeros de Sistema Operativo

Por padrão, o Azure replica automaticamente o disco do sistema operacional da VM para o Armazenamento do Azure. Essa abordagem evita a perda de dados se a VM precisar ser realocada para outro host. Mas os contêineres não são projetados para manter o estado local, portanto, armazenar o disco do sistema operacional no Armazenamento do Azure oferece benefícios limitados para o AKS. Essa abordagem pode levar a um provisionamento de nó mais lento e a uma maior latência de leitura e 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. Eles também fornecem menor latência de leitura e gravação e escalonamento de nó mais rápido e atualizações de cluster. Como um disco temporário, o preço da VM inclui um disco de sistema operacional efêmero, para que você não incorra em custos extras de armazenamento.

Importante

Se você não solicitar explicitamente discos gerenciados para o sistema operacional, o AKS assumirá como padrão um sistema operacional efêmero, se possível, para uma determinada configuração de pool de nós.

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 entrada/saída (E/S) como tamanho do cache em gibibytes (GiB).

Por exemplo, o tamanho padrão da VM Standard_DS2_v2 do AKS com o tamanho padrão do disco do SO de 100 GB acomoda um sistema operacional volátil, mas possui apenas um tamanho de cache de 86 GB. O padrão dessa configuração é para discos gerenciados 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 um tamanho de cache de 200 GB. Se você 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, consulte Disco do sistema operacional efêmero.

Pools de nós das Máquinas Virtuais do Azure no AKS

Cada grupo de nós gerenciados no EKS é apoiado por um grupo de auto scaling do Amazon EC2 gerenciado pelo Amazon EKS. Essa integração permite que o EKS configure e dimensione automaticamente instâncias do EC2 dentro do grupo de nós.

Você pode configurar grupos de dimensionamento automático para oferecer suporte a vários tipos de instância do EC2, mas não pode especificar quantos nós criar ou dimensionar para cada tipo de instância. Em vez disso, o EKS gerencia o dimensionamento do grupo de nós com base na configuração e nas políticas desejadas. Essa abordagem simplifica e automatiza o processo de gerenciamento para o grupo de nós para que você possa escolher tipos de instância do EC2 que atendam aos seus requisitos de carga de trabalho. Você também pode iniciar nós autogeridos do Amazon Linux usando a ferramenta de eksctl linha de comando ou o Console de Gestão da AWS.

Para pools de nós de Máquinas Virtuais do Azure, o AKS configura e inicializa os nós de cada agente. Para os pools de nós nos Conjuntos de Escala de Máquinas Virtuais do Azure, o AKS gere o modelo destes conjuntos e utiliza-o para garantir consistência em todos os nós de agente no pool de nós. Você pode usar pools de nós de Máquinas Virtuais para orquestrar seu cluster com VMs que melhor se ajustam às suas cargas de trabalho individuais. Você também pode especificar quantos nós deseja criar ou dimensionar para cada tamanho de VM.

Um pool de nós consiste em um conjunto de VMs que têm tamanhos diferentes. Cada VM suporta um tipo diferente de carga de trabalho. Esses tamanhos de VM, conhecidos como SKUs, são categorizados em diferentes famílias que são otimizadas para fins específicos. Para obter mais informações, consulte Tamanhos de VM no Azure.

Para habilitar o dimensionamento de vários tamanhos de VM, o tipo de pool de nós Máquinas Virtuais usa um ScaleProfile. Esse perfil configura como o pool de nós é dimensionado especificando o tamanho e a contagem de VM desejados. A ManualScaleProfile é um perfil de escala que especifica o tamanho e a contagem de VM desejados. Apenas um tamanho de VM é permitido em um ManualScaleProfile. Você precisa criar um ManualScaleProfile separadamente para cada tamanho de VM no seu grupo de nós.

Quando criar um novo pool de nós de máquinas virtuais, é necessário ter pelo menos um ManualScaleProfile no ScaleProfile. Você pode criar vários perfis de escala manual para um único pool de nós de Máquinas Virtuais.

As vantagens dos pools de nós de máquinas virtuais são:

  • Flexibilidade: Você pode atualizar as especificações do nó para atender às suas cargas de trabalho e necessidades.

  • Controlo ajustado: Os controlos a nível de nó único ajudam a especificar e combinar nós de diferentes especificações para aumentar a consistência.

  • Eficiência: Pode reduzir a pegada dos nós no seu cluster para simplificar os seus requisitos operacionais.

Os pools de nós de Máquinas Virtuais oferecem uma experiência melhor para cargas de trabalho dinâmicas e requisitos de alta disponibilidade. Você pode usá-los para configurar várias VMs da mesma família em um pool de nós, e sua carga de trabalho é agendada automaticamente nos recursos disponíveis que você configurar.

A tabela seguinte compara pools de nós de máquinas virtuais com os pools de nós padrão de conjuntos de escala de máquinas virtuais.

Tipo de conjunto de nós Capacidades
Pool de nós de máquinas virtuais Você pode adicionar, remover ou atualizar nós em um pool de nós. Os tipos de VM podem ser qualquer VM do mesmo tipo de família, como a série D ou a série A.
Pool de nós de conjuntos de dimensionamento de máquina virtual Você pode adicionar ou remover nós do mesmo tamanho e digitar um pool de nós. Se você adicionar um novo tamanho de VM ao cluster, precisará criar um novo pool de nós.

Os pools de nós de Máquinas Virtuais têm as seguintes limitações:

  • O autoscaler de cluster não é suportado.
  • InfiniBand não está disponível.
  • Os pools de nós do Windows não são suportados.
  • Esse recurso não está disponível no portal do Azure. Utilize o CLI do Azure e as APIs REST para executar operações de criação, leitura, atualização e exclusão (CRUD) ou gerir o pool.
  • O instantâneo do pool de nós não é suportado.
  • Todos os tamanhos de VM em um pool de nós devem ser da mesma família de VMs. Por exemplo, não é possível combinar um tipo de VM da série N com um tipo de VM da série D no mesmo pool de nós.
  • Os pools de nós de Máquinas Virtuais permitem até cinco tamanhos diferentes de VM por pool de nós.

Nodos virtuais

Você pode usar nós virtuais para expandir rapidamente cargas de trabalho de aplicativos em um cluster AKS. Os nós virtuais fornecem 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. Apenas nós e pods Linux suportam nós virtuais. 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, consulte Criar e configurar um cluster AKS para usar nós virtuais.

Manchas, rótulos e tags

Ao criar um pool de nós, pode-se adicionar taints e rótulos do Kubernetes e tags Azure. Cada mancha, rótulo ou tag se aplica a todos os nós dentro desse pool de nós.

Para criar um pool de nós que tenha uma mancha, 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, use o --labels parâmetro e especifique 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 em nós.

  • 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 nós. Na tabela, a coluna Uso do nó virtual especifica se os nós virtuais oferecem suporte ao rótulo.

Na coluna Uso do nó virtual:

  • N/D significa que a propriedade não se aplica a nós virtuais porque requer a modificação do host.
  • O mesmo significa que os valores esperados são os mesmos para um pool de nós virtuais e 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 as VMs subjacentes.
  • Versão do nó virtual refere-se à versão atual do lançamento do conector virtual Kubelet-ACI.
  • O nome da sub-rede do nó virtual é a sub-rede que implanta pods de nó virtual em instâncias de contêiner.
  • Nó virtual da rede virtual é a rede virtual que contém a sub-rede do nó virtual.
Etiqueta Valor Exemplo ou opções Uso do nó virtual
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Mesma
kubernetes.io/arch amd64 runtime.GOARCH N/A
kubernetes.io/os <OS type> Linux ou Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 Mesma
topology.kubernetes.io/zone <Azure zone> 0 Mesma
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Mesma
kubernetes.azure.com/mode <mode> User ou System User
kubernetes.azure.com/role agent Agent Mesma
kubernetes.azure.com/scalesetpriority <scale set priority> Spot ou Regular N/A
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Mesma
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N/A
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N/A
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 Versão do nó virtual
kubernetes.azure.com/subnet <nodepool subnet name> subnetName Nome da sub-rede do nó virtual
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName Rede virtual de nó virtual
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N/A
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N/A
kubernetes.azure.com/accelerator <accelerator> nvidia N/A
kubernetes.azure.com/fips_enabled <fips enabled> True N/A
kubernetes.azure.com/os-sku <os/sku> Consulte Criar ou atualizar o SKU do Sistema Operativo Linux SKU

Os conjuntos de nós do Windows

Você pode usar o AKS para criar e usar pools de nós de contêiner do Windows Server através do plugin de rede da 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 Interface de Rede de Contêiner 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 que tenha 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 únicos ou múltiplos:

  • Cotas, restrições de tamanho de VM e disponibilidade por região são aplicáveis a pools de nós AKS.

  • Os agrupamentos 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 balanceadores de carga SKU padrão. Os balanceadores de carga básicos SKU não suportam múltiplos grupos 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 um pool de nós devem estar na mesma rede virtual.

  • Se você criar vários pools de nós ao criar um cluster, as versões do Kubernetes para todos os pools de nós deverão corresponder à versão do plano de controle. Para atualizar versões depois de configurar o cluster, use operações por grupo de nós.

Dimensionar grupos 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. Para dimensionar manualmente o número de nós para cima ou para baixo, use o comando az aks nodepool scale . O exemplo a seguir redimensiona o número de nós em mynodepool para cinco.

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

Dimensionar automaticamente os agrupamentos de nós

O AKS suporta o dimensionamento automático de pools de nós usando o autoscaler de cluster. Habilite esse recurso em cada pool de nós e defina 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 parâmetro --enable-cluster-autoscaler ativa o autoscaler do cluster no novo pool de nós. 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 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

Para desativar o autoscaler do cluster, use o az aks nodepool update comando com o --disable-cluster-autoscaler parâmetro.

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

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

Para obter mais informações sobre como usar o autoscaler de cluster para pools de nós individuais, consulte Usar o autoscaler de cluster no AKS.

Sandboxing de Pods

Para configurar e executar facilmente o Kata Containers no AKS como uma solução totalmente gerenciada, use o Pod Sandboxing. O Pod Sandboxing é um recurso AKS que cria um limite de isolamento entre o aplicativo de contêiner e o kernel compartilhado e os recursos de computação do host do contêiner, como CPU, memória e rede.

O Pod Sandboxing complementa outras medidas de segurança ou controles de proteção de dados para ajudar as cargas de trabalho do locatário a proteger informações confidenciais e atender aos requisitos de conformidade regulamentar, do setor ou de governança. Esses requisitos incluem o Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS), a Organização Internacional de Padronização (ISO) 27001 e a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA).

Implante aplicações em clusters ou pools de nós separados para ajudar a isolar as cargas de trabalho de diferentes equipes ou clientes. Pode usar vários clusters e grupos de nós caso a sua organização ou solução de software como serviço (SaaS) o exija. Mas alguns cenários se beneficiam de um único cluster que tem pools de nós de VM compartilhados. Por exemplo, pode usar um único cluster para executar pods não confiáveis e confiáveis no mesmo nó ou colocar DaemonSets e contêineres privilegiados no mesmo nó para uma comunicação local e agrupamento funcional mais rápidos.

O Pod Sandboxing pode ajudá-lo a isolar aplicativos locatários nos mesmos nós de cluster sem a necessidade de executar essas cargas de trabalho em clusters ou pools de nós separados. Outros métodos podem exigir que você recompile seu código ou podem criar outros problemas de compatibilidade. O Pod Sandboxing no AKS pode executar qualquer contentor não modificado dentro de uma VM com limites de segurança melhorados.

O Pod Sandboxing é baseado em Kata Containers que é executado no host de contêiner do Linux do Azure para a pilha AKS para fornecer isolamento imposto por hardware. O Kata Containers no AKS foi criado em um hipervisor do Azure com segurança reforçada. Alcança o isolamento para cada pod através de uma VM Kata aninhada e leve que utiliza os recursos de um nó de VM principal. Neste modelo, cada pod Kata obtém o seu próprio kernel numa VM convidada Kata aninhada. Use este modelo para colocar vários contentores Kata numa única máquina virtual hóspede, enquanto continua a executar contentores na máquina virtual principal. Este modelo fornece um forte limite de isolamento em um cluster AKS compartilhado.

Para obter mais informações, consulte Suporte para contêineres isolados Kata VM no AKS for Pod Sandboxing.

Host Dedicado do Azure

O Host Dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma única assinatura do Azure para ajudar a garantir o isolamento de hardware no nível do servidor físico. Você pode provisionar esses hosts dedicados dentro de uma região, zona de disponibilidade e domínio de falha. Você pode colocar VMs diretamente nos hosts provisionados.

Use o Host Dedicado com o AKS para fornecer os seguintes benefícios:

  • O isolamento de hardware garante que nenhuma outra VM seja colocada nos hosts dedicados, o que fornece uma camada extra de isolamento para cargas de trabalho de locatário. Os hosts dedicados são implantados nos mesmos datacenters e compartilham a mesma rede e a mesma infraestrutura de armazenamento subjacente que outros hosts não isolados.

  • O Host Dedicado fornece controle sobre os eventos de manutenção que a plataforma Azure inicia. Você pode escolher uma janela de manutenção para reduzir o impacto nos serviços e ajudar a garantir a disponibilidade e a privacidade das cargas de trabalho do locatário.

O Host Dedicado pode ajudar os provedores de SaaS a garantir que os aplicativos de locatário atendam aos requisitos de conformidade regulamentar, do setor e de governança para proteger informações confidenciais. Para obter mais informações, consulte Adicionar host dedicado a um cluster AKS.

Karpenter

Karpenter é um projeto de gerenciamento de ciclo de vida de nó de código aberto criado para o Kubernetes. Adicione o Karpenter a um cluster do Kubernetes para melhorar a eficiência e o custo da execução de cargas de trabalho nesse cluster. Karpenter observa os pods que o agendador do Kubernetes marca como não agendáveis. Ele também provisiona e gerencia dinamicamente nós que podem atender aos requisitos do pod.

O Karpenter fornece controle refinado sobre o provisionamento de nós e o posicionamento da carga de trabalho em um cluster gerenciado. Esse controle otimiza a alocação de recursos, ajuda a garantir o isolamento entre os aplicativos de cada locatário e reduz os custos operacionais, o que melhora a multilocação. Quando você cria uma solução multilocatária no AKS, a Karpenter fornece recursos úteis para ajudar a gerenciar diversos requisitos de aplicativos para oferecer suporte a diferentes locatários.

Por exemplo, você pode precisar que alguns aplicativos de locatários sejam executados em pools de nós otimizados para GPU e outros para serem executados em pools de nós otimizados para memória. Se a sua aplicação requer baixa latência para armazenamento, pode utilizar o Karpenter para indicar que um pod requer um nó que opera numa zona de disponibilidade específica. Em seguida, pode colocalizar a sua camada de armazenamento e de aplicação.

O AKS permite o provisionamento automático de nós em clusters AKS via Karpenter. A maioria dos usuários deve usar o modo de provisionamento automático do nó para habilitar o Karpenter como um complemento gerenciado. Para obter mais informações, consulte aprovisionamento automático de nós. Se você precisar de personalização mais avançada, você pode auto-hospedar Karpenter. Para obter mais informações, consulte Provedor AKS Karpenter.

VMs confidenciais

A computação confidencial é uma medida de segurança que ajuda a proteger os dados durante a utilização através de isolamento e encriptação assistidos por software ou hardware. Esta tecnologia adiciona uma camada extra de segurança às abordagens tradicionais, o que ajuda a proteger os dados em repouso e os dados em trânsito.

A plataforma da AWS oferece suporte à computação confidencial por meio do Nitro Enclaves, que estão disponíveis em instâncias do EC2 e no Amazon EKS. As instâncias do Amazon EC2 também suportam AMD Secure Encrypted Virtualization Secure Nested Paging (SEV-SNP). O repositório GitHub Runtime Attestation fornece artefatos para criar e implantar uma Amazon Machine Image para EKS com suporte para AMD SEV-SNP.

O Azure fornece aos clientes VMs confidenciais para ajudar a atender aos requisitos estritos de isolamento, privacidade e segurança em um cluster AKS. Essas VMs confidenciais usam um ambiente de execução confiável baseado em hardware. Especificamente, as VMs confidenciais do Azure usam a tecnologia AMD SEV-SNP. Essa tecnologia nega ao hipervisor e a outros códigos de gerenciamento de host acesso à memória e ao estado da VM. Use essa abordagem para adicionar uma camada extra de defesa e proteção contra o acesso do operador. Para obter mais informações, consulte Usar VMs confidenciais em um cluster AKS e Visão geral de VMs confidenciais no Azure.

Normas Federais de Processo de Informação

Federal Information Process Standards (FIPS) 140-3 é um padrão do governo dos EUA que define requisitos mínimos de segurança para módulos criptográficos em produtos e sistemas de tecnologia da informação. Habilite a conformidade FIPS para pools de nós AKS para melhorar o isolamento, a privacidade e a segurança das suas cargas de trabalho. A conformidade com FIPS ajuda a garantir o uso de módulos criptográficos validados para criptografia, hash e outras operações relacionadas à segurança. Use pools de nós AKS habilitados para FIPS para empregar algoritmos e mecanismos criptográficos robustos, que ajudam a atender aos requisitos regulatórios e de conformidade do setor. Para obter mais informações sobre como fortalecer a postura de segurança dos seus ambientes AKS multicliente, consulte Ativar FIPS para pools de nós AKS.

Encriptação baseada no anfitrião

No EKS, sua arquitetura pode usar os seguintes recursos para melhorar a segurança dos dados:

A criptografia baseada em host no AKS fortalece ainda mais o isolamento, a privacidade e a segurança da carga de trabalho do locatário. Quando você habilita a criptografia baseada em host, o AKS criptografa dados em repouso nas máquinas host subjacentes. Essa abordagem ajuda a proteger informações confidenciais do locatário contra acesso não autorizado. Quando você habilita a criptografia de ponta a ponta, discos temporários e discos efêmeros do sistema operacional são criptografados em repouso por meio de chaves gerenciadas pela plataforma.

No AKS, os discos do SO e os discos de dados utilizam encriptação do lado do servidor através de chaves geridas pela plataforma por predefinição. Os caches desses discos são criptografados em repouso por meio de chaves gerenciadas pela plataforma. Você pode usar sua própria chave de criptografia de chave para criptografar a chave de proteção de dados. Esse método é chamado de criptografia de envelope ou encapsulamento. A chave de criptografia especificada também criptografa o cache dos discos do sistema operacional e dos discos de dados.

A criptografia baseada em host adiciona uma camada de segurança para ambientes multilocatário. Os dados de cada locatário no disco do sistema operacional e nos caches de disco de dados são criptografados em repouso por meio de chaves gerenciadas pelo cliente ou gerenciadas pela plataforma, dependendo do tipo de criptografia de disco selecionado. Para obter mais informações, consulte os seguintes recursos:

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, consulte Manutenção para VMs no Azure.

As atualizações da infraestrutura de hospedagem de VM geralmente não afetam as VMs hospedadas, como os nós de agente dos 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 migra 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 quando você pode iniciar a atualização. 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. Gerencie notificações de manutenção planejada usando a CLI do Azure, o Azure PowerShell ou o portal do Azure. A manutenção planejada deteta se você usa o recurso de atualização automática do cluster e agenda atualizações durante a janela de manutenção automaticamente. Para obter mais informações, consulte Utilize a manutenção planeada para agendar janelas de manutenção para o seu cluster AKS e o comando az aks maintenanceconfiguration.

Atualizações do Kubernetes

Parte do ciclo de vida do cluster AKS inclui a atualização periódica para a versão mais recente do Kubernetes. Você deve 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, deve-se cordonar e drenar os 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 a adição de um nó extra. Um valor padrão de um para as max-surge configurações minimiza a interrupção do fluxo de trabalho. Esta configuração cria um nó extra para substituir os nós com versões mais antigas antes de isolar ou esvaziar as aplicações existentes. Você pode personalizar o max-surge valor por pool de nós para otimizar a compensação entre a velocidade de atualização e a interrupção da atualização. Um valor mais alto max-surge aumenta a velocidade do processo de atualização, mas um valor grande para max-surge pode causar interrupções durante o processo de atualização.

Por exemplo, um valor max-surge de 100% fornece o processo de atualização mais rápido possível ao dobrar a contagem de nós. Mas esse valor também drena todos os nós no pool de nós simultaneamente. Talvez queira usar este valor elevado para testes, mas para conjuntos de nós de produção use uma configuração de max-surge de 33%.

O AKS aceita valores inteiros e percentuais para o max-surge valor. Um número inteiro como 5 indica cinco nós extras a serem aumentados. Você pode definir o valor de porcentagem para max-surge de 1% a 100%, arredondado para cima para o número de nós mais próximo. Um valor de 50% indica um pico de metade da contagem atual de nós no pool.

Durante uma atualização, pode-se definir o valor de max-surge com um mínimo de 1 e um valor 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 para max-surge não pode exceder o número de nós no pool.

Importante

Para operações de atualização, os picos de nó precisam de cota de assinatura suficiente para a contagem solicitada max-surge . Por exemplo, um cluster que tem cinco pools de nós, cada um com quatro nós, tem um total de 20 nós. Se cada pool de nós tiver um max-surge valor de 50%, você precisará de computação extra e uma cota IP de 10 nós, ou dois nós vezes cinco pools, para concluir a atualização.

Se você usar a Interface de Rede de Contêiner do Azure, verifique se você tem IPs suficientes na sub-rede para atender aos requisitos do AKS.

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

Para atualizar um pool de nós individual, use az aks nodepool upgrade.

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

Para obter mais informações, consulte os seguintes recursos:

Considerações sobre a atualização

Considere as seguintes práticas recomendadas ao atualizar a versão do Kubernetes em um cluster AKS:

  • Você deve 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 conjuntos de nós e o plano de controlo.

  • Execute atualizações 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 AKS.

  • O az aks upgrade comando com o --control-plane-only sinalizador atualiza o plano de controle do cluster e não altera os 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 no AKS aciona um processo de cordon e drain dos seus nós. Se você tiver uma cota de computação baixa disponível, a atualização poderá falhar. Para obter mais informações, veja Aumentar as quotas regionais de vCPU.

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

  • Ao atualizar um cluster AKS que usa a rede da Interface de Rede de Contêiner do Azure, 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 da Interface de Rede de Contêiner do Azure no 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á criar temporariamente uma configuração de zona desequilibrada. Para obter mais informações, consulte Pools de nós que abrangem várias zonas de disponibilidade.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

Outros contribuidores:

  • Laura Nicolas | Engenheira de Software Sénior
  • Chad Kittel | Engenheiro Principal de Software - Azure Patterns & Practices
  • Ed Price | Gerente de Programa de Conteúdo Senior
  • Theano Petersen | Redator Técnico

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos