Container Service for Kubernetes:Upgrade clusters

1. Preparação

• Defina a versão de destino para a atualização com base nas notas de lançamento do ACK. O ACK suporta a atualização de apenas uma versão menor por vez. Não é possível pular versões ou reverter para uma anterior.

• Leia atentamente o guia de versões referente à versão de destino. Certifique-se de compreender as considerações de atualização, as principais alterações e os recursos obsoletos para evitar problemas de compatibilidade posteriores.

• Planeje uma janela de manutenção para o cluster. Execute verificações prévias com antecedência para identificar riscos potenciais e realize a atualização em horários de baixa demanda.

2. Atualização do plano de controle

1. Execute a verificação prévia: Antes de atualizar, execute a verificação prévia. Prossiga com a atualização somente depois que todos os itens forem aprovados ou todos os problemas identificados forem corrigidos.

   A verificação inspeciona itens como APIs obsoletas (para versão 1,20 e posteriores), compatibilidade de componentes, compatibilidade de configurações de recursos, status do cluster e status dos componentes do plano de controle.

2. Realize a atualização: Após a aprovação na verificação prévia, execute a atualização.

   • Clusters gerenciados pelo ACK e Clusters Serverless do ACK: O ACK gerencia a atualização. Ele atualiza os componentes do plano de controle, incluindo kube-apiserver, kube-controller-manager, kube-scheduler e kube-proxy.

   • Clusters dedicados do ACK: Utiliza-se a atualização local para maximizar a continuidade do serviço e reduzir riscos de migração de dados e ajustes de configuração.

     Clique para visualizar o processo

     1. Quando o ACK detecta que o etcd e o runtime de contêiner do seu cluster precisam ser atualizados, ele os atualiza nos nós mestres um por um.

     2. Os nós mestres são selecionados e atualizados individualmente. O ID do nó mestre atualmente em atualização é exibido.

     3. Atualize os componentes mestres, incluindo kube-apiserver, kube-controller-manager, kube-scheduler e kube-proxy.

     4. Atualize o kubelet nos nós mestres.

4. Verificação pós-atualização: Verifique se a versão do cluster foi atualizada e se os componentes principais, aplicações, criação de pods e adição de nós estão funcionando conforme o esperado.

3. Atualização do node pool

A atualização de um node pool envolve a atualização do kubelet e do runtime de contêiner.

1. Execute a verificação prévia: Antes de atualizar, execute a verificação prévia. Prossiga com a atualização somente após a aprovação de todos os itens ou correção dos problemas identificados.

   A verificação inspeciona itens como status do nó, recursos do sistema, status do disco e ambiente de rede.

2. Configure a política de atualização e execute-a: Escolha um método de atualização (local ou substituição de disco) e configure a política de atualização em lotes. Isso inclui especificar o número máximo de nós por lote e se snapshots devem ser criados automaticamente.

3. Verificação pós-atualização: Confirme se as versões do kubelet e do runtime de contêiner foram atualizadas e se o agendamento de pods e as aplicações estão operando normalmente.

4. Outros procedimentos

• Alterar a imagem do SO: Para atualizar a imagem do SO de um node pool ou trocar o tipo de SO (por exemplo, de Alibaba Cloud Linux 2 para Alibaba Cloud Linux 3), consulte Alterar o sistema operacional.

• Componentes do cluster: O ACK atualiza apenas o plano de controle e componentes essenciais como o kube-proxy. Atualize manualmente outros componentes do cluster através da página Add-ons durante horários de baixa demanda. Consulte a Visão geral dos componentes e notas de lançamento para requisitos de compatibilidade de versões.

Considerações sobre a atualização

Planos de controle

• É obrigatório atualizar a versão do Kubernetes de um cluster ACK sequencialmente, passando pelas versões suportadas. Não há suporte para rollbacks. Para realizar múltiplas atualizações, monitore a estabilidade dos serviços do seu cluster após cada etapa antes de iniciar a próxima.

• Antes de prosseguir, veja Atualizar clusters para uma visão geral. Revise o guia de versões e as notas de lançamento de cada versão. Assegure-se de entender os detalhes da versão, as APIs obsoletas e as considerações de atualização para evitar incompatibilidades causadas por mudanças de recursos em versões posteriores.

• A atualização do plano de controle não afeta aplicações em execução. O API Server é reiniciado de forma contínua durante o processo. Se sua aplicação depender fortemente do API Server, ela deve ser capaz de tentar reconexões automaticamente.

• O Kubernetes 1,24 e versões posteriores não suportam docker como runtime de contêiner nativo. Ao atualizar um cluster da versão 1,22 para 1,24 ou superior, você deve Migrar o runtime de contêiner do nó de docker para containerd.

