Como faço para planejar uma atualização para meu cluster do Amazon EKS?

Resolução

Entender o efeito de uma atualização

Novas versões do Kubernetes podem introduzir mudanças significativas em seu cluster do Amazon EKS. Depois de atualizar seu cluster, não é possível fazer o downgrade dele.

Se você atualizar para uma versão posterior do Kubernetes, não precisará realizar uma atualização de cluster no local. Em vez disso, é possível migrar para um novo cluster. Se você migrar para um novo cluster, é uma prática recomendada usar ferramentas de backup e restauração de clusters, como o Velero. Para obter mais informações, consulte Velero no site do GitHub.

Para as versões atuais e anteriores do Kubernetes, consulte o calendário de lançamentos do Kubernetes do Amazon EKS.

Atender aos requisitos de upgrade

Para atualizar seu cluster, você deve atender aos seguintes requisitos:

• É preciso ter 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 (AWS IAM) do seu 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 para a chave do AWS Key Management Service (AWS KMS).

Analisar as principais atualizações do Amazon EKS e do Kubernetes

Realize as seguintes ações:

• Analise todas as alterações documentadas para a versão atualizada e anote todas as etapas de atualização necessárias.
• Analise os requisitos ou procedimentos específicos dos clusters gerenciados pelo Amazon EKS.

Para obter mais informações sobre as principais atualizações das versões de plataforma dos clusters do Amazon EKS e das versões do Kubernetes, consulte a seguinte documentação:

• Compreender o ciclo de vida da versão do Kubernetes no Amazon EKS
• Veja as versões da plataforma Amazon EKS para cada versão do Kubernetes
• Atualizar um cluster existente para a nova versão do Kubernetes

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
• Kubernetes changelog no site do GitHub

Entender e verificar se há APIs descontinuadas

Quando o Kubernetes atualiza uma API, ele também remove a API anterior.

Para gerenciar APIs descontinuadas, execute as seguintes ações:

• Para entender como o Kubernetes descontinua as APIs em uma versão posterior do Kubernetes, consulte a política de descontinuação do Kubernetes no site do Kubernetes.
• Para verificar se há versões de API descontinuadas em seu cluster, use a ferramenta Kube No Trouble (kubent). Para mais informações, consulte kube-no-trouble no site do GitHub. Se você usa versões descontinuadas da API, atualize seus workloads antes de atualizar seu cluster do Kubernetes.
• Para converter arquivos de manifesto do Kubernetes entre diferentes versões da API, use o plug-in kubectl convert. Para obter mais informações, consulte Install kubectl convert plugin no site do Kubernetes.

Sobre o que esperar durante uma atualização do Kubernetes

Se você atualizar seu cluster, o Amazon EKS lançará novos nós de servidor de API com a versão atualizada do Kubernetes para substituir os nós existentes. O Amazon EKS também executa uma série de verificações internas. Se uma verificação falhar, o Amazon EKS reverterá a implantação da infraestrutura e seu cluster permanecerá na versão anterior do Kubernetes. A reversão não afeta as aplicações em execução e é possível recuperar os clusters.

Observação: durante o processo de atualização, é possível enfrentar pequenas interrupções no serviço.

Atualize o ambiente de gerenciamento e o plano de dados

Para atualizar um cluster, você deve atualizar o ambiente de gerenciamento e o plano de dados.

Para isso, escolha um dos seguintes métodos:

• Atualização de cluster no local
• Atualização azul/verde ou canário
• Atualização de grupos de nós gerenciados

Atualização de cluster no local

Importante: para atualizações no local, é possível atualizar somente para a próxima versão secundária mais recente do Kubernetes. Se houver várias versões entre a versão atual do cluster e a versão de destino, você deverá atualizar sequencialmente para cada versão.

Para cada atualização local do cluster do Kubernetes, conclua as seguintes etapas:

1. Atualize seus manifestos do Kubernetes e as APIs descontinuadas.
2. Atualize o ambiente de gerenciamento do cluster.
3. Atualize os nós em seu cluster.
4. Atualize seus complementos e controladores personalizados do Kubernetes.

Para mais informações, consulte a seção Planning and executing Kubernetes version upgrades in Amazon EKS (Planejamento e execução de atualizações de versão do Kubernetes no Amazon EKS) em Planning Kubernetes upgrades with Amazon EKS (Planejamento de upgrades do Kubernetes com o Amazon EKS). Além disso, consulte Best practices for cluster upgrades (Práticas recomendadas para atualizações de clusters).

Atualização azul/verde ou canário

