Editar

Partilhar via

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

Azure Kubernetes Service (AKS)
Azure Virtual Machines

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.

Nota

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

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.

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

Karpenter

Karpenter é um projeto de código aberto projetado para aprimorar o gerenciamento do ciclo de vida do nó em clusters Kubernetes. Ele automatiza o provisionamento e o desprovisionamento de nós com base nas necessidades específicas de agendamento de pods, permitindo dimensionamento eficiente e otimização de custos. As suas principais funções são:

  • Monitore pods que o agendador do Kubernetes não pode agendar devido a restrições de recursos.
  • Avalie os requisitos de agendamento (solicitações de recursos, seletores de nós, afinidades, tolerâncias, etc.) dos pods não escalonáveis.
  • Provisione novos nós que atendam aos requisitos desses pods.
  • Remova os nós quando eles não forem mais necessários.

Com o Karpenter, você define NodePools com restrições no provisionamento de nós, como taints, rótulos, requisitos (tipos de instância, zonas, etc.) e limites no total de recursos provisionados. Ao implantar cargas de trabalho, você especifica várias restrições de agendamento nas especificações do pod, como solicitações/limites de recursos, seletores de nós, afinidades de nó/pod, tolerâncias e restrições de dispersão de topologia. Karpenter então provisiona nós de tamanho certo com base nessas especificações.

Antes do lançamento do Karpenter, os usuários do Amazon EKS dependiam principalmente de grupos do Amazon EC2 Auto Scaling e do do Kubernetes Cluster Autoscaler (CAS) 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 você obtém com o Karpenter. Ao contrário do Kubernetes Cluster Autoscaler, o Karpenter não está tão fortemente acoplado às versões do Kubernetes e não exige que você salte 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 reconhece clusters. Karpenter foi projetado para superar alguns dos desafios apresentados pelo Cluster Autoscaler, fornecendo maneiras simplificadas de:

  • Provisione nós com base nos requisitos de carga de trabalho.
  • Crie diversas configurações de nó por tipo de instância, usando opções flexíveis do NodePool. Em vez de gerenciar muitos grupos de nós personalizados específicos, o Karpenter poderia permitir que você gerenciasse diversas capacidades de carga de trabalho com um único NodePool flexível.
  • Obtenha um melhor agendamento de pods em escala lançando rapidamente nós e agendando pods.

Para obter informações e documentação sobre o uso do Karpenter, visite o site da karpenter.sh.

O Karpenter aproxima o gerenciamento de dimensionamento das APIs nativas do Kubernetes do que os ASGs (Auto Scaling Groups) e Managed Node Groups (MNGs). ASGs e MNGs são abstrações nativas da AWS em que o dimensionamento é acionado com base em métricas de nível da AWS, como a carga da CPU do EC2. Cluster Autoscaler faz a ponte entre as abstrações do Kubernetes e as abstrações da AWS, mas perde alguma flexibilidade por causa disso, como o agendamento para uma zona de disponibilidade específica.

O Karpenter remove uma camada de abstração da AWS para trazer parte da flexibilidade diretamente para o Kubernetes. Karpenter é melhor usado para clusters com cargas de trabalho que encontram períodos de alta e alta demanda ou têm diversos requisitos de computação. MNGs e ASGs são bons para clusters que executam cargas de trabalho que tendem a ser mais estáticas e consistentes. Você pode usar uma combinação de nós gerenciados dinamicamente e estaticamente, dependendo de suas necessidades.

Contentores Kata

Kata Containers é um projeto de código aberto que fornece um tempo de execução de contêiner seguro que combina a natureza leve dos contêineres com os benefícios de segurança das máquinas virtuais. Ele aborda a necessidade de isolamento e segurança de carga de trabalho mais fortes inicializando 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. Os contêineres Kata executam contêineres em uma máquina virtual compatível com OCI, fornecendo isolamento estrito entre contêineres na mesma máquina host. Kata Containers fornecer os seguintes recursos:

  • Isolamento de carga de trabalho aprimorado: Cada contêiner é executado em sua própria VM leve, garantindo o isolamento no nível de hardware.
  • de segurança aprimorada: O uso da tecnologia VM fornece uma camada adicional de segurança, reduzindo o risco de fuga de contêineres.
  • Compatibilidade com os padrões da indústria: Os contêineres Kata integram-se a ferramentas padrão do setor, como o formato de contêiner OCI e a interface CRI do Kubernetes.
  • Suporte para várias arquiteturas e hipervisores: Kata Containers suportam arquiteturas AMD64 e ARM e podem ser usados com hipervisores como Cloud-Hypervisor e Firecracker.
  • Fácil implantação e gerenciamento: Kata Containers abstrai a complexidade de orquestrar cargas de trabalho aproveitando o sistema de orquestração do Kubernetes.

