Como faço para planejar uma estratégia de atualização para um cluster do Amazon EKS?
Ao atualizar meu cluster do Amazon Elastic Kubernetes Service (Amazon EKS), quero seguir as melhores práticas.
Breve descrição
As novas versões do Kubernetes podem introduzir mudanças significativas em seu cluster do Amazon EKS. Depois de atualizar um cluster, não é possível fazer o downgrade do cluster. Ao atualizar para uma versão mais recente do Kubernetes, é possível migrar para novos clusters em vez de realizar atualizações de cluster no local. Se você optar por migrar para novos clusters, ferramentas de backup e restauração de clusters, como o Velero da VMware, podem ajudá-lo no processo. Para obter mais informações, consulte Velero no site do GitHub.
Para ver as versões atuais e anteriores do Kubernetes que estão disponíveis para o Amazon EKS, consulte o Calendário de lançamento do Amazon EKS Kubernetes.
Resolução
Prepare-se para um upgrade
Antes de começar a atualização do cluster, observe os seguintes requisitos:
- O Amazon EKS exige até cinco endereços IP disponíveis das sub-redes que você especificou ao criar seu cluster.
- O perfil e o grupo de segurança do AWS Identity and Access Management (IAM) do cluster devem existir na sua conta da AWS.
- Se você ativar a criptografia de segredos, o perfil do IAM do cluster deverá ter permissões de chave do AWS Key Management Service (AWS KMS).
Analise as principais atualizações do Amazon EKS e do Kubernetes
Analise todas as alterações documentadas para a versão atualizada e anote todas as etapas de atualização necessárias. Além disso, observe quaisquer requisitos ou procedimentos específicos dos clusters gerenciados pelo Amazon EKS.
Consulte os seguintes recursos para obter as principais atualizações das versões da plataforma de clusters do Amazon EKS e das versões do Kubernetes:
- Atualizar uma versão do Kubernetes do cluster do Amazon EKS
- Versões Kubernetes do Amazon EKS
- Versões da plataforma do Amazon EKS
Para obter mais informações sobre as versões upstream e as principais atualizações do Kubernetes, consulte a documentação a seguir:
- Kubernetes release notes no site do Kubernetes
- Changelog no site do GitHub
Entenda a política de descontinuação do Kubernetes
Quando uma API é atualizada, a API anterior é descontinuada e, por fim, removida. Para entender como as APIs podem ser descontinuadas em uma versão mais recente do Kubernetes, leia a política de descontinuação no site do Kubernetes.
Para verificar se você usa alguma versão obsoleta da API em seu cluster, use o Kube No Trouble (kubent) no site do GitHub. Se você usa versões descontinuadas da API, atualize suas workloadas antes de atualizar seu cluster Kubernetes.
Para converter arquivos de manifesto do Kubernetes entre diferentes versões da API, use o plugin kubectl convert. Para obter mais informações, consulte Install kubectl convert plugin no site do Kubernetes.
O que esperar durante uma atualização do Kubernetes
Quando você atualiza seu cluster, o Amazon EKS lança novos nós de servidor de API com a versão atualizada do Kubernetes para substituir os nós existentes. Se alguma dessas verificações falhar, o Amazon EKS reverterá a implantação da infraestrutura e seu cluster permanecerá na versão anterior do Kubernetes. No entanto, essa reversão não afeta nenhum aplicativo em execução e você pode recuperar qualquer cluster, se necessário. Durante o processo de atualização, você pode enfrentar pequenas interrupções no serviço.
Atualize o ambiente de gerenciamento e o plano de dados
Para atualizar um cluster do Amazon EKS, você deve atualizar dois componentes principais: o ambiente de gerenciamento e o plano de dados. Ao atualizar esses componentes, leve em conta as seguintes considerações.
Atualizações de cluster do Amazon EKS no local
Para atualizações no local, você pode atualizar somente para a próxima versão secundária mais alta do Kubernetes. Se houver várias versões entre a versão atual do cluster e a versão de destino, você deverá atualizar para cada versão sequencialmente. Para cada atualização do cluster Kubernetes no local, conclua as seguintes tarefas:
- Atualize seus manifestos do Kubernetes e atualize as APIs descontinuadas ou removidas, conforme necessário.
- Atualize o ambiente de gerenciamento do cluster.
- Atualize os nós em seu cluster.
- Atualize seus complementos e controladores personalizados do Kubernetes, conforme necessário.
Para obter mais informações, consulte Planejamento e execução de atualizações de versão do Kubernetes no Amazon EKS em Planejamento de upgrades do Kubernetes com o Amazon EKS. Além disso, consulte Práticas recomendadas para upgrades de cluster no site do GitHub.
**Migração de clusters azul/verde ou canário do Amazon EKS **
Uma estratégia de atualização azul/verde ou canário pode ser mais complexa, mas a estratégia permite atualizações com fácil capacidade de reversão e sem tempo de inatividade. Para uma atualização azul/verde ou canário, consulte Migração de clusters Amazon EKS azul/verde ou canário para workloads ArgoCD sem estado.
Atualize grupos de nós gerenciados do Amazon EKS
Importante: o kubelet de um nó não pode ser mais novo que o kube-apiserver. Além disso, não pode ser mais do que duas versões secundárias anteriores ao kube-apiserver. Por exemplo, suponha que kube-apiserver esteja na versão 1.24. Nesse caso, um kubelet é compatível apenas com as versões 1.24, 1.23 e 1.22.
Para atualizar completamente seus grupos de nós gerenciados, conclua as seguintes etapas:
- Atualize seus componentes do ambiente de gerenciamento de cluster do Amazon EKS para a versão mais recente.
- Atualize seus nós no grupo de nós gerenciados.
**Migre para grupos de nós gerenciados pelo Amazon EKS **
Se você usa grupos de nós autogerenciados, pode migrar sua workload para grupos de nós gerenciados pelo Amazon EKS sem tempo de inatividade. Para obter mais informações, consulte Migrar perfeitamente as workloads do grupo de nós autogerenciados do EKS para grupos de nós gerenciados pelo EKS.
Identifique e atualize as dependências downstream (complementos)
Os clusters geralmente contêm produtos externos, como controladores de entrada, sistemas de entrega contínua, ferramentas de monitoramento e outros fluxos de trabalho. Ao atualizar seu cluster do Amazon EKS, você também deve atualizar seus complementos e ferramentas de terceiros. Certifique-se de entender como os complementos funcionam com seu cluster e como eles são atualizados.
Observação: é uma prática recomendada usar complementos gerenciados em vez de complementos autogerenciados.
Analise os seguintes exemplos de complementos comuns e a documentação de atualização relevante:
- CNI da Amazon VPC: para ver a versão sugerida do complemento CNI da Amazon VPC a ser usada em cada versão do cluster, consulte Trabalhar com o complemento Amazon VPC CNI plugin for Kubernetes do Amazon EKS. Além disso, consulte Atualizar o conjunto de daemons aws-node para usar o IRSA no site do GitHub.
- Complemento autogerenciado kube-proxy: atualize para a versão mais recente da imagem do contêiner kube-proxy disponível para cada versão do cluster do Amazon EKS. Para obter mais informações, consulte Trabalhar com o complemento kube-proxy do Kubernetes.
- CoreDNS: atualize para a versão mais recente da imagem de contêiner CoreDNS disponível para cada versão do cluster do Amazon EKS. Para obter mais informações, consulte Atualização do complemento autogerenciado.
- Controlador AWS Load Balancer: as versões 2.5.0 ou posteriores do AWS Load Balancer Controller exigem as versões 1.22 ou posteriores do Kubernetes. Para obter mais informações, consulte Lançamentos do AWS Load Balancer Controller no site do GitHub. Para obter informações sobre a instalação, consulte Instalar o complemento AWS Load Balancer Controller.
- Driver da Interface de armazenamento de contêiner (CSI) do Amazon Elastic Block Store (Amazon EBS): as versões 1.25.0 ou posteriores do driver da CSI do Amazon EBS exigem as versões 1.23 ou posteriores do Kubernetes. Para obter mais informações, consulte Lançamentos de drivers CSI do Amazon EBS no site do GitHub. Para obter informações sobre instalação e atualização, consulte Gerenciar o driver da CSI do Amazon EBS como complemento do Amazon EKS.
- Driver da Interface de armazenamento de contêiner (CSI) do Amazon Elastic File System (Amazon EFS): as versões 1.5.8 ou posteriores do driver da CSI do Amazon EFS exigem as versões 1.22 ou posteriores do Kubernetes. Para obter mais informações, consulte Amazon EFS CSI driver releases no site do GitHub. Para obter informações sobre instalação e atualização, consulte Driver da CSI do Amazon EFS.
Atualize os nós do AWS Fargate
Para atualizar um nó Fargate, exclua o pod que o nó representa. Depois de atualizar seu ambiente de gerenciamento, reimplante o pod. Todos os novos pods que você iniciar no Fargate têm uma versão kubelet que corresponde à sua versão do cluster. Os pods Fargate existentes não são alterados.
Observação: para manter os pods do Fargate seguros, o Amazon EKS deve corrigi-los periodicamente. O Amazon EKS tenta atualizar os pods de forma a reduzir seus efeitos. No entanto, se os pods não puderem ser removidos com sucesso, o Amazon EKS os excluirá. Para minimizar as interrupções, consulte Aplicação de patches no sistema operacional do Fargate.
Atualize os nós sem grupos que a Karpenter cria
Quando você define um valor para ttlSecondsUntilExpired, esse valor ativa a expiração do nó. Depois que os nós atingem a idade definida em segundos, o Amazon EKS os exclui. Essa exclusão ocorre mesmo que os nós estejam em uso. Esse processo permite que você substitua os nós por instâncias recém-provisionadas e, portanto, que os atualize. Quando um nó é substituído, a Karpenter usa as AMIs otimizadas para Amazon EKS mais recentes. Para obter mais informações, consulte Disruption no site da Karpenter.
O exemplo a seguir mostra um nó que foi desprovisionado com ttlSecondsUntilExpired e, depois, substituído por uma instância atualizada:
apiVersion: karpenter.sh/v1alpha5kind: Provisioner metadata: name: default spec: requirements: - key: karpenter.sh/capacity-type # optional, set to on-demand by default, spot if both are listed operator: In values: ["spot"] limits: resources: cpu: 1000 # optional, recommended to limit total provisioned CPUs memory: 1000Gi ttlSecondsAfterEmpty: 30 # optional, but never scales down if not set ttlSecondsUntilExpired: 2592000 # optional, nodes are recycled after 30 days but never expires if not set provider: subnetSelector: karpenter.sh/discovery/CLUSTER_NAME: '*' securityGroupSelector: kubernetes.io/cluster/CLUSTER_NAME: '*'
Observação: a Karpenter não adiciona automaticamente instabilidade a esse valor. Se você criar várias instâncias em um curto período de tempo, elas expirarão quase ao mesmo tempo. Para evitar interrupções excessivas na workload, defina uma estimativa de interrupção do pod. Para obter mais informações, consulte Especificar um orçamento de interrupção para sua aplicação no site do Kubernetes.
Conteúdo relevante
- AWS OFICIALAtualizada há 3 anos
- AWS OFICIALAtualizada há 3 anos
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há um ano