Ao usar o AWS re:Post, você concorda com os AWS re:Post Termos de uso
AWS re:Postre:Post

Como faço para planejar uma estratégia de atualização para um cluster do Amazon EKS?

9 minuto de leitura
0

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:

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:

Para obter mais informações sobre as versões upstream e as principais atualizações do Kubernetes, consulte a documentação a seguir:

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:

  1. Atualize seus componentes do ambiente de gerenciamento de cluster do Amazon EKS para a versão mais recente.
  2. 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:

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.

Tópicos
Contêineres
Tags
Amazon Elastic Kubernetes Service
Idioma
Português
AWS OFICIAL
AWS OFICIALAtualizada há 3 meses

Conteúdo relevante