• Evite executar operações e manutenção (O&M) no cluster durante a atualização do plano de controle.

Node pools

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

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

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

  • Se você fez alterações de configuração no cluster, como habilitar a partição SWAP ou modificar configurações do kubelet ou 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 configura 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ó for alto, os pods podem não ser agendados prontamente após serem evacuados. Reserve recursos para seus nós. Mantenha o uso de CPU em ou abaixo de 50% e o uso de memória em ou abaixo de 70%.

  • Em clusters executando a versão 1,24 ou anterior, se os pods de uma carga de trabalho estiverem configurados apenas com Startup Probe, eles entrarão brevemente no estado NotReady após o reinício do kubelet. Implante cargas de trabalho com múltiplas réplicas em 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. Isso evita a evacuação de pods causada por capacidade insuficiente de disco durante uma atualização.

• Restrições de atualização de 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 nós worker não gerenciados que não pertençam a um node pool, migre-os. Para mais informações, consulte Migrar nós não gerenciados para um node pool.

  • Não há suporte para atualizar node pools Lingjun durante a atualização de um 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 login, rótulos, taints, imagem do SO e versão do runtime. Para atualizar as configurações do node pool, consulte Editar um 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 aponta 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 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 padronizadas dele.

• dimensionamento de nós e agendamento

  • Se o recurso de dimensionamento de nós estiver habilitado no cluster, o cluster-autoscaler é 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 Habilitar dimensionamento automático de nós.

  • Durante a atualização do cluster, nós com 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 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 em diferentes nós. Além disso, configure um PDB para serviços críticos para 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 do período de tempo limite, o ACK encerra a atualização para garantir a estabilidade do serviço.

Métodos de atualização

Atualização local e substituição de disco do sistema

Para atualizações do plano de controle, o ACK gerencia o processo para Clusters gerenciados pelo ACK e Clusters Serverless do ACK. Clusters dedicados do ACK são atualizados usando atualização local.

Para atualização de node pool, o ACK oferece dois métodos: atualização local e atualização com substituição de disco do sistema.

• Atualização local: As atualizações são realizadas diretamente nos nós existentes sem substituir o disco do sistema ou reinicializar o nó. Os dados originais do nó não são afetados. Configurações relacionadas à instância ecs, como endereços ip e montagens de disco, permanecem inalteradas. No entanto, configurações de componentes gerenciados pelo ACK, como containerd e kubelet, podem ser ajustadas com base nas diferenças entre as versões dos componentes.

  Para personalizar configurações do containerd ou kubelet, consulte Personalizar configurações do kubelet do node pool e Personalizar configurações do containerd para um node pool .

• Atualização com substituição de disco do sistema: Este método substitui o disco do sistema e reinicializa o nó. Embora endereços ip e montagens de disco de dados permaneçam inalterados, todos os dados no disco do sistema são excluídos. Habilite snapshots de disco e faça backup do disco do sistema antes de prosseguir.

  Discos de dados anexados ao nó não são afetados.

Casos especiais

A atualização com substituição de disco do sistema é necessária nos seguintes cenários:

• Migração de runtime de contêiner: A partir da versão 1,24, o Kubernetes não suporta mais docker como runtime nativo. Você deve migrar para containerd usando o método de substituição de disco.

  Para mais informações, consulte Migrar o runtime de contêiner do nó de docker para containerd .

• Alterações no sistema operacional: A partir da versão 1,30, CentOS e Alibaba Cloud Linux 2 não têm suporte. Use a substituição de disco para mudar para um sistema operacional suportado.

  Para mais informações, consulte Alterar o sistema operacional .

• Node pools Windows: Atualizar node pools Windows requer o método de substituição de disco.

Alternativa: Atualização contínua via novo node pool

Em vez de atualizar os nós existentes, você pode realizar uma atualização contínua criando um novo node pool com a configuração de destino. Migre gradualmente as aplicações definindo o node pool antigo como não agendável ou atualizando o agendamento das cargas de trabalho. Uma vez verificada a migração, exclua o node pool antigo.

Você será cobrado por ambos os node pools enquanto coexistirem; remova o pool antigo prontamente após a migração para gerenciar custos.

FAQ

• Como atualizo meu cluster manualmente?

  Para mais informações, consulte Atualizar um cluster manualmente. Primeiro, complete a verificação prévia. Em seguida, execute a atualização e verifique se o resultado atende às suas expectativas.

