 |
Atualizando um Kubernetes o plano de controle sempre foi uma porta de mão única. O Kubernetes de código aberto não oferece suporte à reversão do plano de controle, portanto, depois de atualizar, não há como voltar atrás. A comunidade está fazendo progressos reais aqui, e KEP-4330 introduz versões emuladas para facilitar a reversão. Mas, na prática, essa restrição levou as organizações a criar mecanismos de compensação elaborados, como períodos de preparação, grupos escalonados, aprovações automatizadas e ciclos de atualização que duram meses. Com o Kubernetes lançando três versões secundárias por ano, as equipes que gerenciam centenas de clusters, especialmente em ambientes regulamentados, muitas vezes atrasam totalmente as atualizações porque não têm certeza de que poderão se recuperar se algo der errado. O resultado são clusters presos em versões mais antigas, faltando patches de segurança e, eventualmente, enfrentando cronogramas de suporte estendidos.
Hoje estamos anunciando o Kubernetes reversões de versão para Serviço Amazon Elastic Kubernetes (Amazon EKS)um novo recurso que oferece aos administradores de cluster uma rede de segurança ao realizar atualizações de cluster. Com reversões de versão, você pode reverter uma atualização de versão do Kubernetes dentro de sete dias se encontrar problemas após a atualização, retornando seu cluster ao estado de funcionamento anterior.
Onde abordagens como versões emuladas mantêm um cluster em um estado de retenção transitório, a reversão de versão do EKS retorna seu cluster para uma versão anterior totalmente validada que foi executada em produção, e não uma emulação dela. Agora, se você atualizar um cluster de, digamos, Kubernetes 1.34 para 1.35 e descobrir um problema de compatibilidade, poderá reverter para 1.34 em sete dias. Não há necessidade de reconstruir seu cluster ou se esforçar para solucionar problemas sob pressão. Pense nisso como um botão de desfazer para atualizações de versão do Kubernetes.
O recurso oferece suporte à reversão de uma versão secundária por vez, correspondendo à mesma abordagem incremental que o EKS usa para atualizações. E para ajudá-lo a reverter com segurança, o EKS avalia automaticamente a prontidão para reversão do seu cluster por meio de insights de clustersinalizando itens como compatibilidade de versão do nó ou dependências complementares antes de continuar. Se você já avaliou a situação e deseja agir rapidamente, você pode usar o --force sinalizador para ignorar essas verificações. O acima se aplica a todos os clusters EKS, quer você gerencie seus próprios nós ou deixe a AWS cuidar deles. Mas para os clientes que adotaram uma infraestrutura totalmente gerenciada, a reversão vai um passo além.
Reversão para o modo automático EKS
Modo automático EKS oferece implantação com um clique de clusters Kubernetes prontos para produção, automatizando o gerenciamento de computação, rede e armazenamento para que você possa se concentrar em seus aplicativos em vez de na infraestrutura. O modo automático EKS introduz considerações adicionais para reversões de versão porque tanto o plano de controle quanto os nós gerenciados precisam ser revertidos juntos. Como as reversões de nós respeitam seus orçamentos de interrupção de pod, o processo pode levar algum tempo dependendo da sua configuração.
Para lhe dar controle sobre esse processo, introduzimos um cancelar API que permite interromper a reversão de um nó a qualquer momento. Se você decidir que a reversão está demorando muito ou quiser mudar sua abordagem, poderá cancelar e ajustar seus orçamentos de interrupção para acelerar as coisas ou escolher um caminho diferente a seguir.
Por padrão, o EKS nunca ignora seus orçamentos de interrupção durante uma reversão porque priorizamos a estabilidade da carga de trabalho. Você sempre pode optar por modificar ou remover orçamentos de interrupção para acelerar o processo, se necessário.
Vamos experimentar
Para tentar reversões de versão, naveguei até o console do Amazon EKS e selecionei um dos meus clusters que atualizei recentemente.
Na página de configuração do cluster, posso ver a opção de iniciar uma reversão de versão, juntamente com informações sobre minha janela de reversão atual.
Antes de iniciar a reversão, revisei os insights da reversão para verificar possíveis problemas. Os insights me mostraram o standing dos meus nós e sinalizaram qualquer coisa que eu deveria abordar antes de continuar.
Após a confirmação, a reversão começou. Meu cluster permaneceu funcional durante todo o processo. A reversão do plano de controle levou cerca de 20 minutos, semelhante a uma atualização padrão. Para meu cluster EKS Auto Mode, os nós foram revertidos normalmente de acordo com minhas configurações de orçamento de interrupção.
Depois de concluído, meu cluster voltou à versão anterior do Kubernetes, funcionando conforme o esperado.
Agora disponível
Kubernetes reversões de versão para Amazon EKS estão disponíveis hoje sem custo adicional em todas as regiões comerciais da AWS onde o Amazon EKS está disponível. Você paga apenas pelo EKS padrão e pelos custos de cálculo que normalmente incorreria. Não há custos adicionais para usar o recurso de reversão.
As reversões do plano de controle estão disponíveis para todos os clusters do EKS, e as reversões de nós estão disponíveis para clusters que executam o modo automático do EKS. As reversões de versão oferecem suporte a clusters que executam versões do Kubernetes disponíveis no suporte padrão e suporte estendido do EKS.
Para começar, visite o Documentação do Amazon EKS ou experimente diretamente no Console do Amazon EKS.