Os clientes da AWS podem configurar e executar de contêineres Kata na AWS configurando um cluster Amazon Elastic Kubernetes Service (EKS) para usar Firecracker, uma tecnologia de virtualização de código aberto desenvolvida pela Amazon para criar e gerenciar contêineres seguros e multilocatários e serviços baseados em funções. O Firecracker permite que os clientes implantem cargas de trabalho em máquinas virtuais leves, chamadas microVMs, que fornecem segurança aprimorada e isolamento de carga de trabalho em relação às máquinas virtuais tradicionais, ao mesmo tempo em que permitem a velocidade e a eficiência de recursos dos contêineres. Habilitar o Kata Containers no AWS EKS requer uma série de etapas manuais descritas em Aprimorando o isolamento e a segurança da carga de trabalho do Kubernetes usando o Kata Containers.

Anfitriões Dedicados

Execução de contêineres em hosts dedicados do Amazon EC2 com o AWS EKS

Ao usar do Amazon Elastic Kubernetes Service (EKS) para implantar e executar contêineres, é possível executá-los em hosts dedicados do Amazon EC2. No entanto, é importante observar que esse recurso só está disponível para grupos de nós autogerenciados. Isso significa que os clientes precisam criar manualmente um modelo de inicialização de , Grupos de Auto Scalinge registrá-los no cluster EKS. O processo de criação desses recursos é o mesmo que para o dimensionamento automático geral do EC2.

Para obter informações mais detalhadas sobre a execução de contêineres em hosts dedicados do EC2 com o AWS EKS, consulte a seguinte documentação:

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.

Diagrama mostrando um único nó do Kubernetes.

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.

Importante

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

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.

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

Pools de nós de máquinas virtuais no Serviço Kubernetes do Azure (AKS)

Todos os grupo de nós gerenciados no EKS são apoiados por um grupo Amazon EC2 Auto Scaling, que é gerenciado pelo Amazon EKS. Essa integração permite que o EKS manipule automaticamente o provisionamento e o dimensionamento de instâncias do EC2 dentro do grupo de nós. Embora os grupos de Auto Scaling possam ser configurados para suportar vários tipos de instância do EC2, eles não fornecem a capacidade de 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 desejada e nas políticas definidas pelo usuário. Isso garante um processo de gerenciamento simplificado e automatizado para o grupo de nós e, ao mesmo tempo, oferece flexibilidade na seleção dos tipos de instância do EC2 que atendem aos seus requisitos de carga de trabalho. No entanto, os clientes da AWS podem executar nós autogerenciados do Amazon Linux com o eksctl ou o Console de Gerenciamento da AWS.

Com pools de nós de Máquinas Virtuais, o Serviço Kubernetes do Azure (AKS) gerencia o provisionamento e a inicialização de cada nó de agente. Para pools de nós de Conjuntos de Escala de Máquina Virtual, o AKS gerencia o modelo dos Conjuntos de Escala de Máquina Virtual e o usa para obter consistência em todos os nós de agente no pool de nós. Em vez disso, os pools de nós de Máquinas Virtuais permitem orquestrar seu cluster com máquinas virtuais que melhor se ajustam às suas cargas de trabalho individuais e especificam quantos nós criar ou dimensionar para cada tamanho de máquina virtual.

Um pool de nós consiste em um conjunto de máquinas virtuais, com diferentes tamanhos (SKUs) designados para suportar diferentes tipos de cargas de trabalho. Esses tamanhos de máquina virtual, conhecidos como SKUs, são categorizados em diferentes famílias que são otimizadas para fins específicos. Para obter mais informações sobre SKUs de VM, consulte a visão geral de SKUs de VM .

Para habilitar o dimensionamento de vários tamanhos de máquina virtual, o tipo de pool de nós Máquinas Virtuais usa um ScaleProfile que configura como o pool de nós é dimensionado, especificamente a lista desejada de tamanho e contagem de máquinas virtuais. Um ManualScaleProfile é um perfil de escala que especifica o tamanho e a contagem de máquinas virtuais desejados. Apenas um tamanho de máquina virtual é permitido em um ManualScaleProfile. Você precisa criar um ManualScaleProfile separado para cada tamanho de máquina virtual em seu pool de nós.

