Os clusters ACK Lingjun suportam atualizações do Kubernetes da versão 1.20 para a 1.22 por meio de atualizações in-place. Você pode atualizar todo o cluster em uma única operação ou atualizar o plano de controle e os pools de nós separadamente.
Como funciona
A atualização de um cluster ACK Lingjun segue estas etapas:
Execute uma verificação prévia. O ACK examina o cluster em busca de problemas de compatibilidade antes de aplicar qualquer alteração. Corrija todos os problemas relatados antes de prosseguir.
Atualize o plano de controle. O ACK atualiza o kube-apiserver, o kube-controller-manager e o kube-scheduler. Componentes do Kubernetes, como o kube-proxy, também são atualizados. Novos nós adicionados após esta etapa executarão a nova versão do Kubernetes.
Atualize os pools de nós. O ACK atualiza o kubelet e o runtime de contêiner nos nós existentes em lotes. Vários pools de nós são atualizados um por vez.
Verifique. Confirme a versão do cluster, o status dos pools de nós e a integridade das aplicações.
Pré-requisitos
Antes de começar, certifique-se de ter:
Acesso ao console do ACK
Lido as notas de versão da versão do Kubernetes para a qual deseja atualizar seu cluster
-
Lido as notas de versão da versão de destino do Kubernetes:
Revisado o suporte a versões do Kubernetes no ACK Lingjun
Observações de uso
Compatibilidade de versões do Kubernetes
Antes de atualizar, verifique a coluna Version na página Clusters do console do Container Service for Kubernetes para confirmar sua versão atual do Kubernetes. Se seus gráficos Helm utilizarem recursos de API obsoletos, atualize esses manifestos antes da atualização. Para obter detalhes sobre APIs obsoletas, consulte APIs obsoletas e as notas de versão correspondentes.
Para clusters que executam o Kubernetes 1.20 ou posterior, a verificação prévia também busca o uso de APIs obsoletas. O resultado é apenas informativo e não bloqueia a atualização.
Considerações específicas de recursos
Caso seu cluster utilize algum dos recursos abaixo, revise as considerações antes de iniciar a atualização.
| Recurso | O que ocorre durante a atualização | Ação necessária |
|---|---|---|
| FlexVolume | Volumes do Object Storage Service (OSS) montados pelo FlexVolume 1.11.2.5 ou anterior são remontados. | Recrie os pods que usam volumes OSS após a atualização. Migre do FlexVolume para CSI quando possível. Consulte Migrate from FlexVolume to CSI. |
| Auto scaling | O Cluster Autoscaler é atualizado automaticamente para a versão mais recente. | Verifique se o Cluster Autoscaler está executando a versão esperada. Consulte Auto scaling of nodes. |
| Reserva de recursos | Após a atualização para o Kubernetes 1.18, o ACK configura automaticamente a reserva de recursos. Se o uso de recursos do nó estiver alto, os pods evacuados podem falhar ao serem reagendados. | Reserve pelo menos 50% da CPU e 70% da memória em cada nó antes de atualizar. Consulte Resource reservation policy. |
LoadBalancer com externalTrafficPolicy: Local |
O tráfego é encaminhado apenas para pods locais ao nó. Se os pods da aplicação estiverem em outros nós, eles ficarão inacessíveis. | Verifique se externalTrafficPolicy: Local está definido em alguma instância do Server Load Balancer (SLB). Consulte What to do if the cluster cannot access the SLB IP address. |
| Aplicações dependentes do servidor de API | O servidor de API pode sofrer uma breve interrupção durante a atualização do plano de controle. Aplicações que usam operações list-and-watch são afetadas. | Configure sua aplicação para tentar novamente as operações watch automaticamente em caso de desconexão. Aplicações que não acessam o servidor de API não são afetadas. |
| kubectl | Após a atualização, o kubectl em sua máquina local pode ficar incompatível com a nova versão do servidor de API, causando erros invalid object doesn't have additional properties. |
Atualize o kubectl após a atualização do cluster. Consulte Install kubectl. |
Considerações sobre configurações personalizadas
|
Item |
Consideração |
|
Rede |
A atualização utiliza o yum para baixar pacotes. Se o seu cluster usa uma configuração de rede personalizada, verifique se o yum funciona corretamente executando |
|
Imagem do SO |
O ACK não valida imagens personalizadas do SO. O sucesso da atualização não é garantido para clusters que utilizam imagens personalizadas do SO. |
|
Outras configurações personalizadas |
Partições swap, configurações do kubelet modificadas via CLI ou outras configurações fora do padrão podem causar falha na atualização ou perda dessas definições. |
Atualizar o cluster
O ACK executa uma verificação prévia antes de cada atualização, mas essa verificação não garante a identificação de todas as APIs, recursos ou configurações incompatíveis. De acordo com o modelo de responsabilidade compartilhada, revise todas as notas de versão relevantes e as orientações de atualização antes de prosseguir.
Realize a atualização fora do horário de pico para minimizar o impacto nos negócios.
Etapa 1: Atualizar o plano de controle
Faça login no console do ACK. No painel de navegação à esquerda, clique em Clusters.
Na página Clusters, clique no nome do cluster que deseja atualizar. No painel à esquerda, escolha Operations > Upgrade Cluster.
-
Na página Upgrade Cluster, defina Destination Version e clique em Precheck. Após a conclusão da verificação prévia, analise os resultados na seção Pre-check Results:
Sem problemas: O cluster passou na verificação prévia. Prossiga para a próxima etapa.
Problemas encontrados: O cluster continua funcionando normalmente. Corrija os problemas relatados com base nas sugestões do console e execute a verificação prévia novamente. Consulte Itens de verificação do cluster e como corrigi-los.
Clique em Start Update e siga as instruções na tela. Visualize o histórico de atualizações no canto superior direito da página Upgrade Cluster. Após a conclusão da atualização do plano de controle, acesse a página Clusters e verifique a versão do Kubernetes na coluna Version.
Ações do ACK durante a atualização do plano de controle:
Atualiza os componentes do plano de controle: kube-apiserver, kube-controller-manager e kube-scheduler.
Atualiza componentes do Kubernetes, como o kube-proxy.
Etapa 2: Atualizar pools de nós
Após a atualização do plano de controle, atualize os pools de nós existentes o mais rápido possível. Os nós de um pool que ainda não foram atualizados continuam executando a versão anterior do Kubernetes.
Consulte Atualizar um pool de nós e Atualizar um pool de nós Lingjun para obter etapas detalhadas.
Ações do ACK durante a atualização de um pool de nós:
Atualiza o kubelet e o runtime de contêiner em cada nó.
Migração de Docker para containerd: Se você estiver trocando o runtime de contêiner de Docker para containerd, o ACK substitui o disco do sistema de cada nó, o que também atualiza o SO e reinstala as aplicações. Faça backup de quaisquer dados nos discos do sistema antes de iniciar esse tipo de atualização.
Em todos os outros cenários, o ACK realiza atualizações in-place.
Regras de atualização em lote:
Vários pools de nós são atualizados um por vez.
Dentro de um pool de nós, a atualização ocorre em lotes: 1 nó no primeiro lote, dobrando a quantidade em cada lote subsequente (1 → 2 → 4 → 8...).
Defina o tamanho máximo do lote na página Node Pool Upgrade. Recomenda-se um tamanho máximo de lote de 10.
A política de lotes continua a ser aplicada após a retomada de uma atualização pausada.
Verificar a atualização
Após a conclusão de ambas as fases, confirme os seguintes pontos:
A coluna Version na página Clusters exibe a nova versão do Kubernetes.
Todos os pools de nós estão em execução e íntegros.
As cargas de trabalho das aplicações no cluster estão funcionando conforme o esperado.
Confirme a versão do kubelet nos nós atualizados para verificar se a atualização do pool de nós foi concluída.
Solução de problemas
Falha na atualização com "the aliyun service is not running on the instance"
O agente do Cloud Assistant está indisponível, impedindo o envio do comando de atualização para o nó. Inicie ou reinicie o cliente do Cloud Assistant e tente a atualização novamente. Consulte Iniciar, reiniciar, parar ou desinstalar o agente do Cloud Assistant.
Erro PLEG not healthy
O contêiner ou o runtime de contêiner no nó não está respondendo. Reinicie os nós afetados e inicie a atualização novamente.