• Quais são as melhores práticas para atualizar um cluster?

  • Mantenha uma frequência regular de atualizações: Acompanhe o guia de versões, documentos de ajuda e notificações oficiais. Atualize prontamente para garantir suporte contínuo e segurança.

  • Crie um plano de atualização: Como as atualizações envolvem mudanças importantes como APIs obsoletas, crie um plano detalhado baseado no tamanho do cluster e nas necessidades do negócio. Reserve uma janela de manutenção em horários de baixa demanda e valide a atualização em um ambiente de teste antes de aplicá-la em produção.

  • Use atualizações automáticas: Utilize o recurso de atualização automática de cluster. O ACK gera um plano de atualização antecipadamente, aciona uma verificação prévia e atualiza o cluster dentro da janela de manutenção especificada. Isso reduz a carga de trabalho de O&M no gerenciamento de versões.

    Você também pode criar um cluster gerenciado pelo ACK no Modo de Hospedagem Inteligente. O ACK atualiza a versão do cluster automaticamente.

• Quanto tempo leva uma atualização de cluster?

  • Plano de controle: Para Clusters gerenciados pelo ACK e Clusters Serverless do ACK, o ACK gerencia a atualização, que leva cerca de 5 minutos. Para um Cluster dedicado do ACK, os nós mestres são atualizados sequencialmente, o que leva cerca de 8 minutos por nó.

  • Node pool: A duração depende da configuração de lotes de nós. Uma atualização local leva cerca de 5 a 10 minutos por lote. Uma atualização com substituição de disco do sistema sem snapshots leva cerca de 8 minutos por lote, mas a duração real é afetada pelo processo de drenagem do nó. Se você optar por criar snapshots, o processo de atualização aguardará a criação dos mesmos. O tempo necessário para criar um snapshot depende da quantidade de dados.

• Posso permanecer em uma versão para sempre e não atualizar meu cluster?

  Não, não pode. Riscos potenciais de segurança em versões desatualizadas podem afetar não apenas seus clusters, mas também a segurança geral da Alibaba Cloud. O ACK não permite que clusters permaneçam em um estado desatualizado por um longo período e executa atualizações forçadas para trazê-los a uma versão segura e estável.

  Recomendamos que você atualize a versão do seu cluster prontamente. Para mais informações, consulte Atualizar um cluster manualmente. Isso permite que você se beneficie dos recursos mais recentes e receba melhor suporte técnico do ACK. Antes de atualizar, veja as notas de lançamento da versão de destino para entender suas mudanças de recursos e notas importantes. Habilite o recurso de atualização automática de cluster para garantir que seu cluster seja atualizado automática e periodicamente.

• O ACK suporta pular versões menores durante uma atualização?

  Não, não suporta. Você deve atualizar seu cluster uma versão menor por vez. Além disso, antes de atualizar o plano de controle do cluster, certifique-se de que a versão dos nós do cluster seja a mesma da versão do plano de controle.

• A versão do meu cluster é muito antiga. Como posso atualizá-lo rapidamente?

  Você pode usar uma das seguintes soluções.

  • Solução 1: Atualize o cluster uma versão menor por vez. Após cada atualização, verifique se suas aplicações de negócios no cluster estão funcionando conforme o esperado antes de prosseguir com a próxima atualização. Para mais informações, consulte Atualizar um cluster manualmente.

  • Solução 2: Crie um cluster que execute a versão mais recente, migre gradualmente suas aplicações para o novo cluster e, em seguida, despublique o cluster antigo. Para informações sobre como criar e configurar um cluster, consulte Criar um cluster gerenciado pelo ACK.

• Como mudo de docker para containerd ao atualizar um cluster da versão 1,22 para 1,24?

  O ACK não suporta mais docker como runtime de contêiner nativo na versão 1,24 e posteriores. Você deve migrar o runtime de contêiner dos seus nós de docker para containerd.

  Você pode trocar o runtime no node pool original usando o recurso de atualização de node pool, ou pode criar um novo node pool containerd e migrar suas cargas de trabalho. Para mais informações, consulte Migrar o runtime de contêiner dos nós de docker para containerd.