Ao criar um novo pool de nós de Máquinas Virtuais, você precisa de pelo menos um ManualScaleProfile no ScaleProfile. Vários perfis de escala manual podem ser criados para um único pool de nós de Máquinas Virtuais.

As vantagens dos pools de nós de Máquinas Virtuais incluem:

  • Flexibilidade: As especificações do nó podem ser atualizadas para atender às suas cargas de trabalho e necessidades.
  • Controle ajustado: Os controles de nível de nó único permitem especificar e misturar nós de diferentes especificações para melhorar a consistência.
  • Efficiency: Você pode reduzir o espaço ocupado pelo nó para seu cluster, simplificando 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. Eles permitem que você configure várias máquinas virtuais da mesma família em um pool de nós, com sua carga de trabalho agendada automaticamente nos recursos disponíveis que você configurar.

A tabela a seguir compara pools de nós de Máquinas Virtuais com pools de nós de Conjunto de Dimensionamento padrão.

Tipo de pool 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 máquinas virtuais podem ser qualquer máquina virtual do mesmo tipo de família (por exemplo, série D, série A, etc.).
Pool de nós baseado no conjunto 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 máquina virtual 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:

  • de autodimensionamento de cluster não é suportada.
  • InfiniBand não está disponível.
  • Não há suporte para pools de nós do Windows.
  • Esse recurso não está disponível no portal do Azure. Use da CLI do Azure ou APIs REST para executar operações CRUD ou gerenciar o pool.
  • de instantâneo do pool de nós não é suportada.
  • Todos os tamanhos de VM selecionados em um pool de nós devem ser da mesma família de máquinas virtuais. Por exemplo, não é possível misturar um tipo de máquina virtual da série N com um tipo de máquina virtual 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 máquinas virtuais por pool de nós.

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.
Etiqueta Value Exemplo, 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 SO Linux SKU

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

Pod Sandboxing

Os clientes do AKS podem facilmente configurar e executar Kata Containers no AKS de uma forma totalmente gerenciada. Isso é possível graças ao uso do Pod Sandboxing, um recurso que cria um limite de isolamento entre o aplicativo contêiner e o kernel compartilhado e os recursos de computação do host do contêiner.

O AKS inclui um mecanismo chamado Pod Sandboxing que fornece 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, como 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).

Ao implantar aplicativos em clusters ou pools de nós separados, você pode isolar fortemente as cargas de trabalho de locatários de diferentes equipes ou clientes. O uso de vários clusters e pools de nós pode ser adequado para os requisitos de isolamento de muitas organizações e soluções SaaS, mas há cenários em que um único cluster com pools de nós de VM compartilhados é mais eficiente. Por exemplo, você pode usar um único cluster quando executa pods não confiáveis e confiáveis no mesmo nó ou colocalizar DaemonSets e contêineres privilegiados no mesmo nó para uma comunicação local e agrupamento funcional mais rápidos. de Sandboxing de Pod pode ajudá-lo a isolar fortemente os 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 exigem que você recompile seu código ou cause outros problemas de compatibilidade, mas o Pod Sandboxing no AKS pode executar qualquer contêiner sem modificações dentro de um limite de VM de segurança aprimorada.

O Pod Sandboxing no AKS é baseado em Kata Containers que são executados no host de contêiner Linux do Azure para a pilha de do AKS para fornecer isolamento imposto por hardware. Os Contêineres Kata no AKS são criados em um hipervisor do Azure com segurança reforçada. Ele alcança o isolamento por pod por meio de uma VM Kata aninhada e leve que utiliza recursos de um nó de VM pai. Neste modelo, cada pod Kata obtém seu próprio kernel em uma VM convidada Kata aninhada. Use esse modelo para colocar muitos contêineres Kata em uma única VM convidada enquanto continua a executar contêineres na VM pai. Este modelo fornece um forte limite de isolamento em um cluster AKS compartilhado.

Para mais informações, consulte:

Host Dedicado do Azure

de Host Dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma única assinatura do Azure e fornece 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, e pode colocar VMs diretamente nos hosts provisionados.

Há vários benefícios em usar o Host Dedicado do Azure com o AKS, incluindo:

  • 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 do Azure fornece controle sobre os eventos de manutenção que a plataforma do 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 do Azure 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 do Azure a um cluster AKS.

Karpenter

