Container Service for Kubernetes:Upgrade a node pool

Considerações

• Verificações pré-atualização

  • As atualizações de cluster usam o yum para baixar os pacotes de software necessários. Caso você tenha modificado manualmente as configurações de rede dos nós ou usado uma imagem de sistema operacional (SO) personalizada, certifique-se de que o yum funcione corretamente nos nós. Execute yum makecache para verificar.

  • O ACK não valida rigorosamente imagens de SO personalizadas. Portanto, não é possível garantir o sucesso da atualização.

  • Se você alterou configurações do cluster, como ativar a partição SWAP ou modificar configurações do kubelet ou do runtime via linha de comando, a atualização do cluster pode falhar ou suas configurações personalizadas podem ser sobrescritas.

  • Após atualizar um cluster para a versão 1,18, o ACK configure a Política de Reserva de Recursos do Nó 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 prontamente após a evicção. Reserve recursos para seus nós. Mantenha o uso de CPU em até 50% e o uso de memória em até 70%.

  • Em clusters com a versão 1,24 ou anterior, se os pods de uma carga de trabalho estiverem configurados apenas com um Startup Probe, eles entrarão brevemente no estado NotReady após a reinicialização do kubelet. Implante cargas de trabalho com múltiplas réplicas distribuídas por diferentes nós. Isso garante a disponibilidade de pods suficientes caso um nó seja reiniciado.

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

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

  • 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 trabalhadores não gerenciados fora de um pool de nós, migre-os. Para mais informações, consulte Migrar nós não gerenciados para um pool de nós.

  • Não há suporte para a atualização de pools de nós Lingjun durante uma atualização de cluster ACK.

  • Ao atualizar nós substituindo seus discos, o ACK os reinicializa com base na configuração atual do pool de nós. Isso inclui o método de logon, rótulos, taints, imagem do SO e versão do runtime. Para atualizar as configurações do pool de nós, consulte Editar um pool de nós. Se você modificou os nós de qualquer outra forma, a atualização sobrescreverá suas alterações.

  • Se um pod em um nó referenciar um HostPath que aponte para o disco do sistema, os dados no diretório HostPath serão perdidos após uma atualização por 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 quaisquer configurações não padrão dele.

• dimensionamento de nós e agendamento

  • Se o recurso de dimensionamento de nós estiver ativado no cluster, o cluster-autoscaler será atualizado automaticamente para a versão mais recente após uma atualização bem-sucedida, garantindo que o recurso de auto scaling não seja afetado. Após a atualização do cluster, confirme se a versão do cluster-autoscaler está correta. Para mais informações, consulte Ativar dimensionamento automático de nós.

  • Durante uma atualização de cluster, nós com o Scaling Mode definido como Swift podem falhar na atualização porque são desligados. Se alguns nós não forem atualizados devido ao modo Swift após a conclusão da atualização, recomendamos removê-los manualmente.

• Rede e disponibilidade de serviço

  • Se um pod usar o endereço SLB de um Serviço LoadBalancer para acessar outro pod no mesmo nó, e o externalTrafficPolicy do Serviço estiver definido como Local, os dois pods podem deixar de estar no mesmo nó após a rotação de nós. Isso pode causar falha na conexão de rede.

  • Ao atualizar nós substituindo seus discos, o ACK drena os nós. Esse processo evacua os pods para outros nós ativos, respeitando o Pod Disruption Budget (PDB). Para garantir alta disponibilidade, implante cargas de trabalho com múltiplas réplicas distribuídas por diferentes nós. Além disso, configure um PDB para serviços críticos a fim de controlar o número de pods que podem ser interrompidos simultaneamente.

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

Recursos

A atualização de um pool de nós inclui o kubelet e o runtime de contêineres.

• Atualização do Kubelet: O kubelet em cada nó do pool é atualizado para corresponder à versão do plano de controle. Método padrão: atualização in-place.

• Atualização do runtime de contêineres: Atualize o runtime de contêineres nos nós quando uma nova versão estiver disponível.

  • A migração do docker para containerd substitui o disco do sistema nos nós do pool de nós, apagando todos os dados do disco do sistema. Faça backup de dados críticos antes da atualização. Consulte Migrar o runtime de contêiner do nó de docker para containerd.

  • Exceto para nós ContainerOS, a atualização de uma versão do containerd para uma mais recente realiza uma atualização in-place por padrão. O arquivo /etc/containerd/config.toml no nó é substituído pela nova versão fornecida pelo ACK.

    Importante

    • Nós ContainerOS suportam apenas a substituição do disco do sistema para atualizações do containerd. Consulte Atualizar versões do ContainerOS anteriores à 3,4 para a versão mais recente.

    • Durante uma atualização do runtime de contêineres, probes de pods e hooks de ciclo de vida podem falhar, e os pods podem ser reiniciados in-place.

  • Em clusters com Kubernetes 1,24 ou anterior, a atualização do docker substitui o disco do sistema nos nós do pool de nós por padrão, apagando todos os dados do disco do sistema. Faça backup de dados críticos antes da atualização.