• Como o ACK garante estabilidade durante uma atualização de cluster?

  Um cluster ACK consiste em um plano de controle e node pools.

  • Atualização do plano de controle: O ACK fornece um recurso de verificação pré-atualização que inspeciona APIs obsoletas, compatibilidade de componentes, compatibilidade de configurações de recursos e componentes do plano de controle. Os resultados da verificação não afetam a operação normal das aplicações no cluster. Se a verificação falhar, o console exibirá sugestões de reparo. Para mais informações, consulte Atualizar um cluster manualmente.

  • Atualização de node pool: Uma atualização de node pool inclui a atualização do kubelet e do containerd. O ACK fornece um recurso de verificação pré-atualização que inspeciona o status do nó, recursos do sistema, status do disco e ambiente de rede. Os resultados da verificação não afetam a operação normal das aplicações no cluster. Se a verificação falhar, o console exibirá sugestões de reparo.

    Você também pode configurar uma política de atualização para controlar o ritmo da atualização. Por exemplo, você pode especificar os nós a serem atualizados, definir o número máximo de nós que podem ser atualizados em cada lote e configurar uma política de pausa de atualização. Se os discos do sistema dos seus nós contiverem dados importantes de negócios, você também pode criar snapshots para os nós antes de atualizar o node pool. Para mais informações, consulte Atualizar um node pool.

• O que devo saber antes de atualizar um cluster?

  Não é possível reverter uma atualização de cluster. Após a validação, atualize primeiro um ambiente de teste e, em seguida, atualize o ambiente de produção. Você também pode atualizar nós específicos primeiro para validação durante o processo de atualização.

  As versões de componentes suportadas, recursos e recursos obsoletos variam conforme a versão do Kubernetes. Para mais informações, consulte as notas de lançamento para diferentes versões.

  Revise as notas sobre atualizações do plano de controle.

  Revise as notas sobre atualizações de node pool.

• Clusters com versões expiradas ainda podem ser usados normalmente?

  Sim. No entanto, clusters desatualizados apresentam riscos de segurança e estabilidade. Atualize para uma versão mantida o mais rápido possível.

  Como os clusters ACK usam uma arquitetura gerenciada, esses riscos de segurança não afetam apenas seu cluster, mas também podem impactar a segurança geral da Alibaba Cloud. Portanto, o ACK não permite que clusters permaneçam em um estado desatualizado por um longo período e executa uma atualização obrigatória para uma versão segura e estável. Para mais informações, consulte Atualização obrigatória de versões desatualizadas.

• O rollback de versão é suportado após uma atualização de cluster?

  Não. Não há suporte para rollbacks do plano de controle, kubelet ou versões de runtime de contêiner após uma atualização.

  Durante uma atualização de node pool, se dados importantes de serviço estiverem armazenados no disco do sistema de um nó, crie um snapshot para o nó antes da atualização para fazer backup e restaurar os dados do nó.

• Qual operação devo realizar primeiro se precisar atualizar um cluster e migrá-lo para um cluster gerenciado ACK Pro?

  Conclua a migração do cluster antes de iniciar a atualização. Uma vez que os serviços sejam verificados como estáveis, prossiga com a atualização da versão.

• O que faço se a verificação prévia relatar APIs obsoletas?

  Para Kubernetes 1,20 ou posterior, o ACK fornece notificações para APIs obsoletas. Embora isso não bloqueie a atualização, corrija esses problemas antecipadamente para garantir a compatibilidade da aplicação com a nova versão.

• Como resolvo um aviso de "versão de componente muito baixa" nas verificações prévias?

  O ACK atualiza apenas o plano de controle e componentes principais selecionados como o kube-proxy. Identifique outros componentes que necessitam de atualização através da página Add-ons no console. Você pode visualizar os componentes que precisam ser atualizados. Antes de prosseguir, revise a Visão geral dos componentes e notas de lançamento para garantir compatibilidade de versões. Agende essas atualizações de componentes durante horários de baixa demanda para minimizar o impacto no serviço.

• Como resolvo uma falha de atualização com o erro "the aliyun service is not running on the instance"?

  Esse erro ocorre porque o Cloud Assistant está indisponível, o que causa falha no comando de atualização. Inicie ou reinicie o Cloud Assistant e tente a atualização do cluster novamente. Para mais informações, consulte Iniciar, parar ou desinstalar o Agente do Cloud Assistant.

• Como resolvo um erro "PLEG not healthy" em um nó?

  Esse erro indica que o contêiner ou runtime de contêiner não está respondendo. Reinicie o nó e tente a atualização novamente.

• O que devo fazer se receber um erro "invalid object doesn't have additional properties" ao atualizar um cluster?

  Após atualizar um cluster, você também deve atualizar sua versão local do kubectl. Se não o atualizar prontamente, poderá encontrar erros como invalid object doesn't have additional properties ao usar o kubectl local, pois sua versão difere da versão do API Server do cluster. Para mais informações sobre como instalar ou atualizar o kubectl, consulte Instalar e Configurar kubectl. É crítico sincronizar sua versão do kubectl com a versão do api server do cluster para prevenir problemas de compatibilidade.