Karpenter é um projeto de gerenciamento do ciclo de vida do nó de código aberto criado para o Kubernetes. Adicionar o Karpenter a um cluster do Kubernetes pode 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 escaloná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 melhora a multilocação otimizando a alocação de recursos, garantindo o isolamento entre os aplicativos de cada locatário e reduzindo os custos operacionais. Quando você cria uma solução multilocatária no AKS, a Karpenter fornece recursos úteis para ajudá-lo 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 seu aplicativo requer baixa latência para armazenamento, você pode usar Karpenter para indicar que um pod requer um nó que é executado em uma zona de disponibilidade específica para que você possa colocalizar seu armazenamento e camada de aplicativo.

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 de provisionamento automático de nó . Se você precisar de uma personalização mais avançada, você pode optar por auto-hospedar Karpenter. Para obter mais informações, consulte o provedor AKS Karpenter.

VMs confidenciais

A computação confidencial é uma medida de segurança destinada 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, salvaguardando os dados em repouso e em trânsito.

A plataforma da AWS oferece suporte à computação confidencial por meio Nitro Enclaves, que estão disponíveis em instâncias do EC2, bem como em Amazon Elastic Kubernetes Service (EKS). Para obter mais informações, consulte este artigo sobre a documentação da Amazon. Além disso, as instâncias do Amazon EC2 oferecem suporte AMD SEV-SNP. Este repositório GitHub fornece artefatos para criar e implantar um de imagem de máquina da Amazon (AMI) para EKS com suporte AMD SEV-SNP.

Por outro lado, o Azure fornece aos clientes VMs confidenciais para atender aos requisitos estritos de isolamento, privacidade e segurança em um cluster AKS. Essas VMs confidenciais utilizam um ambiente de execução baseado em hardware confiável. Especificamente, as VMs confidenciais do Azure utilizam a tecnologia AMD Secure Encrypted Virtualization - Secure Nested Paging (SEV-SNP), que nega ao hipervisor e a outros códigos de gerenciamento de host acesso à memória e ao estado da VM. Isso adiciona uma camada adicional de defesa e proteção contra o acesso do operador. Para obter mais detalhes, você pode consultar a documentação sobre como usar VMs confidenciais em um cluster AKS e a visão geral de VMs confidenciais no Azure.

Normas Federais de Processo de Informação (FIPS)

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. Ao habilitar conformidade FIPS para pools de nós AKS, você pode melhorar o isolamento, a privacidade e a segurança de suas cargas de trabalho de locatário. conformidade com FIPS garante o uso de módulos criptográficos validados para criptografia, hashing e outras operações relacionadas à segurança. Com pools de nós AKS habilitados para FIPS, você pode atender aos requisitos de conformidade regulatória e do setor empregando algoritmos e mecanismos criptográficos robustos. O Azure fornece documentação sobre como habilitar o FIPS para pools de nós AKS, o que permite fortalecer a postura de segurança de seus ambientes AKS multilocatário. Para obter mais informações, consulte Habilitar FIPS para pools de nós AKS.

Criptografia baseada em host

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

  • de criptografia do Amazon EBS: você pode criptografar dados em repouso em volumes do Amazon Elastic Block Store (EBS) anexados aos nós de trabalho do EKS.
  • AWS Key Management Service (KMS): você pode usar o AWS KMS para gerenciar chaves de criptografia e impor a criptografia de seus dados em repouso. Se você habilitar a criptografia de segredos , poderá criptografar segredos do Kubernetes usando sua própria chave do AWS KMS. Para obter mais informações, consulte criptografar segredos do Kubernetes com o AWS KMS em clusters existentes.
  • Amazon S3 Server-Side Encryption: Se seus aplicativos EKS interagirem com o Amazon S3, você poderá habilitar a criptografia do lado do servidor para seus buckets do S3 para proteger os dados em repouso.

de 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, o que ajuda a garantir que as informações confidenciais do locatário sejam protegidas contra acesso não autorizado. Discos temporários e discos efêmeros do sistema operacional são criptografados em repouso com chaves gerenciadas pela plataforma quando você habilita a criptografia de ponta a ponta.

No AKS, o sistema operacional e os discos de dados usam criptografia do lado do servidor com chaves gerenciadas pela plataforma por padrão. Os caches desses discos são criptografados em repouso com chaves gerenciadas pela plataforma. Você pode especificar sua própria chave de criptografia de chave para criptografar a chave de proteção de dados usando a criptografia de envelope, também conhecida como de encapsulamento de. O cache do sistema operacional e dos discos de dados também são criptografados por meio do BYOK que você especificar.

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

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.

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 adicional e cota IP de 10 nós, ou dois nós vezes cinco pools, para concluir a atualização.

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

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:

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.

Contribuidores

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

Principais autores:

Outros contribuidores:

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

Próximos passos