Container Service for Kubernetes:Upgrade a node pool

Considerações

• Preparativos

  • As atualizações de cluster utilizam o yum para baixar os pacotes de software necessários. Se você modificou manualmente as configurações de rede dos nós ou usou uma imagem de sistema operacional (SO) personalizada, verifique se o yum funciona corretamente nos nós. Execute yum makecache para confirmar.

  • O ACK não valida imagens de SO personalizadas por completo e não garante que elas possam ser atualizadas.

  • Caso tenha modificado as configurações do cluster, por exemplo, ao ativar o swap ou usar métodos não padronizados, como acessar um nó (Customize node pool kubelet configurations) e modificar as configurações do kubelet ou do runtime, a atualização do cluster poderá falhar ou sobrescrever suas personalizações.

  • Ao atualizar um cluster para a versão 1.18, o ACK configura a Node resource reservation policy por padrão. Se a reserva de recursos não estiver configurada e o uso de recursos do nó estiver alto, os pods podem não ser agendados rapidamente após a evicção. Reserve recursos para os nós. Mantenha o uso de CPU em até 50% e o de memória em até 70%.

  • Em clusters com a versão 1.24 ou anterior, os pods configurados apenas com uma startup probe entram brevemente no estado NotReady após a reinicialização do kubelet. Implante cargas de trabalho com múltiplas réplicas em vários nós, garantindo que pods suficientes permaneçam disponíveis durante a reinicialização de um nó.

  • Mantenha pelo menos 20% do espaço em disco livre. Isso evita a evicção de pods causada por capacidade de disco insuficiente durante uma atualização.

• Restrições de atualização do pool de nós

  • As atualizações de pool de nós suportam apenas operações de scale-out. Não há suporte para operações de scale-in.

  • Caso possua nós workers não gerenciados fora de um pool de nós, migre-os. Para mais informações, consulte Migrate unmanaged nodes to a node pool.

  • Durante uma atualização com substituição de disco, o ACK reinicializa os nós com base na configuração atual do pool de nós, incluindo o método de login, rótulos, taints, imagem do SO e versão do runtime. Atualize a configuração do pool de nós conforme descrito em Edit a node pool. O sistema sobrescreve alterações feitas por outros métodos durante a atualização.

  • Se um pod em um nó referenciar um HostPath apontando para o disco do sistema, os dados no diretório HostPath serão perdidos após uma atualização com substituição de disco.

  • Ao atualizar um pool de nós em um cluster da versão 1.31 ou anterior, o processo também atualiza o NVIDIA Device Plugin e redefine qualquer configuração não padrão.

• dimensionamento de nós e agendamento

  • Se o dimensionamento de nós estiver ativado, o ACK atualiza automaticamente o cluster-autoscaler para a versão mais recente após a atualização do cluster, garantindo a disponibilidade do dimensionamento. Confirme a atualização do cluster-autoscaler. Para mais informações, consulte Enable node autoscaling.

  • Durante uma atualização de cluster, os nós com o Scaling Mode definido como Swift podem falhar na atualização devido ao desligamento. Caso algum nó permaneça sem atualização devido à ativação do Swift, remova-o manualmente.

• Rede e disponibilidade de serviço

  • Se um pod acessar outro pod no mesmo nó por meio do endereço SLB de um Service LoadBalancer, e o externalTrafficPolicy estiver definido como Local, a rotação de nós pode alocar os pods em nós diferentes. Isso pode interromper a conectividade.

  • Durante uma atualização com substituição de disco, o ACK drena os nós e evacua os pods para outros nós disponíveis, respeitando o Pod Disruption Budget (PDB). Para garantir alta disponibilidade, implante cargas de trabalho com múltiplas réplicas em vários nós e configure um PDB para serviços críticos para limitar interrupções simultâneas de pods.

    O tempo limite padrão para drenar um nó é de 30 minutos. Se a migração dos pods não for concluída dentro desse período, o ACK encerra a atualização para manter a estabilidade do serviço.

Funcionalidades

Uma atualização de pool de nós inclui as seguintes operações:

• Atualização do kubelet: Atualiza o kubelet em cada nó para a versão do plano de controle. O método padrão é a atualização in-place.

• Atualização do runtime de contêiner: Atualiza o runtime de contêiner nos nós quando uma versão mais recente do runtime está disponível.

  • A migração do Docker para o containerd aciona uma atualização com substituição de disco, substituindo o disco do sistema em cada nó e excluindo todos os seus dados. Faça o backup dos dados críticos do disco do sistema antes da atualização. Para mais informações, consulte Migrate the node container runtime from Docker to containerd.

  • Exceto em nós ContainerOS, a atualização do containerd para uma versão mais recente usa o método in-place por padrão. O ACK substitui o /etc/containerd/config.toml em cada nó pela versão fornecida pelo ACK.

    Importante

    • Os nós ContainerOS não suportam atualizações in-place do containerd. Use uma atualização com substituição de disco. Para mais informações, consulte Upgrade ContainerOS versions earlier than 3.4 to the latest version.

    • Durante uma atualização do runtime de contêiner, as sondas dos Pods e os lifecycle hooks podem falhar, e o sistema pode reiniciar os Pods in-place.

  • Em clusters com versões do Kubernetes anteriores a 1.24, a atualização do Docker usa o método de substituição de disco por padrão e exclui todos os dados do disco do sistema. Faça o backup dos dados críticos do disco do sistema antes da atualização.

