Todos os produtos
Search

Este produto

    Container Service for Kubernetes:Update a node pool

    Central de documentação

    Container Service for Kubernetes:Update a node pool

    Última atualização: Jun 27, 2026

    Ao atualizar a versão do Kubernetes de um cluster, atualize primeiro o plano de controle e, em seguida, os node pools fora dos horários de pico. A atualização de um node pool inclui o kubelet e o container runtime. Antes de iniciar o processo, o ACK executa uma verificação prévia para identificar e relatar riscos potenciais, garantindo uma transição tranquila.

    Observações

    • Dimensionamento de nós

      • Se o dimensionamento de nós estiver ativado no cluster, o componente cluster-autoscaler será atualizado automaticamente para a versão mais recente após a atualização do cluster. Isso garante o funcionamento correto do recurso de Auto Scaling. Após a atualização do cluster, verifique se o componente cluster-autoscaler está executando a versão correta. Para obter mais informações, consulte Ativar dimensionamento automático de nós.

      • Durante a atualização de um cluster, nós com Scaling Mode definido como Swift podem falhar na atualização porque são desligados. Caso um nó com modo Swift não seja atualizado após a conclusão da atualização do cluster, remova esse nó manualmente.

    • Após atualizar um cluster para o Kubernetes 1.18, o ACK configura a reserva de recursos do nó 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 reagendados prontamente após a evicção. Reserve recursos para seus nós. Para obter desempenho ideal, a utilização da CPU não deve exceder 50% e a utilização da memória não deve exceder 70%. Para obter mais informações, consulte Política de reserva de recursos do nó.

    • Em clusters que executam o Kubernetes 1.24 ou anterior, se um pod em uma carga de trabalho estiver configurado apenas com uma sonda de inicialização (startup probe), ele poderá entrar no estado NotReady por um curto período após a reinicialização do kubelet. Adote uma estratégia de implantação com múltiplas réplicas para distribuir as cargas de trabalho entre vários nós. Essa abordagem assegura que haja pods disponíveis suficientes durante a reinicialização de um nó.

    • Caso um pod acesse outro pod no mesmo nó usando o endereço IP da instância SLB exposta por um serviço LoadBalancer, e o externalTrafficPolicy desse serviço estiver definido como Local, os dois pods poderão deixar de residir no mesmo nó após a substituição de um nó. Isso pode causar interrupções de rede.

    • O ACK não valida rigorosamente imagens personalizadas de sistema operacional (SO). Portanto, não há garantia de atualização bem-sucedida para clusters que utilizam uma imagem personalizada de SO.

    • Durante a atualização de um cluster, o yum baixa os pacotes de software necessários. Se você modificou as configurações de rede dos seus nós ou usou uma imagem personalizada de SO, certifique-se de que o yum funcione corretamente nos nós. Execute o comando yum makecache para verificar seu status.

    • Se você fez alterações personalizadas na configuração do cluster, como ativar a partição SWAP ou modificar configurações do kubelet ou do container runtime via linha de comando, o processo de atualização poderá falhar ou suas configurações personalizadas poderão ser sobrescritas.

    • Ao atualizar um nó substituindo seu disco do sistema, o ACK drena o nó. Os pods são evacuados para outros nós disponíveis de acordo com o PodDisruptionBudget (PDB) configurado. Para garantir alta disponibilidade do serviço, use uma estratégia de implantação com múltiplas réplicas para distribuir as cargas de trabalho entre vários nós. Configure também 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 a drenagem do nó é de 30 minutos. Se a migração dos pods não for concluída dentro desse prazo, o ACK encerra a atualização para garantir a estabilidade do serviço.

    • Ao atualizar um nó substituindo seu disco do sistema, o ACK reinicializa o nó com base na configuração atual do node pool, incluindo método de login do nó, rótulos, taints, imagem do SO e versão do container runtime. Normalmente, atualiza-se a configuração de um node pool editando o node pool. Caso tenha modificado um nó por outros métodos, essas alterações serão sobrescritas durante a atualização.

    • Se um pod em um nó utilizar um volume HostPath que aponte para o disco do sistema, os dados nesse diretório serão perdidos após uma atualização por substituição do disco do sistema.

    • Durante a atualização de um node pool, apenas operações de scale-out são suportadas. Operações de scale-in não são permitidas.

    • Caso um nó seja não gerenciado (um worker node que não pertence a nenhum node pool), migre-o primeiro para um node pool. Para obter mais informações, consulte Migrar nós não gerenciados para um node pool.

    • Ao atualizar um cluster ACK, não é possível atualizar node pools Lingjun.

    • Ao fazer upgrade de um node pool em um cluster com 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.

    Recursos

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

    • Atualização do Kubelet: Atualiza o kubelet nos nós de um node pool para a mesma versão do plano de controle. Por padrão, o ACK executa uma atualização in-place.

    • Atualização do container runtime: Quando uma nova versão do container runtime é lançada, atualize o container runtime nos seus nós para a versão mais recente.

      • Ao migrar o container runtime do Docker para o containerd, os nós no node pool são atualizados mediante a substituição de seus discos do sistema. Isso apaga todo o conteúdo do disco do sistema. Antes de iniciar a atualização, faça backup de todos os dados importantes do disco do sistema. Para obter mais informações, consulte Migrar o container runtime do nó de Docker para containerd.

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

        Importante

      • Em clusters que executam o Kubernetes 1.24 ou anterior, ao atualizar o Docker para uma versão mais recente, o ACK atualiza os nós no node pool substituindo seus discos do sistema por padrão. Isso apaga todo o conteúdo do disco do sistema. Antes de iniciar a atualização, faça backup de todos os dados importantes do disco do sistema.

    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 node pool que deseja atualizar e escolha image > Kubelet Update na coluna Actions. Configure os parâmetros conforme descrito na tabela a seguir.

      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 e selecione a versão de destino do runtime.

      • Ao migrar o container runtime do nó de Docker para containerd, os nós no node pool são atualizados substituindo seus discos do sistema. Esse processo apaga todo o conteúdo dos discos do sistema.

      • Se o seu cluster executa o Kubernetes 1.22 e a versão instalada do containerd é 1.6.34 (uma versão relativamente nova), as atualizações não são suportadas.

      Update Nodes

      Especifique os nós a serem atualizados: todos os nós ou nós específicos.

      Método de atualização

      Selecione um método de atualização. São suportados o In-place Upgrade e o Upgrade by Replacing System Disk. Para obter informações sobre a lógica e o processo de atualização, consulte Informações de referência: Atualizações in-place e atualizações por substituição de disco do sistema.

      • In-place Upgrade: Atualiza os componentes necessários nos nós existentes. Este método não substitui o disco do sistema nem reinicializa o nó, e não afeta os dados no nó.

      • Upgrade by Replacing System Disk: Reinicializa o nó substituindo seu disco do sistema. As propriedades da instância do nó, como nome, ID e endereço IP, permanecem inalteradas, mas todos os dados no disco do sistema são apagados. Dados em discos de dados montados separadamente não são afetados.

      Ignore Warnings

      Indica se deve prosseguir caso a verificação prévia relate avisos. Por exemplo, um pod usa um hostPath apontando para o disco do sistema.

      Batch Update Policy

      Maximum Number of Nodes per Batch

      O ACK atualiza os nós em lotes com base no número máximo de nós simultâneos especificado por você. Para obter mais informações sobre o processo de atualização, consulte Informações de referência: Atualizações in-place e atualizações por substituição de disco do sistema.

      Automatic Pause Policy

      A política de pausa para o processo de atualização de nós.

      Interval Between Batches

      Se você definir a Política de Pausa Automática como Não definir, poderá especificar um intervalo de tempo entre os lotes de atualização. O valor varia de 5 a 120 minutos.

      Auto Snapshot

      Se o disco do sistema do seu nó contiver dados comerciais importantes, crie um snapshot para o nó antes de atualizar o node pool. Isso permite fazer backup e restaurar dados do nó. A criação de snapshots gera custos. Para obter mais informações, consulte Preços de snapshot. O progresso da criação é atualizado em tempo real. Se o snapshot não for mais necessário após a atualização, exclua-o prontamente.

      Nota

      Se você selecionar Upgrade By Replacing System Disk como método de atualização, ative o Auto Snapshot. A criação de snapshots gera custos. Para obter mais informações, consulte Preços de snapshot.

    4. Após concluir as configurações, clique em Precheck. Depois que a verificação prévia for aprovada, siga as instruções na tela para iniciar a atualização.

      Nota

      Se a verificação prévia falhar ou retornar avisos, consulte Soluções para itens de verificação com falha ou visualize o Pre-check Report conforme solicitado para solucionar os problemas.

      Durante a atualização, execute as seguintes operações conforme solicitado:

      • Pause: Pausar a atualização de um cluster é um estado intermediário. Não execute outras operações no cluster durante esse período e conclua o processo de atualização o mais rápido possível. Se uma atualização permanecer pausada por mais de sete dias, o ACK encerra automaticamente o processo e limpa todos os eventos e logs relacionados.

        Após pausar a atualização, não é possível reverter as versões do kubelet e do container runtime 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 e do container runtime em nós já atualizados.

      Após a atualização, acesse a página Nodes, clique no nome de um nó e, em seguida, clique na aba Basic Information para verificar se as versões do kubelet e do container runtime estão corretas.

    Atualizações in-place e substituições de disco do sistema

    Processo de atualização in-place e por substituição

    A seção a seguir descreve os processos para atualizações in-place e atualizações por substituição de discos do sistema. O ACK atualiza os nós em um node pool em lotes com base no número máximo especificado de nós simultâneos. O número de nós em cada lote aumenta exponencialmente (1, 2, 4, 8 e assim por diante) até atingir o máximo especificado. Depois disso, cada lote subsequente prossegue com o número máximo de nós. Por exemplo, se você definir o número máximo de nós simultâneos como 4, um nó será atualizado no primeiro lote, dois nós no segundo e quatro nós no terceiro e em todos os lotes subsequentes.

    A figura abaixo mostra o processo de atualização em lotes onde o número máximo de nós simultâneos é N. O número de nós atualizados em cada lote é 1, 2, 4, 8 e assim por diante, até N.

    image

    Lógica de atualização in-place

    1. O ACK executa uma verificação prévia de atualização. Se for detectado um problema crítico no container, como falha ao processar solicitações ttrpc ou um processo de container que não responde a sinais, a atualização é interrompida.

    2. Os estados atuais dos containers e pods são salvos em um diretório tmp temporário.

    3. O sistema atualiza o containerd, crictl e arquivos de configuração relacionados para as novas versões fornecidas pelo ACK e, em seguida, reinicia o containerd. Essa ação não afeta os containers em execução. Se você modificou anteriormente o arquivo /etc/containerd/config.toml no nó, a atualização sobrescreverá suas alterações.

    4. O sistema garante que o kubelet esteja funcionando corretamente e que o nó esteja pronto.

    Lógica de substituição do disco do sistema

    1. O nó é drenado. Se o nó for agendável, o sistema o define como não agendável.

    2. A instância ECS é desligada.

    3. O disco do sistema é substituído. O ID do disco do sistema muda, mas o tipo de disco em nuvem, o endereço IP da instância e o endereço MAC da interface de rede elástica permanecem inalterados.

    4. O nó é reinicializado.

    5. O nó é reiniciado e fica pronto. Ao mesmo tempo, o nó é definido como agendável.

      Se você definiu um nó como não agendável antes do início da drenagem do nó, ele não será automaticamente redefinido como agendável após a conclusão da atualização.

    Perguntas frequentes

    Posso reverter um node pool após uma atualização?

    Não é possível reverter o kubelet ou o container runtime após uma atualização. Você só pode reverter o SO. Ao reverter o SO, é necessário garantir que o node pool ainda suporte a imagem original.

    Uma atualização afeta meus aplicativos?

    Atualização in-place: Os pods não são reiniciados e seus aplicativos não são afetados.

    Atualização por substituição do disco do sistema: Os nós são drenados durante esse tipo de atualização. Se seus pods implementarem a lógica de desligamento gracioso e forem implantados com múltiplas réplicas em diferentes nós, seus aplicativos não serão afetados. Para evitar que múltiplas réplicas do mesmo aplicativo sejam atualizadas no mesmo lote, defina manualmente o número máximo de nós simultâneos para um valor menor que o número de réplicas de pods.

    Quanto tempo leva cada 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 se nenhum snapshot for criado. Se você optar por criar um snapshot, a atualização começa após a criação do snapshot, e o tempo total depende do tempo de criação do snapshot. O processo de atualização do node pool concede 40 minutos para a criação do snapshot. Se o snapshot não for concluído dentro de 40 minutos, a atualização do nó expira e falha. Nesse ponto, a operação de atualização no nó ainda não começou. Se você não armazena dados comerciais no disco do sistema, pule a criação do snapshot para reduzir o tempo de atualização.

    Os dados do nó são perdidos durante uma atualização?

    Ao atualizar o container runtime substituindo o disco do sistema, não armazene dados importantes no disco do sistema ou certifique-se de fazer backup deles antecipadamente. Os dados em discos de dados não são afetados durante a atualização.

    Impacto no IP do nó após a substituição do disco do sistema

    Quando o disco do sistema é substituído, seu ID muda, mas o tipo de disco em nuvem, o endereço IP da instância e o endereço MAC da interface de rede elástica permanecem inalterados. Para obter mais informações, consulte Substituir o disco do sistema (sistema operacional).

    Como atualizar nós não gerenciados?

    Clusters criados antes da disponibilidade do recurso de node pool podem ter nós não gerenciados que não pertencem a nenhum node pool. Migre esses nós não gerenciados para um node pool e, em seguida, atualize o node pool. Para obter mais informações sobre como migrar nós não gerenciados, consulte Migrar nós não gerenciados para um node pool.

    Limpeza do diretório Docker após troca para containerd

    Além dos arquivos gerenciados pelo cluster Kubernetes, como containers, imagens e logs, o diretório Docker também contém caminhos de arquivos criados por você. Se não precisar mais do conteúdo do diretório Docker, exclua-o manualmente do disco de dados após trocar o runtime.

    Como restauro dados de um snapshot?

    Ao atualizar um node pool, crie um snapshot para cada nó. O snapshot é retido por sete dias por padrão, mas você pode excluí-lo manualmente antes disso. Em casos raros, como perda de dados após uma atualização, use um dos seguintes métodos para restaurar seus dados:

    • Se você executou uma atualização in-place (por exemplo, apenas a versão do kubelet foi atualizada), reverta o disco usando o snapshot. Para obter mais informações, consulte Reverter um disco em nuvem usando um snapshot.

    • Se você executou uma atualização substituindo o disco do sistema (por exemplo, o SO ou container runtime foi atualizado), crie um novo disco em nuvem a partir do snapshot para restaurar os dados. Para obter mais informações, consulte Criar um disco de dados a partir de um snapshot.

    Tópicos relacionados