As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Práticas recomendadas para reversão de versões de cluster
Com a reversão da versão do Amazon Elastic Kubernetes Service (Amazon EKS), você pode reverter o plano de controle do Kubernetes do seu cluster para a versão secundária anterior em até 7 dias após uma atualização no local. Esta página descreve as melhores práticas para planejar, executar e operacionalizar a reversão como parte do fluxo de trabalho de upgrade.
Para obter detalhes dos pré-requisitos, procedimentos passo a passo e referência da API, consulte Reversão do cluster para a versão anterior do Kubernetes.
Entenda como o modelo de responsabilidade compartilhada se aplica à reversão
Quando você inicia uma reversão da versão do cluster, o Amazon EKS gerencia a reversão do plano de controle. Você é responsável pelo plano de dados, pelos complementos e pela compatibilidade do aplicativo. O seguinte descreve as responsabilidades:
-
O Amazon EKS gerencia: revertendo o servidor da API Kubernetes e os componentes do plano de controle. Para clusters de modo automático, o Amazon EKS também gerencia a reversão dos nós de trabalho.
-
Você é responsável por: reverter grupos de nós gerenciados, nós autogerenciados e nós híbridos. Você também deve validar a compatibilidade do complemento e garantir que seus aplicativos, controladores personalizados e ferramentas de terceiros funcionem corretamente com a versão anterior.
Para obter mais informações sobre o modelo de responsabilidade compartilhada para atualizações, consulte Entender como o modelo de responsabilidade compartilhada se aplica às atualizações de cluster.
Planeje atualizações com a reversão em mente
A reversão de versão funciona melhor quando seu fluxo de trabalho de atualização é projetado para manter a janela de reversão aberta.
-
Atualizações separadas do plano de controle e do plano de dados (clusters que não são do modo automático). Para clusters que usam grupos de nós gerenciados ou nós autogerenciados, considere primeiro atualizar o plano de controle e permitir um período de cozimento antes de atualizar os nós de trabalho. Enquanto os nós permanecem ativados N-1, a versão kubelet skew insight permanece no status PASSING. Isso mantém o caminho de reversão limpo sem precisar reverter os nós primeiro.
-
Atualize os complementos para versões compatíveis entre si. Antes de atualizar o plano de controle, certifique-se de que todos os complementos (gerenciados e autogerenciados) sejam compatíveis com as versões atual e de destino do Kubernetes. Isso mantém a visão clara da compatibilidade do complemento, tanto para atualização quanto para reversão.
-
Use os complementos gerenciados do Amazon EKS para se beneficiar dos insights de prontidão para reversão que verificam automaticamente a compatibilidade das versões dos complementos.
-
Evite o autogerenciamento de um complemento gerenciado (por exemplo, substituindo a versão fora do ciclo de vida do complemento EKS). Durante a reversão, os insights tratam a configuração gerenciada do complemento como a fonte da verdade e não detectarão a variação de versão que você introduziu.
-
-
Evite usar APIs específicas da versão durante o período de cozimento. Se você criar recursos que usam APIs ou recursos disponíveis somente na nova versão durante a janela de 7 dias, você deve removê-los antes de reverter. Limite a adoção de APIs somente para novas versões até ter certeza de que a atualização está estável.
-
Atualize mais cedo, não mais tarde. Com a reversão disponível, você pode fazer o upgrade com confiança logo após o lançamento de uma nova versão, em vez de esperar até prazos de suporte estendidos. A atualização antecipada oferece mais tempo para validar e reduz as cobranças de suporte estendido.
-
Esteja ciente das restrições de reversão do suporte estendido. Se seu cluster foi atualizado automaticamente no final do suporte estendido, você não pode reverter para a versão anterior. Se você recebeu o upgrade automático no final do suporte padrão, poderá reverter, mas primeiro deverá alterar a política de atualização para.
EXTENDED
Para obter diretrizes gerais de planejamento de atualizações, incluindo políticas de suspensão de uso, notas de versão e compatibilidade de complementos, consulte Melhores práticas para atualizações de cluster.
Analise os insights sobre a preparação para a reversão antes de reverter
O Amazon EKS apresenta insights pontuais sobre a prontidão para reversão na categoria de insights de cluster. ROLLBACK_READINESS Essas verificações são sua principal ferramenta para avaliar a segurança da reversão.
-
Analise os insights imediatamente após a atualização. Não espere até que algo dê errado. Após a atualização, verifique as informações de prontidão para reversão para conhecer sua postura atual de reversão.
-
Aborde os insights de ERRO de forma proativa. Se os insights mostrarem o status de ERRO logo após uma atualização, resolva-os mais cedo, enquanto a janela de 7 dias ainda estiver aberta. Quanto mais você esperar, maior a probabilidade de o estado do cluster divergir e novos bloqueadores aparecerem.
-
Entenda o que os insights abrangem e o que não abrangem. O Insights verifica as versões de complementos gerenciados do Amazon EKS, o uso da API, a distorção da versão e a integridade do cluster. Eles não verificam complementos autogerenciados, controladores personalizados ou compatibilidade em nível de aplicativo. Mantenha sua própria validação de compatibilidade para complementos autogerenciados (por exemplo, autoescalador de cluster, controladores de entrada, operadores personalizados, agentes de monitoramento).
Para ver a lista completa de verificações de insights e comportamento de status, consulte Reversão do cluster para a versão anterior do Kubernetes.
Preparar os nós do modo não automático para reversão
Para clusters que usam grupos de nós gerenciados, nós autogerenciados ou AWS Fargate, você é responsável por garantir que os nós de trabalho sejam compatíveis com a versão de reversão de destino.
-
Grupos de nós gerenciados. Você deve reverter seus grupos de nós gerenciados para a versão anterior antes de reverter o plano de controle. Use a
UpdateNodegroupVersionoperação com a versão anterior do Kubernetes. A reversão respeita suas configurações de atualização definidas (maxUnavailableestratégia de atualização). -
Self-managed e nós híbridos. Atualize suas AMIs ou configurações do node para usar a versão anterior do Kubernetes antes de reverter o plano de controle.
-
Fargate. A reversão de versão não é suportada pelos nós de trabalho do Fargate. Exclua os pods Fargate executando a mesma versão do plano de controle antes de iniciar a reversão ou use
--forcepara ignorar o insight de distorção de versão (o que pode resultar em um comportamento inesperado até que os pods sejam substituídos).
Para obter PodDisruptionBudget diretrizes de configuração abrangentes de topologia para garantir a disponibilidade da carga de trabalho durante as atualizações dos nós, consulte Práticas recomendadas para atualizações de cluster.
Gerencie os controles de interrupção do Amazon EKS Auto Mode para reversão
Para clusters que executam o Amazon EKS Auto Mode, a fase de reversão do nó pode ser a parte mais longa da operação. Seus controles de interrupção determinam diretamente a rapidez com que a reversão é concluída.
-
Analise os orçamentos de interrupção antes de iniciar a reversão. O Amazon EKS fornece informações sobre a prontidão de reversão para NodePool orçamentos disruptivos. Orçamentos definidos como 0 acionam um insight de ERRO, que bloqueia a reversão indefinidamente. Orçamentos e PodDisruptionBudgets (PDBs) restritivos acionam insights de advertência, que podem retardar a reversão, mas permitir o progresso. Aborde os insights de ERRO antes de iniciar a reversão.
-
Esteja preparado para ajustar os orçamentos durante a reversão. Se a reversão estiver demorando mais do que o esperado, você poderá ajustar os orçamentos de NodePool interrupção e os PDBs enquanto a reversão estiver em andamento.
kubectlAumentar o orçamento permite mais substituições simultâneas de nós. -
Remova as anotações do tipo “não interrompa” dos nós de bloqueio. A
karpenter.sh/do-not-disruptanotação nos nós bloqueia a reversão indefinidamente. Remova-o dos nós que devem ser substituídos. -
Acompanhe o progresso da reversão do node. Use
kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o widepara monitorar quais nós foram substituídos pela versão anterior da AMI. -
Use CancelUpdate se necessário. Se a reversão estiver demorando muito ou causando mais problemas do que solucionando, cancele a reversão. Após o cancelamento, os nós convergem de volta para a versão atual e você pode adotar uma abordagem diferente.
-
Defina um tempo limite apropriado. Use o
timeoutMinutesparâmetro inrollbackConfigpara se alinhar às suas expectativas operacionais. O padrão é 720 minutos (12 horas). Para clusters com orçamentos conservadores, considere aumentá-lo. Para IaC-managed clusters, alinhe-se com o tempo limite da sua ferramenta.
Para obter os procedimentos completos de reversão do modo automático e a CancelUpdate operação, consulte Reverter clusters do Amazon EKS Auto Mode.
Monitore o progresso da reversão
Durante uma reversão, use o seguinte para rastrear o status e detectar problemas:
-
DescribeUpdate operação. Use
describe-updatepara verificar o status atual da operação de reversão (InProgress,,SuccessfulFailed,Cancelled). Para acompanhar o andamento do cancelamento, verifique ocancellationobjeto na resposta. -
Insights de cluster. O Amazon EKS verifica novamente os insights antes de prosseguir com a reversão do plano de controle (após a conclusão da reversão do nó no modo automático). Monitore os novos insights de ERRO que possam ter aparecido.
-
Status do cluster. Para clusters de modo automático, o status do cluster permanece
ACTIVEdurante a reversão do nó e muda paraUPDATINGsomente durante a reversão do plano de controle. Não confie apenas no status do cluster para saber se uma reversão está em andamento — use.DescribeUpdate -
Versões do Node. No Modo automático, verifique as versões do Kubernetes do node para acompanhar o progresso da substituição do node. Para grupos de nós gerenciados, monitore o status de atualização do grupo de nós.
Gerencie clusters gerenciados por infraestrutura como código (IaC)
As ferramentas de infraestrutura como código (IaC) têm limitações de tempo limite que podem entrar em conflito com a duração da reversão do Modo Automático.
-
A AWS CloudFormation oferece suporte a até 36 horas por recurso. Se a reversão exceder isso, CloudFormation trate-a como algo autônomo, o que pode deixar o cluster em um estado de desvio em que o modelo não reflete a versão real do cluster. O tempo limite de reversão padrão é de 720 minutos (12 horas).
-
O Terraform Enterprise/Cloud tem tempos limite de aproximadamente 24 horas, embora os tempos limite do lado do cliente variem.
-
Alinhe-se
timeoutMinutesao tempo limite da sua ferramenta IaC para evitar que a ferramenta IaC atinja o tempo limite antes que o Amazon EKS conclua a reversão. -
Considere iniciar a reversão CLI/API para clusters do Modo Automático com orçamentos restritivos, em vez de por meio do IaC. Use
CancelUpdatediretamente se a camada de IAc atingir o tempo limite. -
A reversão do AWS CloudFormation Stack não aciona a reversão da versão. Se uma atualização da CloudFormation pilha da AWS falhar, a reversão automática da pilha para uma versão anterior do modelo não iniciará uma reversão da versão do cluster. Você deve iniciar explicitamente uma reversão de versão.
Use a reversão como uma rede de segurança, não como um fluxo de trabalho rotineiro
A reversão de versão foi projetada para ajudar você a se recuperar de problemas pós-atualização. Ele funciona melhor quando combinado com suas práticas de atualização existentes.
-
A reversão complementa o teste, não o substitui. Continue usando insights de cluster, testes de pré-atualização em ambientes que não são de produção e lançamentos por etapas. A reversão lida com os casos que os testes não conseguem detectar — os problemas que só surgem na produção.
-
A reversão reduz a necessidade de procedimentos manuais de backup e captura instantânea como seu principal mecanismo de segurança. Com a reversão nativa disponível, você não precisa mais depender apenas de instantâneos etcd ou scripts de reversão personalizados para recuperação de desastres durante as atualizações.
-
Os insights são os melhores esforços e são pontuais. O Amazon EKS os avalia quando você aciona a reversão. As alterações feitas após essa verificação (por exemplo, a criação de recursos com novas APIs) não são capturadas e podem causar problemas após a conclusão da reversão.
-
A reversão não garante a recuperação do aplicativo. O Amazon EKS reverte o plano de controle com segurança, mas seus aplicativos, configurações e dependências são de sua responsabilidade validá-los em relação à versão anterior.
A reversão reduz a necessidade de atualizações azul-esverdeadas
Organizações que antes usavam atualizações de cluster azul-esverdeadas principalmente para ter um “caminho de reversão” agora podem considerar atualizações locais com reversão de versão como alternativa. In-place as atualizações com reversão oferecem menor custo de infraestrutura (sem clusters duplicados), identidade de cluster consistente (mesmo endpoint de API, provedor de OpenID Connect (OIDC) e interfaces de rede elástica (ENIs)) e operações mais simples.
Blue-green ainda pode ser preferível quando você precisa alterar várias versões ao mesmo tempo, testar extensivamente as migrações de carga de trabalho ou manter o isolamento total do tráfego durante a validação. Para obter mais informações, consulte Avaliar Blue/Green clusters nas melhores práticas de atualizações de clusters.
Recursos relacionados