Procedimento

1. Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.

2. Na página Clusters, clique no nome do seu cluster. No painel de navegação à esquerda, clique em Nodes > Node Pools.

3. Na página Node Pools, localize o pool de nós de destino, clique no ícone na coluna Actions e selecione Kubelet Update. Configure os seguintes parâmetros.

   Parâmetro		Descrição
   Kubelet Update Information		Visualize a versão atual do kubelet e selecione a versão de destino.
   Runtime Update Information		Visualize a versão atual do runtime de contêiner e selecione a versão de destino. A migração do Docker para o containerd executa uma atualização com substituição de disco, substituindo o disco do sistema em cada nó e excluindo todos os seus dados. Para mais informações, consulte Migrate the node container runtime from Docker to containerd. Clusters com o Kubernetes 1.22 e o containerd 1.6.34 instalado não suportam atualizações de runtime.
   Update Nodes		Selecione os nós a serem atualizados: todos ou nós específicos.
   Método de atualização		Selecione In-place Upgrade ou Upgrade by Replacing System Disk. Consulte Reference: In-place and disk replacement upgrades. In-place Upgrade: O ACK atualiza os componentes necessários diretamente nos nós existentes. Uma atualização in-place não substitui o disco do sistema nem reinicializa o nó, e mantém os dados no nó. Upgrade by Replacing System Disk: O ACK reinicializa os nós substituindo o disco do sistema. Os atributos da instância, como nome, ID e endereço IP, permanecem inalterados, mas os dados do disco do sistema são excluídos. Discos de dados anexados não sofrem alterações.
   Ignore Warnings		Define se a atualização deve prosseguir caso a pré-verificação reporte avisos. Por exemplo, um pod usa um hostPath apontando para o disco do sistema.
   Batch Update Policy	Maximum Number of Nodes per Batch	O sistema atualiza os nós em lotes até este limite. Consulte Reference: In-place and disk replacement upgrades.
   	Automatic Pause Policy	Especifica quando o sistema pausa a atualização automaticamente.
   	Interval Between Batches	Define o intervalo entre lotes quando as pausas automáticas estão desativadas. Valores válidos: 5 a 120 minutos.
   	Auto Snapshot	Para fazer backup e restaurar dados de negócios importantes no disco do sistema de um nó, crie snapshots antes de atualizar o pool de nós. Snapshots geram taxas (consulte Snapshot billing) e o creation progress muda dinamicamente. Após a atualização, delete os snapshots desnecessários. Nota Para uma atualização com substituição de disco, considere ativar a criação automática de snapshots. Há cobrança de taxas de snapshot. Para detalhes de faturamento, consulte Snapshot billing.

4. Após configurar os parâmetros, clique em Precheck. Se a pré-verificação for aprovada, siga as instruções na tela para iniciar a atualização.

   Nota

   Se a pré-verificação falhar ou retornar avisos, consulte Fixes for failed check items ou visualize o Check Report para solucionar problemas.

   As seguintes ações estão disponíveis durante a atualização:

   • Pause: Coloca o pool de nós em um estado intermediário. Evite outras operações no cluster e conclua a atualização rapidamente. O sistema encerra automaticamente atualizações pausas por mais de sete dias e limpa os eventos e logs relacionados.

     Não é possível reverter as versões do kubelet e do runtime de contêiner em nós atualizados.

   • Cancel: Cancela a atualização. Após clicar em Cancel, não é possível reverter as versões do kubelet e do runtime de contêiner em nós atualizados.

   Para verificar a atualização, acesse a página Nodes, clique no nome de um nó e verifique se as versões do kubelet e do runtime de contêiner na aba Basic Information estão conforme o esperado.

Referência: Atualizações in-place e com substituição de disco

Processos de atualização

As atualizações in-place e com substituição de disco usam o mesmo processo em lotes. O ACK primeiro executa uma verificação pré-atualização em cada nó. O sistema ignora os nós que falham e atualiza os nós aprovados em lotes com base no Maximum Parallel Nodes per Batch. Cada lote contém no máximo o limite configurado, e o próximo lote começa após a conclusão do lote atual.

Por exemplo, se o máximo for 2, o ACK atualiza até dois nós em cada lote. Se o máximo for 100, o ACK atualiza até 100 nós em cada lote. Os valores válidos são de 1 a 100.

A figura a seguir mostra as atualizações quando o máximo é definido como 1, 2 ou N. Cada lote atualiza 1, 2 ou N nós, respectivamente.

Perguntas frequentes

echo 2 > /proc/sys/vm/drop_caches

Referências

• Ative o automatic cluster upgrades para reduzir o esforço de manutenção.

• Para as notas de versão do runtime containerd, consulte containerd runtime release notes.

• Os pools de nós gerenciados pelo ACK suportam o automatic OS CVE patching.

• A partir do Kubernetes 1.24, o Docker não é mais um runtime de contêiner suportado. Migre o runtime de contêiner do nó de Docker para containerd. Consulte Migrate the node container runtime from Docker to containerd.

  O Docker e o containerd usam ferramentas de linha de comando diferentes. Consulte Comparison of common commands for Docker and containerd.

• Mantenha as imagens do SO atualizadas. Consulte Change the operating system.