Editar

Compartilhar via

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

AKS (Serviço de Kubernetes do Azure)
Máquinas Virtuais do Azure

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

Observação

Este artigo faz parte de uma série de artigos que ajudam profissionais familiarizados com o Amazon EKS a entender o Serviço Azure Kubernetes (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 em uma arquitetura AKS Kubernetes.

Diagrama que mostra o painel de controle e os nós na arquitetura AKS.

Grupos de nós gerenciados pelo Amazon EKS

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

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

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

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

Karpenter

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

  • Monitore os pods que o agendador do Kubernetes não pode agendar devido a restrições de recurso.
  • Avalie os requisitos de agendamento (solicitações de recurso, seletores de nó, afinidades, tolerâncias etc.) dos pods não programáveis.
  • Provisione novos nós que atendem 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ó, afinidades de nó/pod, tolerâncias e restrições de propagação de topologia. Em seguida, o Karpenter provisiona nós de tamanho correto com base nessas especificações.

Antes do lançamento do Karpenter, os usuários do Amazon EKS contavam principalmente com grupos de Dimensionamento Automático do Amazon EC2 e o CAS (Dimensionador Automático 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 obter a flexibilidade e a diversidade que obtém com o Karpenter. Ao contrário do Dimensionador Automático de Cluster do Kubernetes, o Karpenter não é tão firmemente acoplado às versões do Kubernetes e não exige que você pule entre AS APIs do AWS e do Kubernetes.

O Karpenter consolida as responsabilidades de orquestração de instância em um único sistema, que é mais simples, mais estável e com reconhecimento de cluster. O Karpenter foi projetado para superar alguns dos desafios apresentados pelo Dimensionador Automático de Cluster 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 pode permitir que você gerencie a capacidade de carga de trabalho diversificada com um Único NodePool flexível.
  • Obtenha um agendamento de pod aprimorado em escala iniciando rapidamente nós e agendando pods.

Para obter informações e documentação sobre como usar o Karpenter, visite o site karpenter.sh.

O Karpenter aproxima o gerenciamento de dimensionamento das APIs nativas do Kubernetes do que ASGs (Grupos de Dimensionamento Automático) e de Grupos de Nós Gerenciados (MNGs). ASGs e MNGs são abstrações nativas da AWS em que o dimensionamento é disparado com base em métricas de nível de AWS, como a carga da CPU EC2. Dimensionador Automático de Cluster conecta as abstrações do Kubernetes em abstrações do AWS, mas perde alguma flexibilidade devido a isso, como agendamento para uma zona de disponibilidade específica.

Karpenter remove uma camada de abstração do AWS para trazer parte da flexibilidade diretamente para o Kubernetes. O Karpenter é melhor usado para clusters com cargas de trabalho que encontram períodos de alta demanda espetada ou têm requisitos de computação diversos. 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 seus requisitos.

Contêineres kata

Contêineres kata é um projeto de software livre que fornece um runtime 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 do 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 no mesmo computador host. contêineres kata fornecem os seguintes recursos:

  • isolamento de carga de trabalho avançado: cada contêiner é executado em sua própria VM leve, garantindo o isolamento no nível do hardware.
  • melhorde segurança: o uso da tecnologia de VM fornece uma camada adicional de segurança, reduzindo o risco de quebras de contêiner.
  • Compatibilidade com os padrões do setor: contêineres Kata integram-se com 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: contêineres kata dão suporte a arquiteturas AMD64 e ARM e podem ser usados com hipervisores como Cloud-Hypervisor e Firecracker.
  • de gerenciamento e implantação fácil: os Contêineres kata abstraem a complexidade da orquestração de cargas de trabalho aproveitando o sistema de orquestração do Kubernetes.

Os clientes do AWS podem configurar e executar de Contêineres kata no AWS configurando um cluster do EKS (Serviço de Kubernetes Elástico) da Amazon para usar firecracker, uma tecnologia de virtualização de software livre desenvolvida pela Amazon para criar e gerenciar serviços seguros, multilocatários e 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 máquinas virtuais tradicionais, permitindo a velocidade e a eficiência dos recursos dos contêineres. Habilitar contêineres Kata no AWS EKS requer uma série de etapas manuais descritas em aprimoramento do isolamento e segurança da carga de trabalho do Kubernetes usando contêineres kata.

Hosts dedicados

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 , grupos de dimensionamento automáticoe registrá-los no cluster EKS. O processo de criação desses recursos é o mesmo que para o dimensionamento automático EC2 geral.

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

Nós do AKS e pools de nós

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

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

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

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

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 de vizinhos barulhentos ou para oferecer suporte a aplicativos com demandas de computação ou armazenamento diferentes.

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

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

Importante

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

Criação do pool de nós

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

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

Por padrão, o grupo de recursos do nó tem um nome como MC_<resourcegroupname>_<clustername>_<location>. O AKS exclui automaticamente o grupo de recursos de nó quando o cluster é excluído e, portanto, só deve ser usado para os recursos que compartilham o ciclo de vida do cluster.

Adicionar um pool de nós

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

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

Pools de nós spot

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

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

Os nós spot são ótimos para cargas de trabalho que podem lidar com interrupções, encerramentos antecipados ou remoções. Por exemplo, trabalhos de processamento em lotes, ambientes de desenvolvimento e teste e grandes cargas de trabalho de computação podem ser boas candidatas a serem agendadas em um pool de nós spot. Para obter mais detalhes, consulte as limitações da instância spot.

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

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

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

Discos do SO Efêmero

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

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

Importante

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

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

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

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

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

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

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

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

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

Cada grupo de nós gerenciados no EKS é apoiado por um grupo de dimensionamento automático Amazon EC2, que é gerenciado pelo Amazon EKS. Essa integração permite que o EKS lide automaticamente com o provisionamento e o dimensionamento de instâncias EC2 dentro do grupo de nós. Embora os grupos de Dimensionamento Automático possam ser configurados para dar suporte a vários tipos de instância 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 e nas políticas desejadas definidas pelo usuário. Isso garante um processo de gerenciamento simplificado e automatizado para o grupo de nós, proporcionando flexibilidade na seleção dos tipos de instância EC2 que atendem aos requisitos de carga de trabalho. No entanto, os clientes da AWS podem iniciar nós do Amazon Linux autogerenciados com eksctl ou o Console de Gerenciamento do AWS.

Com pools de nós de Máquinas Virtuais, o AKS (Serviço de Kubernetes do Azure) gerencia o provisionamento e inicialização de cada nó do agente. Para pools de nós de Conjuntos de Dimensionamento de Máquinas Virtuais, o AKS gerencia o modelo dos Conjuntos de Dimensionamento de Máquinas Virtuais e o usa para obter consistência em todos os nós do 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 encaixam em suas cargas de trabalho individuais e especificar 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 SKUs (tamanhos diferentes) designados para dar suporte a diferentes tipos de cargas de trabalho. Esses tamanhos de máquina virtual, conhecidos como SKUs, são categorizados em diferentes famílias 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 de 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. Somente um tamanho de máquina virtual é permitido em um ManualScaleProfile. Você precisa criar um ManualScaleProfile separado para cada tamanho de máquina virtual no pool de nós.

Ao criar um novo pool de nós de Máquinas Virtuais, você precisará 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: controles de nível de nó único permitem especificar e misturar nós de especificações diferentes para melhorar a consistência.
  • eficiência: você pode reduzir o volume de nós do cluster, simplificando seus requisitos operacionais.

Os pools de nós de Máquinas Virtuais fornecem 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 configurados.

A tabela a seguir compara pools de nós de Máquinas Virtuais com pools de nós 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áquina virtual 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 em Conjunto de Dimensionamento de Máquinas Virtuais Você pode adicionar ou remover nós do mesmo tamanho e digitar em 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áquina virtual têm as seguintes limitações:

  • não há suporte para de dimensionador automático de cluster.
  • 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 CLI do Azure ou APIs REST para executar operações CRUD ou gerenciar o pool.
  • não há suporte de instantâneo do pool de nós.
  • Todos os tamanhos de VM selecionados em um pool de nós devem ser da mesma família de máquinas virtuais. Por exemplo, você não pode 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 de máquinas virtuais diferentes por pool de nós.

Nós virtuais

Você pode usar nós virtuais para aumentar rapidamente as cargas de trabalho do aplicativo em um cluster do AKS. Os nós virtuais oferecem provisionamento rápido de pods, e você paga apenas por segundo pelo tempo de execução. Você não precisa esperar que o dimensionador automático do cluster implante novos nós de trabalho para executar mais réplicas de pod. Os nós virtuais só têm suporte com os pods e nós do Linux. O complemento de nós virtuais para AKS é baseado no projeto de código aberto Kubelet virtual.

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

Taints, etiquetas e marcações

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

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

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

Para saber mais, confira Especificar um taint, um rótulo ou uma marca para um pool de nós.

Rótulos de sistema reservados

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

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

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

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

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

Na coluna Uso do nó virtual:

  • N/A significa que a propriedade não se aplica a nós virtuais porque seria necessário modificar o host.
  • Same significa que os valores esperados são os mesmos para um pool de nós virtuais como para um pool de nós padrão.
  • Virtual substitui os valores de SKU da VM, porque os pods de nó virtual não expõem nenhuma VM subjacente.
  • A versão do nó virtual refere-se à versão atual da versão virtual do conector Kubelet-ACI.
  • Nome da sub-rede do nó virtual é o nome da sub-rede que implanta pods de nó virtual nas Instâncias de Contêiner do Azure.
  • Rede virtual de nó virtual é a rede virtual que contém a sub-rede de nó virtual.
Etiqueta Valor Exemplo, opções Uso de nós virtuais
kubernetes.azure.com/agentpool <agent pool name> nodepool1 Idêntico
kubernetes.io/arch amd64 runtime.GOARCH N/D
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 Idêntico
topology.kubernetes.io/zone <Azure zone> 0 Idêntico
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 Idêntico
kubernetes.azure.com/mode <mode> User ou System User
kubernetes.azure.com/role agent Agent Idêntico
kubernetes.azure.com/scalesetpriority <scale set priority> Spot ou Regular N/D
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 Idêntico
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed N/D
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS N/D
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 do nó virtual
kubernetes.azure.com/ppg <nodepool ppg name> ppgName N/D
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name N/D
kubernetes.azure.com/accelerator <accelerator> Nvidia N/D
kubernetes.azure.com/fips_enabled <fips enabled> True N/D
kubernetes.azure.com/os-sku <os/sku> Confira Criar ou atualizar a SKU do SO SKU Linux

Pools de nós do Windows

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

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

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

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

Considerações sobre o pool de nós

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

  • Cotas, restrições de tamanho de VM e disponibilidade de região se aplicam a pools de nós do AKS.
  • Os pools de sistemas devem conter pelo menos um nó. É possível excluir os pools de nós do sistema, desde que tenha outro pool de nós do sistema para assumir o lugar no cluster do AKS. Os pools de nós do usuário podem conter zero ou mais nós.
  • Você não pode alterar o tamanho da VM de um pool de nós depois de criá-la.
  • Para vários pools de nós, o cluster do AKS deve usar os balanceadores de carga de SKU Standard. Os balanceadores de carga SKU Básico não oferecem suporte a vários pools de nós.
  • Todos os pools de nós de cluster e todas as sub-redes atribuídas a qualquer pool de nós devem estar na mesma rede virtual.
  • Ao criar vários pools de nós no momento da criação do cluster, todas as versões do Kubernetes usadas por pools de nós devem corresponder à versão do plano de controle. Você pode atualizar as versões após o cluster ter sido provisionado usando operações por pool de nós.

Escala do pool de nós

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

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

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

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

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

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

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

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

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

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

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

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

Área restrita de pod

Os clientes do AKS podem facilmente configurar e executar contêineres kata no AKS de maneira totalmente gerenciada. Isso é possível por meio do uso de de Área Restrita do Pod, um recurso que cria um limite de isolamento entre o aplicativo contêiner e os recursos compartilhados de kernel e computação do host de contêiner.

O AKS inclui um mecanismo chamado de Área Restrita de Pod que fornece um limite de isolamento entre o aplicativo contêiner e os recursos compartilhados de kernel e computação do host de 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 de locatário a proteger informações confidenciais e atender aos requisitos de conformidade regulatória, do setor ou de governança, como PCI DSS (Payment Card Industry Data Security Standard), ISO (International Organization for Standardization) 27001 e HIPAA (Health Insurance Portability And Accountability Act).

Ao implantar aplicativos em clusters ou pools de nós separados, você pode isolar fortemente as cargas de trabalho de locatário 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 ao executar pods não confiáveis e não confiáveis no mesmo nó ou colocar DaemonSets e contêineres privilegiados no mesmo nó para comunicação local mais rápida e agrupamento funcional. o Pod Sandboxing pode ajudá-lo a isolar fortemente os aplicativos de locatário 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 não modificado dentro de um limite de VM de segurança aprimorado.

O Pod Sandboxing no AKS baseia-se no contêineres kata que são executados no host de contêiner do 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 protegido pela segurança. Ele obtém 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. Esse modelo fornece um limite de isolamento forte em um cluster compartilhado do AKS.

Para obter mais informações, consulte:

Host Dedicado do Azure

host dedicado do Azure é um serviço que fornece servidores físicos dedicados a uma única assinatura do Azure e fornecem isolamento de hardware no nível do servidor físico. Você pode provisionar esses hosts dedicados em 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 infraestrutura de armazenamento subjacente que outros hosts não isolados.
  • O Host Dedicado do Azure fornece controle sobre eventos de manutenção iniciados pela plataforma do Azure. 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 de locatário.

O Host Dedicado do Azure pode ajudar os provedores de SaaS a garantir que os aplicativos locatários atendam aos requisitos de conformidade regulatória, do setor e da governança para proteger informações confidenciais. Para obter mais informações, consulte Adicionar o Host Dedicado do Azure a um cluster do AKS.

Karpenter

o Karpenter é um projeto de gerenciamento de ciclo de vida de nó de software livre criado para o Kubernetes. Adicionar o Karpenter a um cluster do Kubernetes pode melhorar a eficiência e o custo de execução de cargas de trabalho nesse cluster. O Karpenter observa os pods que o agendador do Kubernetes marca como não programá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 multilocatário 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ário no AKS, o Karpenter fornece recursos úteis para ajudá-lo a gerenciar diversos requisitos de aplicativo para dar suporte a diferentes locatários. Por exemplo, talvez seja necessário que alguns aplicativos de locatários sejam executados em pools de nós com otimização de GPU e outros para serem executados em pools de nós com otimização de memória. Se o aplicativo exigir baixa latência para armazenamento, você poderá usar o Karpenter para indicar que um pod requer um nó executado em uma zona de disponibilidade específica para que você possa colocar seu armazenamento e camada de aplicativo.

O AKS habilita o provisionamento automático de nós em clusters do AKS por meio do 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ós. Se você precisar de personalização mais avançada, poderá optar por hospedar o Karpenter automaticamente. Para obter mais informações, consulte o provedor AKS Karpenter.

VMs confidenciais

A computação confidencial é uma medida de segurança destinada a proteger dados enquanto estiver em uso por meio de isolamento e criptografia assistidos por software ou hardware. Essa tecnologia adiciona uma camada extra de segurança a abordagens tradicionais, protegendo dados em repouso e em trânsito.

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

Por outro lado, o Azure fornece aos clientes VMs confidenciais para atender a requisitos estritos de isolamento, privacidade e segurança em um cluster do AKS. Essas VMs confidenciais utilizam um ambiente de execução confiável baseado em hardware. Especificamente, as VMs confidenciais do Azure utilizam a tecnologia AMD Secure Encrypted Virtualization – Secure Aninhad 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 usando VMs confidenciais em um de cluster do AKS e a visão geral de VMs confidenciais no Azure.

Padrões do Processo de Informações Federais (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 do AKS, você pode aprimorar o isolamento, a privacidade e a segurança das cargas de trabalho de locatário. conformidade de FIPS garante o uso de módulos criptográficos validados para criptografia, hash e outras operações relacionadas à segurança. Com pools de nós do 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 do AKS, o que permite fortalecer a postura de segurança de seus ambientes multilocatários do AKS. Para obter mais informações, consulte Habilitar o FIPS para pools de nós do AKS.

Criptografia baseada em host

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

  • de Criptografia do Amazon EBS: você pode criptografar dados em repouso em volumes do EBS (Amazon Elastic Block Store) anexados aos nós de trabalho do EKS.
  • kms (serviço de gerenciamento de chaves) do AWS: você pode usar o KMS do AWS para gerenciar chaves de criptografia e impor a criptografia de seus dados em repouso. Se você habilitar de criptografia de segredos, poderá criptografar segredos do Kubernetes usando sua própria chave KMS do AWS. Para obter mais informações, consulte Criptografar segredos do Kubernetes com o KMS do AWS 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 S3 protegerem 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 nos computadores host subjacentes, o que ajuda a garantir que as informações confidenciais do locatário estejam protegidas contra acesso não autorizado. Discos temporários e discos de so efêmeros são criptografados em repouso com chaves gerenciadas pela plataforma quando você habilita a criptografia de ponta a ponta.

No AKS, os discos de dados e do sistema operacional 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 criptografia de envelope, também conhecida como encapsulamento. O cache para o sistema operacional e os 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ários. Os dados de cada locatário nos caches de sistema operacional e de disco de dados são criptografados em repouso com chaves gerenciadas pelo cliente ou gerenciadas pela plataforma, dependendo do tipo de criptografia de disco selecionado. Para obter 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 patch de componentes de software no ambiente de hospedagem e atualização de componentes de rede até o encerramento de hardware. Para obter mais informações sobre como o Azure atualiza VMs, consulte Manutenção para máquinas virtuais no Azure.

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

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

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

Atualizações do Kubernetes

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

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

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

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

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

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 valor de max-surge de 50%, você precisará de computação adicional e cota de 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 (CNI) do Azure, verifique também se 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ós único.

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

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

Considerações sobre atualização

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

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

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

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

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

  • Configure o parâmetro max-surge com base em suas necessidades usando um valor inteiro ou percentual. Para pools de nós de produção, use uma configuração max-surge de 33%. Para saber mais, confira Personalizar a atualização de sobretensão de nó.

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

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

Colaboradores

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

Principais autores:

Outros colaboradores:

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

Próximas etapas