Para uma atualização azul/verde ou canário, consulte Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads (Migração azul/verde ou canário de clusters do Amazon EKS para workloads ArgoCD sem estado).

Atualização de grupos de nós gerenciados

Importante: o kubelet de um nó não pode ser mais recente que o kube-apiserver. Além disso, o kubelet não pode ser mais do que duas versões secundárias anteriores ao kube-apiserver. Por exemplo, se o kube-apiserver estiver na versão 1.24, o Amazon EKS oferecerá suporte a um kubelet somente nas versões 1.24, 1.23 e 1.22.

Para atualizar um grupo de nós gerenciados, atualize seus nós no grupo de nós gerenciados.

Migrar para grupos de nós gerenciados pelo Amazon EKS

Se você usa grupos de nós autogerenciados, pode migrar seu workload para grupos de nós gerenciados pelo Amazon EKS sem tempo de inatividade.

Identificar e atualizar as dependências downstream

Os clusters podem conter complementos e ferramentas de terceiros, como controladores de entrada, sistemas de entrega contínua, ferramentas de monitoramento e outros fluxos de trabalho. Se você atualizar seu cluster, também deverá 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:

• Determine o complemento Container Network Interface da Amazon Virtual Private Cloud (CNIO da Amazon VPC) a ser usado em cada versão do cluster. Para mais informações, consulte Atribuir endereços IPs a pods com a CNI da Amazon VPC. Além disso, consulte Configurar o plug-in CNI da Amazon VPC para usar perfis do IAM para contas de serviço (IRSA).
• Para um complemento autogerenciado kube-proxy, atualize para a versão mais recente de imagem do contêiner kube-proxy disponível para cada versão do cluster. Para mais informações, consulte Gerenciar o kube-proxy em clusters do Amazon EKS.
• Para o CoreDNS, atualize para a versão mais recente de imagem de contêiner do CoreDNS disponível para cada versão do cluster. Para mais informações, consulte Gerenciar o CoreDNS para DNS em clusters do Amazon EKS.
• A versão 2.5.0 ou posterior do AWS Load Balancer Controller exige a versão 1.22 ou posterior do Kubernetes. Para mais informações, consulte AWS Load Balancer Controller releases (Versões do AWS Load Balancer Controller) no site do GitHub. Para informações sobre a instalação, consulte Direcionar o tráfego da Internet com o AWS Load Balancer Controller.
• O driver CSI do Amazon Elastic Block Store (Amazon EBS) versão 1.25.0 ou posterior requer a versão 1.23 ou posterior do Kubernetes. Para mais informações, consulte aws-ebs-csi-driver no site do GitHub. Para informações sobre instalação e atualização, consulte a Etapa 2: obter o driver CSI do Amazon EBS.
• O driver CSI do Amazon Elastic File System (Amazon EFS) versão 1.5.8 ou posterior exige a versão 1.22 ou posterior do Kubernetes. Para mais informações, consulte aws-efs-csi-driver no site do GitHub. Para informações sobre instalação e atualização, consulte Usar armazenamento elástico do sistema de arquivos com o Amazon EFS.

Atualizar os nós do Fargate

Para atualizar um nó do AWS Fargate, conclua as seguintes etapas:

1. Exclua o pod que seu nó representa.
2. Atualize seu ambiente de gerenciamento.
3. Reimplante o pod.

Os novos pods que você iniciar no Fargate agora têm uma versão kubelet que corresponde à sua versão do cluster. Sua atualização não afeta os pods existentes do Fargate.

Observação: o Amazon EKS deve corrigir periodicamente os pods do Fargate para manter os pods seguros. Quando está atualizando os pods, o Amazon EKS minimiza os efeitos da correção. Se o Amazon EKS não conseguir remover os pods, o Amazon EKS excluirá os pods. Para minimizar as interrupções, consulte Definir ações para AWS eventos de aplicação de patches do Fargate OS.

Atualizar os nós não gerenciados criados pelo Karpenter

O valor definido para ttlSecondsUntilExpired ativa a expiração do nó. Depois que os nós atingem a idade especificada em segundos, o Amazon EKS exclui os nós. A exclusão ocorre mesmo quando os workloads ou aplicações do Amazon EKS usam os nós. Use ttlSecondsUntilExpired para substituir os nós por instâncias recém-provisionadas para que você possa atualizar as instâncias. O Karpenter usa as mais recentes imagens de máquina da Amazon (AMIs) otimizadas para Amazon EKS para os nós substituídos. Para mais informações sobre como o Karpenter interrompe os nós, 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: o Karpenter não adiciona automaticamente instabilidade ao valor ttlSecondsUntilExpired. 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 no workload, defina um orçamento 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.