Para evitar riscos de segurança e estabilidade associados a versões desatualizadas e aproveitar os recursos mais recentes do Kubernetes e o suporte técnico, atualize a versão do seu cluster em tempo hábil. O ACK oferece verificações prévias, políticas de atualização configuráveis, controle de ritmo e monitoramento de progresso para facilitar a conclusão da atualização do cluster.
Por que atualizar
O ACK permite criar clusters usando as três versões secundárias mais recentes do Kubernetes. Por exemplo, se o ACK oferece suporte ao Kubernetes 1.31, 1.32 e 1.33, você não pode mais criar clusters com a versão 1.30. Também não é possível criar clusters com versões de patch expiradas. Para mais informações, consulte o version guide.
Manter uma versão desatualizada apresenta riscos de segurança e estabilidade. Quando uma versão deixa de ser suportada, seu cluster não recebe novos recursos, correções de bugs ou suporte técnico tempestivo, ficando vulnerável a falhas de segurança não corrigidas.
Atualize seus clusters de forma proativa e em tempo hábil para obter os recursos e correções de bugs mais recentes, além de receber suporte técnico mais tempestivo.
Importante
Ao atualizar um cluster, o ACK executa verificações prévias. No entanto, essas verificações não detectam todas as configurações de funcionalidades ou APIs incompatíveis. De acordo com o shared responsibility model, é sua responsabilidade manter-se informado sobre os lançamentos de versões lendo a documentação e monitorando as mensagens internas e do console. Antes de atualizar um cluster, revise as considerações de atualização da versão de destino.
Impacto da atualização
O ACK fornece políticas de atualização em fases e em lotes para garantir a continuidade e a estabilidade dos seus serviços durante a atualização do cluster.
Item | Descrição |
Verificação prévia | A verificação prévia identifica possíveis riscos de compatibilidade no cluster, como APIs obsoletas, versões de complementos incompatíveis e problemas com o status de nós ou discos, além de fornecer sugestões de correção. O resultado da verificação prévia não afeta as cargas de trabalho em execução no cluster. |
Atualização do plano de controle | Na maioria dos casos, a atualização não afeta os aplicativos em execução. Se um aplicativo for altamente dependente do API server, poderá ser necessário tentar reconectar devido a breves desconexões. Clusters gerenciados pelo ACK: O API server é gerenciado pelo ACK e é reiniciado de forma contínua durante a atualização. Clusters dedicados do ACK: Durante a atualização, o ACK atualiza localmente (in-place) cada nó master, um por vez.
Duração: Para clusters gerenciados pelo ACK e clusters serverless do ACK, a atualização é gerenciada pelo ACK e leva aproximadamente 5 minutos. Para clusters dedicados do ACK, os nós master são atualizados sequencialmente, um por vez. Cada nó leva aproximadamente 8 minutos. |
Atualização do node pool | Os nós são atualizados em lotes para garantir a continuidade do serviço. Personalize a política de atualização em lotes, como o número máximo de nós por lote e o intervalo entre lotes, para controlar o impacto nos seus serviços.
Atualização local (in-place): Os discos não são substituídos e os nós não são reinicializados. Os pods do aplicativo continuam em execução e os serviços não sofrem interrupção. Atualização com substituição de disco: O nó é drenado, o disco do sistema é substituído e o nó é reinicializado. Atenção aos seguintes itens: O ACK drena o nó e evicta os pods para outros nós disponíveis de acordo com o PDB. Para garantir alta disponibilidade, implante várias réplicas em vários nós. configure um
Pod Disruption Budget (PDB) para serviços críticos para controlar o número de pods que podem ser interrompidos simultaneamente.
O ACK reinicializa o nó com base nas configurações atuais do node pool, como o método de login do nó, a imagem do sistema operacional e a versão do runtime de contêiner. Normalmente, você deve atualizar as configurações do node pool ao editar o node pool. Se você modificou o nó de outras formas, as alterações serão sobrescritas durante a atualização. Se um pod no nó referenciar um HostPath que aponta para o disco do sistema, os dados no diretório HostPath serão perdidos após a atualização com substituição de disco.
Duração:
A duração depende do agrupamento dos nós em lotes. Uma atualização local leva de 5 a 10 minutos por lote. Uma atualização com substituição de disco sem snapshots leva aproximadamente 8 minutos. A duração exata varia conforme o tempo de drenagem do nó.
Se optar por criar snapshots, a atualização começa após a criação deles. O tempo necessário para criar snapshots depende do volume de dados.
|
Processo de atualização
A atualização de um cluster ACK envolve a atualização do plano de controle e dos node pools. Execute uma verificação prévia antes de atualizar e agende o processo para horários fora de pico. Após a atualização do plano de controle, verifique o status operacional do cluster e decida se deve atualizar os node pools.
Considerações sobre a atualização
Planos de controle
Atualize a versão do Kubernetes de um cluster ACK sequencialmente, passando pelas versões com suporte. Não há suporte para rollbacks. Para várias atualizações, monitore a estabilidade dos serviços do seu cluster após cada atualização antes de iniciar a próxima.
Revise o version guide e as notas de lançamento de cada versão para entender os detalhes da versão, as deprecated APIs e as considerações de atualização da versão de destino. Isso evita problemas de incompatibilidade causados por alterações de recursos em versões posteriores.
A atualização do plano de controle não afeta os aplicativos em execução. O API server é reiniciado de forma contínua durante a atualização. Se o seu aplicativo for altamente dependente do API server, ele precisa ter capacidade de tentar reconectar.
O Kubernetes 1.24 e versões posteriores não suportam o Docker como runtime de contêiner integrado. Ao atualizar um cluster da versão 1.22 para a 1.24 ou posterior, você deve seguir o guia Migrate the node container runtime from Docker to containerd.
Evite executar operações e manutenção (O&M) no cluster durante a atualização do plano de controle. Não implante nem atualize suas cargas de trabalho durante a atualização. Novos pods podem falhar na obtenção de endereços IP enquanto o API server estiver sendo reiniciado.
Node pools
-
Preparação pré-atualização
A atualização do cluster usa o yum para baixar os pacotes de software necessários. Se você modificou a configuração de rede dos nós no seu cluster ou usou uma imagem de sistema operacional personalizada, certifique-se de que o yum funcione corretamente nos nós. Execute yum makecache para verificar.
Imagens de sistema operacional personalizadas não são rigorosamente verificadas pelo ACK. O ACK não pode garantir totalmente o sucesso da atualização.
Se você fez alterações de configuração no cluster, como ativar uma partição SWAP ou modificar a configuração do kubelet ou do runtime ao fazer login nos nós em vez de usar o console do ACK ou a API (para o método com suporte, consulte Customize node pool kubelet configurations), a atualização do cluster pode falhar ou suas configurações personalizadas podem ser sobrescritas.
Em clusters que executam o Kubernetes 1.18 ou posterior, o ACK configura a Node resource reservation policy por padrão. Se a reserva de recursos não estiver configurada para o cluster e a utilização de recursos dos nós for alta, os pods evictados podem não ser agendados rapidamente após a atualização. Reserve recursos nos nós. Recomendamos que a utilização da CPU não exceda 50% e a utilização da memória não exceda 70%.
Em clusters que executam o Kubernetes 1.24 ou anterior, se os pods de uma carga de trabalho estiverem configurados apenas com uma startup probe, os pods entrarão em um breve estado NotReady após a reinicialização do kubelet. Recomendamos implantar várias réplicas e distribuir a carga de trabalho em vários nós para garantir que pods suficientes permaneçam disponíveis enquanto um nó é reiniciado.
Reserve pelo menos 20% do espaço em disco para evitar que os pods sejam evictados durante a atualização devido à falta de espaço em disco.
-
Restrições de atualização do node pool
Durante a atualização de um node pool, apenas o scale-out é suportado. Não há suporte para scale-in.
Se um nó for não gerenciado, ou seja, um nó worker que não é gerenciado por nenhum node pool, consulte Migrate unmanaged nodes to a node pool para migrá-lo.
Quando os nós são atualizados por substituição de disco, o ACK reinicializa os nós com base na configuração atual do node pool, como o método de login do nó, rótulos, taints, imagem do sistema operacional e versão do runtime. Normalmente, a configuração do node pool deve ser atualizada ao edite a node pool. Se você alterou os nós por outros métodos, essas alterações serão sobrescritas durante a atualização.
Se um pod em um nó referenciar um volume HostPath que aponta para o disco do sistema, os dados no diretório HostPath serão perdidos após a 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 padrão dele.
-
dimensionamento de nós e agendamento
Se o recurso de dimensionamento de nós estiver ativado para o cluster, para garantir que o auto scaling não seja afetado, o cluster atualiza automaticamente o cluster-autoscaler para a versão mais recente após a conclusão bem-sucedida da atualização. Após a atualização, verifique se a versão do cluster-autoscaler está correta. Para mais informações, consulte ative node autoscaling.
Durante a atualização do cluster, os nós cujo Scaling Mode está definido como Swift podem falhar na conclusão da atualização porque os nós são desligados. Se algum nó permanecer sem atualização após o término do processo devido ao modo Swift, recomendamos remover o nó manualmente.
-
Rede e disponibilidade de serviço
Se um pod acessar outro pod no mesmo nó por meio do endereço do Server Load Balancer (SLB) de um service LoadBalancer, e o externalTrafficPolicy do service estiver definido como Local, os dois pods podem não residir mais no mesmo nó após a rotação do nó, o que pode causar falhas de rede.
-
Quando os nós são atualizados por substituição de disco, o ACK drena os nós e evicta os pods para outros nós disponíveis de acordo com o Pod Disruption Budget (PDB). Para garantir alta disponibilidade do serviço, recomendamos implantar várias réplicas e distribuir as cargas de trabalho em vários nós, além de configurar um PDB para cargas de trabalho críticas para controlar o número de pods que podem ser interrompidos simultaneamente.
O tempo limite padrão para a drenagem de nós é de 30 minutos. Se a migração do pod não for concluída dentro do tempo limite, o ACK encerra a atualização para garantir a estabilidade do serviço.
Métodos de atualização
Atualização local e atualização com substituição de disco
Para atualizações do plano de controle, o ACK gerencia o processo para clusters gerenciados pelo ACK e clusters Serverless do ACK. Os clusters dedicados do ACK são atualizados localmente.
Para a atualização de um node pool, o ACK oferece dois métodos: atualização local e atualização com substituição de disco.
-
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, as 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 as configurações do containerd ou do kubelet, consulte Customize node pool kubelet configurations e Customize containerd configurations for a node pool .
-
Atualização com substituição de disco: Este método substitui o disco do sistema e reinicializa o nó. Embora os endereços IP e as montagens de disco de dados permaneçam inalterados, todos os dados no disco do sistema são excluídos. Ative os snapshots de disco e faça backup do disco do sistema antes de prosseguir.
Os discos de dados conectados ao nó não são afetados.
Após uma atualização com substituição de disco, a senha de login padrão da instância ECS torna-se inválida. Reset the password .
Casos especiais
Uma atualização com substituição de disco é 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 o Docker como runtime integrado. Migre para o containerd usando uma atualização com substituição de disco.
Para mais informações, consulte Migrate the node container runtime from Docker to containerd .
-
Alterações no sistema operacional: A partir da versão 1.30, o CentOS e o Alibaba Cloud Linux 2 não são mais suportados. Use uma atualização com substituição de disco para mudar para um operating system com suporte.
Para mais informações, consulte Change the operating system .
Node pools do Windows: O Upgrading Windows node pools requer uma atualização com substituição de disco.
Alternativa: atualização contínua (rolling upgrade) por meio de um novo node pool
Em vez de atualizar os nós existentes, realize uma atualização contínua criando um novo node pool com a configuração de destino. Migre os aplicativos gradualmente definindo o node pool antigo como não agendável (unschedulable) ou atualizando o agendamento da carga de trabalho. Após verificar a migração, exclua o node pool antigo.
Você é cobrado por ambos os node pools enquanto eles coexistem; exclua o pool antigo logo após a migração para gerenciar os custos.
Perguntas frequentes
-
Como atualizo meu cluster manualmente?
Para mais informações, consulte Manually upgrade a cluster. Primeiro, conclua a verificação prévia. Em seguida, execute a atualização e verifique se o resultado atende às suas expectativas.
-
Quais são as práticas recomendadas para atualizar um cluster?
Mantenha uma frequência regular de atualizações: Monitore o version guide, a documentação, e-mails e mensagens de texto. Atualize prontamente para garantir suporte e segurança contínuos.
Crie um plano de atualização: A atualização de um cluster envolve mais do que apenas mudar o número da versão. Envolve também APIs obsoletas, recursos descontinuados e grandes alterações. Crie um plano de atualização detalhado com base no tamanho do cluster e nas necessidades do negócio, e reserve uma janela de manutenção. Atualize durante horários fora de pico. Valide a atualização em um ambiente de teste antes de aplicá-la à produção. Após a atualização, verifique e monitore suas cargas de trabalho para confirmar que a atualização não afeta o seu negócio.
-
Use atualizações automáticas: Ative o recurso de automatic cluster upgrade. O ACK gera um plano de atualização com antecedência, 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.
Como alternativa, crie an ACK Auto Mode cluster. A versão do cluster é atualizada automaticamente pelo ACK.
-
Quanto tempo leva uma atualização de cluster?
Plano de controle: Para clusters gerenciados pelo ACK e clusters Serverless do ACK, a atualização é gerenciada pelo ACK e leva cerca de 5 minutos. Para um cluster dedicado do ACK, os nós master são atualizados sequencialmente, o que leva cerca de 8 minutos por nó.
Node pool: A duração depende da configuração de lotes dos nós. Uma atualização local leva de 5 a 10 minutos por lote. Uma atualização com substituição de disco 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 aguarda a criação dos snapshots. 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, você 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 os clusters permaneçam em um estado desatualizado por um período prolongado e realiza atualizações forçadas para levá-los a uma versão segura e estável.
Atualize a versão do seu cluster prontamente. Para mais informações, consulte Manually upgrade a cluster. Isso permite que você aproveite os recursos mais recentes e receba um suporte técnico melhor do ACK. Antes de atualizar, consulte as release notes da versão de destino para entender as alterações de recursos e notas importantes. Ative o recurso de automatic cluster upgrade para garantir que seu cluster seja atualizado automática e periodicamente.
-
O ACK suporta atualizações entre várias versões?
-
A versão do meu cluster é muito antiga. Como posso atualizá-la rapidamente?
Use uma das seguintes soluções.
Solução 1: Atualize o cluster uma versão secundária por vez. Após cada atualização, verifique se os aplicativos do seu negócio no cluster estão funcionando conforme o esperado antes de prosseguir com a próxima atualização. Para mais informações, consulte Manually upgrade a cluster.
Solução 2: Crie um cluster que execute a versão mais recente, migre gradualmente seus aplicativos para o novo cluster e, em seguida, exclua o cluster antigo. Para informações sobre como criar e configurar um cluster, consulte crie an ACK managed cluster.
-
Como faço para mudar do Docker para o containerd ao atualizar um cluster da versão 1.22 para a 1.24?
O ACK não suporta mais o Docker como runtime de contêiner integrado na versão 1.24 e posteriores. Migre o runtime de contêiner dos seus nós do Docker para o containerd.
Mude o runtime no node pool original usando o recurso de atualização do node pool, ou crie um novo node pool com containerd e migre suas cargas de trabalho. Para mais informações, consulte Migrate the container runtime of nodes from Docker to containerd.
-
Como o ACK garante a estabilidade durante a atualização de um cluster?
Um cluster ACK consiste em um plano de controle e node pools. Tanto para o plano de controle quanto para os node pools, os resultados da verificação prévia não afetam os aplicativos em execução, e o console fornece sugestões de reparo se uma verificação falhar.
Atualização do plano de controle: O ACK fornece um recurso de verificação prévia que inspeciona APIs obsoletas, compatibilidade de complementos, compatibilidade de configuração de recursos e componentes do plano de controle. Para mais informações, consulte Manually upgrade a cluster.
-
Atualização do node pool: A atualização de um node pool inclui a atualização do kubelet e do containerd. O ACK fornece um recurso de verificação prévia que inspeciona o status do nó, recursos do sistema, status do disco e ambiente de rede.
Configure também uma política de atualização para controlar o ritmo da atualização. Por exemplo, especifique os nós a serem atualizados, defina o número máximo de nós que podem ser atualizados em cada lote e configure uma política de pausa na atualização. Se os discos do sistema dos seus nós contiverem dados importantes do negócio, crie snapshots para os nós antes de atualizar o node pool. Para mais informações, consulte Upgrade a node pool.
-
O que devo saber antes de atualizar um cluster?
Não é possível reverter a atualização de um cluster. Primeiro, atualize um ambiente de teste e verifique o resultado; depois, atualize o ambiente de produção. Como alternativa, upgrade specific nodes first para verificação durante o processo de atualização.
As versões de componentes, recursos e recursos descontinuados suportados variam de acordo com a versão do Kubernetes. Para mais informações, consulte as release notes para diferentes versões.
Revise as notes on control plane upgrades.
Revise as notes on node pool upgrades.
-
Uma atualização forçada afeta minhas cargas de trabalho?
Uma atualização forçada é uma atualização local. Ela não substitui discos nem altera o sistema operacional ou o runtime de contêiner. Antes de atualizar forçadamente um cluster, o ACK notifica você com pelo menos um mês de antecedência por mensagem de texto, e-mail e mensagem interna.
Os seguintes clusters não são atualizados forçadamente:
-
Clusters com versões expiradas ainda podem ser usados normalmente?
Sim. No entanto, clusters que usam versões expiradas estão expostos a riscos de segurança e estabilidade. Atualize o cluster para uma maintained version o mais rápido possível.
Como os clusters ACK usam uma arquitetura gerenciada, esses riscos de segurança não afetam apenas o seu cluster, mas também podem impactar a segurança geral da Alibaba Cloud. Portanto, o ACK não permite que os clusters permaneçam em um estado desatualizado por um período prolongado e realiza uma atualização forçada para uma versão segura e estável. Para mais informações, consulte Mandatory upgrade of outdated versions.
-
Há suporte para reversão de versão após a atualização de um cluster?
Não. Não há suporte para reversões das versões do plano de controle, kubelet ou runtime de contêiner após uma atualização.
Durante a atualização de um node pool, se dados importantes do 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 eu precisar atualizar um cluster e migrá-lo para um cluster gerenciado ACK Pro?
Conclua primeiro a migração do cluster. Após verificar se seus serviços estão funcionando normalmente, inicie a atualização do cluster.
-
O que faço se a verificação prévia relatar APIs obsoletas?
Ao atualizar um cluster que executa o Kubernetes 1.20 ou posterior, o ACK verifica se a versão atual usa deprecated APIs. Esses resultados não bloqueiam a atualização e são apenas informativos. Corrija os problemas relatados antes da atualização para evitar afetar a operação normal do cluster na nova versão.
-
Como resolvo um aviso de "versão do componente muito baixa" nas verificações prévias?
Exceto pelos componentes do plano de controle e alguns componentes principais (como o kube-proxy), o ACK não atualiza outros complementos do cluster. Visualize os add-ons que precisam ser atualizados na página Add-ons no console. Consulte Component overview and release notes para saber mais sobre a compatibilidade de versões e os requisitos de atualização. Em seguida, atualize esses complementos durante horários fora de pico.
-
-
É normal que os nós gerem alertas durante uma atualização?
Os seguintes alertas temporários esperados podem ocorrer durante uma atualização. Nenhuma intervenção manual é necessária:
Alertas sobre falha na sincronização de ConfigMaps, Secrets e ServiceAccounts durante as reinicializações do kubelet.
Alertas de FailedMount durante atualizações com substituição de disco (os nós estão sendo reconstruídos).
Breves períodos em que os nós estão no estado NotReady.
Esses alertas se recuperam automaticamente após a conclusão da atualização e geralmente duram alguns minutos.
-
Posso atualizar um cluster se o vSwitch não tiver endereços IP disponíveis?
Uma atualização com substituição de disco requer endereços IP disponíveis para criar a rede ECS temporária para o novo disco do sistema. Se o vSwitch não tiver endereços IP disponíveis suficientes, configure Secondary CIDR blocks ou adicione um vSwitch que tenha mais endereços IP disponíveis ao node pool antes de atualizar.
-
Como resolvo uma falha de atualização com o erro "the aliyun service is not running on the instance"?
O cloud Assistant está indisponível, o que causa a falha do comando de atualização. Inicie ou pare o cloud Assistant e, em seguida, tente atualizar o cluster novamente. Para mais informações, consulte Start, stop, or uninstall cloud Assistant Agent.
-
Como resolvo um erro "PLEG not healthy" em um nó?
Este erro indica que o contêiner ou o runtime de contêiner não está respondendo. Reinicie o nó e tente a atualização novamente.
-
O que devo fazer se eu receber um erro "invalid object doesn't have additional properties" ao atualizar um cluster?
Após atualizar um cluster, atualize também a versão local do kubectl. Se você 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 instale and defina Up kubectl.