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 dentro de 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 de seu fluxo de trabalho de upgrade.
Para obter detalhes sobre os pré-requisitos, procedimentos passo a passo e referência da API, consulte Reverter o cluster para a [versão](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html) 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 do Modo Automático, o Amazon EKS também gerencia a reversão de 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 [Entenda como o modelo de responsabilidade compartilhada se aplica às atualizações de cluster](cluster-upgrades.md).
## 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 de modo não automático).** Para clusters que usam grupos de nós gerenciados ou nós autogerenciados, considere primeiro atualizar o plano de controle e aguardar um período de preparação antes de atualizar os nós de trabalho. Enquanto os nós permanecem ativados N-1, a visão distorcida da versão kubelet permanece no status PASSING. Isso mantém o caminho de reversão claro 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 para atualização e 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 da versão do complemento.
+ Evite autogerenciar um complemento gerenciado (por exemplo, substituir a versão fora do ciclo de vida do complemento EKS). Durante a reversão, os insights tratam a configuração do complemento gerenciado como a fonte da verdade e não detectarão o desvio 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 o período de 7 dias, você deverá removê-los antes de revertê-los. 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 atualizar com confiança logo após o lançamento de uma nova versão, em vez de esperar até os prazos de suporte estendidos. A atualização antecipada oferece mais tempo para validar e reduz as taxas de suporte estendido.
+ **Esteja ciente das restrições de reversão do suporte estendido.** Se seu cluster foi atualizado automaticamente ao final do suporte estendido, você não poderá 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 orientações gerais sobre o planejamento de atualizações, incluindo políticas de suspensão de uso, notas de versão e compatibilidade de complementos, consulte [Melhores práticas](cluster-upgrades.md) para atualizações de clusters.
## Analise os insights de prontidão para a reversão antes de reverter
O Amazon EKS apresenta insights de prontidão para reversão pontual na categoria de insights de cluster. `ROLLBACK_READINESS` Essas verificações são sua principal ferramenta para avaliar a segurança de 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 os insights de prontidão para que você conheça 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 [Reverter o cluster para a versão anterior do Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html).
## Prepare 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 `UpdateNodegroupVersion` operação com a versão anterior do Kubernetes. A reversão respeita suas configurações de atualização definidas (`maxUnavailable`estratégia de atualização).
+ **Self-managed e nós híbridos.** Atualize as AMIs ou configurações do seu nó para usar a versão anterior do Kubernetes antes de reverter o plano de controle.
+ **Fargate.** A reversão de versão não é compatível com os nós de trabalho do Fargate. Exclua os pods do Fargate que executam a mesma versão do plano de controle antes de iniciar a reversão ou use `--force` para ignorar o insight de distorção da versão (o que pode resultar em um comportamento inesperado até que os pods sejam substituídos).
Para obter PodDisruptionBudget orientações de configuração distribuídas de topologia para garantir a disponibilidade da carga de trabalho durante as atualizações dos nós, consulte [Melhores práticas para atualizações de clusters](cluster-upgrades.md).
## 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.
+ **Revise os orçamentos de interrupção antes de iniciar a reversão.** O Amazon EKS fornece insights de prontidão para reversão para NodePool orçamentos disruptivos. Orçamentos definidos como 0 acionam uma visão de ERRO, que bloqueia a reversão indefinidamente. Orçamentos e PodDisruptionBudgets (PDBs) restritivos acionam insights de AVISO, 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. `kubectl` Aumentar o orçamento permite mais substituições simultâneas de nós.
+ **Remova as anotações de não interrupção dos nós de bloqueio.** A `karpenter.sh/do-not-disrupt` anotaçã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 nó.** Use `kubectl get nodes -l karpenter.sh/nodepool= -o wide` para 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 `timeoutMinutes` parâmetro in `rollbackConfig` para 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 ao tempo limite da sua ferramenta.
Para ver os procedimentos completos de reversão do Modo Automático e a `CancelUpdate` operação, consulte [Reverter clusters do Modo Automático do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html).
## 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-update` para verificar o status atual da operação de reversão (`InProgress`,, `Successful``Failed`,`Cancelled`). Para acompanhar o andamento do cancelamento, verifique o `cancellation` objeto na resposta.
+ **Insights do 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ó para o Modo Automático). Monitore novos insights de ERRO que possam ter surgido.
+ **Status do cluster.** Para clusters do Modo Automático, o status do cluster permanece `ACTIVE` durante a reversão do nó e muda para `UPDATING` somente 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.** Para o Modo Automático, verifique as versões do Kubernetes dos nós para acompanhar o progresso da substituição dos nós. 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 autônoma, o que pode deixar o cluster em um estado alterado 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 `timeoutMinutes` ao tempo limite da sua ferramenta de IaC para evitar que** a ferramenta de 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 `CancelUpdate` diretamente se a camada de IAc expirar.
+ **A reversão CloudFormation de pilha da AWS não aciona a reversão de 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. Funciona melhor quando combinado com suas práticas de atualização existentes.
+ **A reversão complementa o teste, mas não o substitui.** Continue usando insights de cluster, testes de pré-atualização em ambientes que não sejam de produção e lançamentos em etapas. O Rollback 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 de imagens como seu principal mecanismo de segurança.** Com a reversão nativa disponível, você não precisa mais depender apenas de instantâneos do etcd ou scripts de reversão personalizados para recuperação de desastres durante as atualizações.
+ **Os insights são o melhor esforço e o momento certo.** O Amazon EKS os avalia quando você aciona a reversão. As alterações feitas após essa verificação (por exemplo, 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 verde-azuladas principalmente para ter um “caminho de reversão” agora podem considerar atualizações no local 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ásticas (ENIs)) e operações mais simples.
Blue-green talvez ainda seja 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](cluster-upgrades.md) nas melhores práticas de upgrade de clusters.
## Recursos relacionados
+ [Reverta o cluster para a versão anterior do Kubernetes](https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html)
+ [Reverta os clusters do Amazon EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/rollback-automode-nodes.html)
+ [Práticas recomendadas para upgrades de clusters](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
+ [Insights de cluster](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html)
+ [Ciclo de vida da versão Kubernetes no EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html)