Procedimento

1. Faça login no console do ACK. 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 desejado, clique em 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êineres e selecione a versão de destino. A migração do docker para containerd substitui o disco do sistema nos nós do pool de nós, apagando todo o conteúdo do disco do sistema. Consulte Migrar o runtime de contêiner do nó de docker para containerd. Clusters na versão 1,22 com containerd 1.6.34 não suportam atualizações de runtime.
   Update Nodes		Selecione os nós a serem atualizados: todos ou específicos.
   Método de atualização		Selecione In-place Upgrade ou Upgrade by Replacing System Disk. Consulte Referência: Atualização in-place e atualização por substituição de disco do sistema. In-place Upgrade: O ACK atualiza componentes diretamente nos nós existentes. Uma atualização in-place não substitui o disco do sistema nem reinicializa o nó, e os dados não são afetados. Upgrade by Replacing System Disk: O ACK reinicializa os nós substituindo seu disco do sistema. 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 são afetados.
   Ignore Warnings		Indica se deve prosseguir caso a verificação prévia reporte avisos. Por exemplo, um pod usa um hostPath apontando para o disco do sistema.
   Batch Update Policy	Maximum Number of Nodes per Batch	Os nós são atualizados em lotes até este máximo. Consulte Referência: Atualização in-place e atualização por substituição de disco do sistema.
   	Automatic Pause Policy	A política de pausa para o processo de atualização.
   	Interval Between Batches	Intervalo entre lotes quando nenhuma pausa automática está configurada. Valores válidos: 5 a 120 minutos.
   	Auto Snapshot	Se o disco do sistema de um nó contiver dados importantes, crie snapshots antes de atualizar o pool de nós. Snapshots geram taxas (consulte Faturamento de snapshots) e o progresso de criação muda dinamicamente. Após a atualização, exclua os snapshots desnecessários. Nota Se você selecionar Upgrade by replacing system disk, ative a criação automática de snapshots. Snapshots geram custos. Consulte Faturamento de snapshots.

4. Clique em Precheck. Após o sucesso da verificação prévia, siga as instruções na tela para iniciar a atualização.

   Nota

   Se a verificação prévia falhar ou retornar avisos, consulte Correções para itens de verificação com falha ou visualize o Check Report para solucionar o problema.

   Durante a atualização, você pode:

   • Pause: Coloca o pool de nós em um estado intermediário. Evite outras operações no cluster e conclua a atualização prontamente. Atualizações pausadas por mais de sete dias são encerradas automaticamente, e eventos e logs relacionados são limpos.

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

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

   Para verificar, acesse a página Nodes, clique em no nome de um nó e verifique as versões do kubelet e do runtime de contêineres na aba Basic Information.

Atualizações in-place e por substituição

Processos de atualização

Tanto a atualização in-place quanto a atualização por substituição de disco do sistema seguem este processo. A atualização do pool de nós processa os nós em lotes, começando com 1 e dobrando (1, 2, 4, 8...) até atingir a contagem máxima simultânea. Por exemplo, com um máximo de 4: o lote 1 atualiza 1 nó, o lote 2 atualiza 2 nós e todos os lotes subsequentes atualizam 4 nós.

A figura a seguir mostra a execução em lotes com N nós concorrentes máximos. Os tamanhos dos lotes são 1, 2, 4, 8... até atingir N.

Perguntas frequentes

echo 2 > /proc/sys/vm/drop_caches

Referências

• Ative as atualizações automáticas de cluster para reduzir a sobrecarga de manutenção.

• Para o histórico de lançamentos do containerd, consulte notas de lançamento do runtime containerd.

• Pools de nós gerenciados pelo ACK suportam correção automática de CVEs do SO.

• A partir do Kubernetes 1,24, o docker não é mais um runtime de contêineres suportado. Você deve migrar o runtime de contêiner do nó de docker para containerd. Consulte Migrar o runtime de contêiner do nó de docker para containerd.

  docker e containerd usam ferramentas de linha de comando diferentes. Consulte Comparação de comandos comuns para docker e containerd.

• Mantenha as imagens do SO atualizadas. Consulte Alterar o sistema operacional.