Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Upgrade a node pool

    Central de documentação

    Container Service for Kubernetes:Upgrade a node pool

    Última atualização: Sep 12, 2026

    Ao atualizar a versão do Kubernetes do cluster, conclua a atualização do node pool prontamente após a atualização do plano de controle, preferencialmente em horários de baixa demanda. A atualização do node pool inclui o kubelet e o container runtime. Antes do início, o ACK executa uma verificação pré-atualização para identificar fatores de risco e garantir que o processo ocorra sem problemas.

    Considerações

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

      • As atualizações de cluster usam o yum para baixar os pacotes de software necessários. Caso 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 no 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 Node resource reservation policy por padrão. Se a reserva de recursos não estiver configurada e o uso de recursos do nó for 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 que pods suficientes permaneçam disponíveis 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 node pool

      • Atualizações de node pool suportam apenas operações de scale-out. Não há suporte para operações de scale-in.

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

      • Não há suporte para a atualização de node pools 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 node pool. Isso inclui método de logon, labels, taints, imagem do SO e versão do runtime. Para atualizar as configurações do node pool, consulte Edit a node pool. 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 node pool 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 Enable node autoscaling.

      • 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 algum nó não for atualizado devido ao modo Swift após a conclusão da atualização, recomendamos removê-lo manualmente.

    • Rede e disponibilidade de service

      • Se um pod usar o endereço SLB de um Service LoadBalancer para acessar outro pod no mesmo nó, e o externalTrafficPolicy do Service 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 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 service.

    Recursos

    A atualização de um node pool inclui o kubelet e o container runtime.

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

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

      • A migração do docker para o containerd substitui o disco do sistema nos nós do node pool, apagando todos os dados do disco do sistema. Faça backup de dados críticos antes da atualização. Consulte Migrate the node container runtime from Docker to 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

      • Em clusters com Kubernetes 1,24 ou anterior, a atualização do docker substitui o disco do sistema nos nós do node pool 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 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 node pool desejado, clique em no ícone image 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 container runtime e selecione a versão de destino.

      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 Reference: In-place upgrade and upgrade by replacing system disk.

      • 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

      Defina se deve prosseguir caso a verificação prévia reporte avisos. Por exemplo, se um pod usar 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 Reference: In-place upgrade and upgrade by replacing system disk.

      Automatic Pause Policy

      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 node pool. Snapshots geram taxas (consulte Snapshot billing) e o creation progress muda dinamicamente. Após a atualização, delete snapshots desnecessários.

      Nota

      Se selecionar Upgrade by replacing system disk, ative a criação automática de snapshot. Snapshots incorrem em custos. Consulte Snapshot billing.

    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 Fixes for failed check items ou visualize o Check Report para solucionar o problema.

      Durante a atualização, você pode:

      • Pause: Coloca o node pool 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 versões do kubelet ou do container runtime em nós já atualizados.

      • Cancel: Cancela a atualização. Após clicar em Cancel, não é possível reverter versões do kubelet ou do container runtime 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 container runtime 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 do disco do sistema seguem este processo. A atualização do node pool 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.

    image

    Lógica de atualização in-place

    1. Execute uma verificação pré-atualização. Se uma exceção crítica for encontrada em um contêiner (por exemplo, solicitações ttrpc não puderem ser atendidas ou processos de contêiner não responderem a sinais), a atualização será interrompida.

    2. Salve o estado atual dos contêineres e pods em um diretório temporário.

    3. Atualize o containerd, crictl e arquivos de configuração relacionados para as novas versões fornecidas pelo ACK e, em seguida, reinicie o containerd. Esta ação não afeta contêineres em execução. Se você modificou anteriormente o arquivo de configuração /etc/containerd/config.toml no nó, suas alterações serão sobrescritas por esta atualização.

    4. Garanta que o kubelet esteja funcionando corretamente e que o nó esteja pronto.

    Lógica de atualização por substituição

    1. Execute a drenagem do nó. Se o nó for agendável, o sistema o defina como não agendável.

    2. Desligue a instância ECS, o que para o nó.

    3. Substitua o disco do sistema. O ID do disco do sistema muda, mas o tipo de disco em cloud, o endereço IP da instância e o endereço MAC da interface de rede elástica permanecem os mesmos.

    4. Reinicialize o nó.

    5. Reinicie o nó. O nó fica pronto e é definido como agendável.

      Se um nó estava não agendável antes da atualização, ele permanece não agendável depois.

    Perguntas frequentes

    Reversão após atualização

    Não é possível reverter as versões do kubelet e do container runtime após uma atualização. É possível reverter o SO, mas apenas se o node pool ainda suportar a imagem original.

    Impacto no service durante a atualização

    Atualização in-place: Os pods não são reiniciados, portanto, os serviços não são afetados.

    Atualização por substituição do disco do sistema: Este método realiza a drenagem do nó. Os serviços continuam sem interrupção se os pods implementarem desligamento gracioso (consulte Graceful shutdown and zero downtime deployments in Kubernetes) e tiverem múltiplas réplicas distribuídas pelos nós. Defina atualizações simultâneas abaixo da sua contagem de réplicas para evitar a atualização de múltiplas réplicas ao mesmo tempo.

    Duração do lote de atualização

    Atualização in-place: Menos de 5 minutos.

    Atualização por substituição do disco do sistema: Geralmente menos de 8 minutos sem snapshots. Com snapshots, a atualização começa após a conclusão do snapshot, e o tempo total depende do tempo de criação do snapshot. O node pool permite até 40 minutos para a criação do snapshot. Se a criação do snapshot exceder 40 minutos, a atualização expira e falha. Ignore a criação de snapshot se não houver dados de negócios no disco do sistema.

    Perda de dados durante a atualização

    Ao atualizar o container runtime substituindo o disco do sistema, faça backup de quaisquer dados importantes do disco do sistema antecipadamente. Discos de dados não são afetados.

    Alterações de endereço IP após substituição

    Quando o disco do sistema é substituído, seu ID muda, mas o tipo de disco em cloud, o endereço IP da instância e o endereço MAC da interface de rede elástica permanecem os mesmos. Consulte Replace the system disk (change the OS).

    Atualizando nós não gerenciados

    Clusters criados antes da introdução do recurso de node pool podem conter nós não gerenciados. Você pode migrar esses nós não gerenciados para um node pool e então atualizar o node pool. Consulte Migrate unmanaged nodes to a node pool.

    Diretório docker residual após migração

    O diretório docker contém arquivos gerenciados pelo Kubernetes (contêineres, imagens, logs) e quaisquer caminhos personalizados que você criou. Exclua-o do disco de dados após trocar de runtime se não for mais necessário.

    Restaurando dados de snapshots

    Ao atualizar um node pool, você pode criar snapshots para os nós. Os snapshots são retidos por sete dias por padrão, mas podem ser excluídos antes. Em casos extremos, como perda de dados, restaure os dados usando os seguintes métodos.

    • Para uma atualização in-place, como atualizar apenas a versão do kubelet, você pode restaurar dados revertendo o snapshot diretamente. Consulte Roll back a cloud disk by using a snapshot.

    • Para uma atualização por substituição do disco do sistema, como atualizar o sistema operacional ou o container runtime, você pode restaurar dados criando um novo disco em cloud a partir do snapshot. Consulte Create a data disk from a snapshot.

    Resolvendo o problema de dentry negativo

    A execução de atualizações do kubelet e do containerd aciona o systemctl daemon-reload. O service systemd monitora diretórios associados a .path unit s e seus pais (por padrão /, /run e /run/systemd). Muitos inodes nesses diretórios podem causar um soft lockup no kernel, afetando a operação do nó.

    Como as contagens de inodes não podem ser obtidas diretamente, limpe os dentries em horários de baixa demanda:

    echo 2 > /proc/sys/vm/drop_caches
    Se os diretórios associados às .path unit e seus pais não contiverem muitos inodes, ignore esta verificação.

    Referências