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 upgrades de cluster

Este guia mostra aos administradores de cluster como planejar e executar sua estratégia de upgrade do Amazon EKS. Ele também descreve como atualizar nós autogerenciados, grupos de nós gerenciados, nós Karpenter e nós Fargate. Ele não inclui orientação sobre EKS Anywhere, Kubernetes autogerenciados, AWS Outposts ou AWS Local Zones.

Visão geral do

Uma versão do Kubernetes engloba o plano de controle e o plano de dados. Para garantir uma operação suave, tanto o plano de controle quanto o plano de dados devem executar a mesma versão secundária do Kubernetes, como 1.24. Embora a AWS gerencie e atualize o plano de controle, atualizar os nós de trabalho no plano de dados é de sua responsabilidade.

Antes da atualização

Se você planeja atualizar sua versão do Kubernetes no Amazon EKS, há algumas políticas, ferramentas e procedimentos importantes que você deve implementar antes de iniciar uma atualização.

Mantenha seu cluster atualizado

Manter-se atualizado com as atualizações do Kubernetes é fundamental para um ambiente EKS seguro e eficiente, refletindo o modelo de responsabilidade compartilhada no Amazon EKS. Ao integrar essas estratégias em seu fluxo de trabalho operacional, você está se posicionando para manter clusters atualizados e seguros que aproveitam ao máximo os recursos e melhorias mais recentes. Táticas:

Revise o calendário de lançamentos do EKS

Consulte o calendário de lançamentos do EKS Kubernetes para saber quando novas versões estão chegando e quando o suporte para versões específicas termina. Geralmente, o EKS lança três versões secundárias do Kubernetes anualmente, e cada versão secundária tem suporte por cerca de 14 meses.

Além disso, revise as informações de lançamento upstream do Kubernetes.

Entenda como o modelo de responsabilidade compartilhada se aplica às atualizações de cluster

Você é responsável por iniciar a atualização tanto do plano de controle do cluster quanto do plano de dados. Saiba como iniciar um upgrade. Quando você inicia uma atualização de cluster, a AWS gerencia a atualização do plano de controle do cluster. Você é responsável por atualizar o plano de dados, incluindo os pods e complementos do Fargate. Atualize complementos e componentes usando a API Kubernetes Você deve validar e planejar atualizações para cargas de trabalho em execução em seu cluster para garantir que sua disponibilidade e operações não sejam afetadas após a atualização do cluster

Atualize clusters no local

O EKS oferece suporte a uma estratégia de atualização de cluster no local. Isso mantém os recursos do cluster e mantém a configuração do cluster consistente (por exemplo, endpoint da API, OIDC, ENIs, balanceadores de carga). Isso causa menos interrupções para os usuários do cluster e usará as cargas de trabalho e os recursos existentes no cluster sem exigir que você reimplante cargas de trabalho ou migre recursos externos (por exemplo, DNS, armazenamento).

Ao realizar uma atualização de cluster no local, é importante observar que somente uma pequena atualização de versão pode ser executada por vez (por exemplo, de 1,24 para 1,25).

Isso significa que, se você precisar atualizar várias versões, será necessária uma série de atualizações sequenciais. Planejar atualizações sequenciais é mais complicado e tem um risco maior de tempo de inatividade. Nessa situação, vejaAvalie Blue/Green os clusters como uma alternativa aos upgrades de clusters no local.

Atualize seu plano de controle e plano de dados em sequência

Para atualizar um cluster, você precisará realizar as seguintes ações:

Use a documentação do EKS para criar uma lista de verificação de atualização

A documentação da versão do EKS Kubernetes inclui uma lista detalhada de alterações para cada versão. Crie uma lista de verificação para cada atualização.

Para obter orientações específicas de atualização de versão do EKS, consulte a documentação para ver as mudanças e considerações notáveis de cada versão.

Atualize complementos e componentes usando a API Kubernetes

Antes de atualizar um cluster, você deve entender quais versões dos componentes do Kubernetes você está usando. Faça o inventário dos componentes do cluster e identifique os componentes que usam diretamente a API Kubernetes. Isso inclui componentes críticos do cluster, como agentes de monitoramento e registro, escaladores automáticos de cluster, drivers de armazenamento de contêineres (por exemplo, EBS CSI, EFS CSI), controladores de entrada e quaisquer outras cargas de trabalho ou complementos que dependam diretamente da API Kubernetes.

kubectl get ns | grep '-system'

Depois de identificar os componentes que dependem da API Kubernetes, verifique a documentação deles para verificar a compatibilidade de versões e os requisitos de atualização. Por exemplo, consulte a documentação do AWS Load Balancer Controller para ver a compatibilidade de versões. Alguns componentes podem precisar ser atualizados ou a configuração alterada antes de prosseguir com a atualização do cluster. Alguns componentes essenciais a serem verificados incluem CoreDNS, kube-proxy, VPC CNI e drivers de armazenamento.

Os clusters geralmente contêm muitas cargas de trabalho que usam a API Kubernetes e são necessários para a funcionalidade da carga de trabalho, como controladores de entrada, sistemas de entrega contínua e ferramentas de monitoramento. Ao atualizar um cluster EKS, você também deve atualizar seus complementos e ferramentas de terceiros para garantir que sejam compatíveis.

Veja os seguintes exemplos de complementos comuns e sua documentação de atualização relevante:

Verifique os requisitos básicos do EKS antes de atualizar

A AWS exige certos recursos em sua conta para concluir o processo de upgrade. Se esses recursos não estiverem presentes, o cluster não poderá ser atualizado. Uma atualização do plano de controle requer os seguintes recursos:

Verifique os endereços IP disponíveis

Para atualizar o cluster, o Amazon EKS requer até cinco endereços IP disponíveis das sub-redes que você especificou ao criar o cluster.

Para verificar se suas sub-redes têm endereços IP suficientes para atualizar o cluster, você pode executar o seguinte comando:

CLUSTER=<cluster name>
aws ec2 describe-subnets --subnet-ids \
  $(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.resourcesVpcConfig.subnetIds' \
  --output text) \
  --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' \
  --output table

----------------------------------------------------
|                  DescribeSubnets                 |
+---------------------------+--------------+-------+
|  subnet-067fa8ee8476abbd6 |  us-east-1a  |  8184 |
|  subnet-0056f7403b17d2b43 |  us-east-1b  |  8153 |
|  subnet-09586f8fb3addbc8c |  us-east-1a  |  8120 |
|  subnet-047f3d276a22c6bce |  us-east-1b  |  8184 |
+---------------------------+--------------+-------+

O VPC CNI Metrics Helper pode ser usado para criar um CloudWatch painel para métricas de VPC. O Amazon EKS recomenda atualizar as sub-redes do cluster usando a API "UpdateClusterConfiguration" antes de iniciar a atualização da versão do Kubernetes se você estiver ficando sem endereços IP nas sub-redes inicialmente especificadas durante a criação do cluster. Verifique se as novas sub-redes serão fornecidas a você:

Considere associar blocos CIDR adicionais se os endereços IP no bloco CIDR da VPC existente se esgotarem. A AWS permite a associação de blocos CIDR adicionais à sua VPC de cluster existente, expandindo efetivamente seu pool de endereços IP. Essa expansão pode ser realizada introduzindo faixas IP privadas adicionais (RFC 1918) ou, se necessário, faixas IP públicas (não RFC 1918). Você deve adicionar novos blocos CIDR da VPC e permitir que a atualização da VPC seja concluída antes que o Amazon EKS possa usar o novo CIDR. Depois disso, você pode atualizar as sub-redes com base nos blocos CIDR recém-configurados para a VPC.

Verificar a função do EKS IAM

Para verificar se a função do IAM está disponível e tem a política correta de assumir função em sua conta, você pode executar os seguintes comandos:

CLUSTER=<cluster name>
ROLE_ARN=$(aws eks describe-cluster --name ${CLUSTER} \
  --query 'cluster.roleArn' --output text)
aws iam get-role --role-name ${ROLE_ARN##*/} \
  --query 'Role.AssumeRolePolicyDocument'

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Migrar para o EKS Add-ons

O Amazon EKS instala automaticamente complementos, como o plug-in CNI do Amazon VPC para Kubernetes e o CoreDNS para cada cluster. kube-proxy Add-ons pode ser autogerenciado ou instalado como Amazon EKS Add-ons. O Amazon EKS Add-ons é uma forma alternativa de gerenciar complementos usando a API do EKS.

Você pode usar o Amazon EKS Add-ons para atualizar versões com um único comando. Por exemplo:

aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \
--service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE

Verifique se você tem algum EKS Add-ons com:

aws eks list-addons --cluster-name <cluster name>

Saiba mais sobre quais componentes estão disponíveis como EKS Add-ons e como começar.

Saiba como fornecer uma configuração personalizada para um EKS Add-on.

Identifique e corrija o uso removido da API antes de atualizar o plano de controle

Você deve identificar o uso da API das APIs removidas antes de atualizar seu plano de controle EKS. Para fazer isso, recomendamos o uso de ferramentas que possam verificar um cluster em execução ou arquivos de manifesto do Kubernetes renderizados estáticos.

A execução da verificação em arquivos de manifesto estáticos geralmente é mais precisa. Se executadas em clusters ativos, essas ferramentas podem retornar falsos positivos.

Uma API Kubernetes obsoleta não significa que a API foi removida. Você deve verificar a Política de descontinuação do Kubernetes para entender como a remoção da API afeta suas cargas de trabalho.

Informações sobre clusters

O Cluster Insights é um recurso que fornece descobertas sobre problemas que podem afetar a capacidade de atualizar um cluster EKS para versões mais recentes do Kubernetes. Essas descobertas são selecionadas e gerenciadas pelo Amazon EKS e oferecem recomendações sobre como corrigi-las. Ao aproveitar o Cluster Insights, você pode minimizar o esforço gasto na atualização para versões mais recentes do Kubernetes.

Para ver os insights de um cluster EKS, você pode executar o comando:

aws eks list-insights --region <region-code> --cluster-name <my-cluster>

{
    "insights": [
        {
            "category": "UPGRADE_READINESS",
            "name": "Deprecated APIs removed in Kubernetes v1.29",
            "insightStatus": {
                "status": "PASSING",
                "reason": "No deprecated API usage detected within the last 30 days."
            },
            "kubernetesVersion": "1.29",
            "lastTransitionTime": 1698774710.0,
            "lastRefreshTime": 1700157422.0,
            "id": "123e4567-e89b-42d3-a456-579642341238",
            "description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes v1.29. Upgrading your cluster before migrating to the updated APIs supported by v1.29 could cause application impact."
        }
    ]
}

Para obter uma saída mais descritiva sobre o insight recebido, você pode executar o comando:

aws eks describe-insight --region <region-code> --id <insight-id> --cluster-name <my-cluster>

Você também tem a opção de visualizar insights no console do Amazon EKS. Depois de selecionar seu cluster na lista de clusters, as descobertas do insight estão localizadas abaixo da Upgrade Insights guia.

Se você encontrar um insight de cluster com"status": ERROR, deverá resolver o problema antes de realizar a atualização do cluster. Execute o aws eks describe-insight comando que compartilhará o seguinte conselho de remediação:

Recursos afetados:

"resources": [
      {
        "insightStatus": {
          "status": "ERROR"
        },
        "kubernetesResourceUri": "/apis/policy/v1beta1/podsecuritypolicies/null"
      }
]

APIs obsoletas:

"deprecationDetails": [
      {
        "usage": "/apis/flowcontrol.apiserver.k8s.io/v1beta2/flowschemas",
        "replacedWith": "/apis/flowcontrol.apiserver.k8s.io/v1beta3/flowschemas",
        "stopServingVersion": "1.29",
        "clientStats": [],
        "startServingReplacementVersion": "1.26"
      }
]

Ação recomendada a ser tomada:

"recommendation": "Update manifests and API clients to use newer Kubernetes APIs if applicable before upgrading to Kubernetes v1.26."

A utilização de insights de cluster por meio do console EKS ou da CLI ajuda a acelerar o processo de atualização bem-sucedida das versões do cluster EKS. Saiba mais com os seguintes recursos: * Documentos oficiais do EKS * Blog de lançamento do Cluster Insights.

Kube-no-trouble

Kube-no-troubleé um utilitário de linha de comando de código aberto com o comandokubent. Quando você executa kubent sem nenhum argumento, ele usa seu KubeConfig contexto atual, escaneia o cluster e imprime um relatório com quais APIs serão descontinuadas e removidas.

kubent

4:17PM INF >>> Kube No Trouble `kubent` <<<
4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042)
4:17PM INF Initializing collectors and retrieving data
4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d
4:l INF Retrieved 93 resources from collector name=Cluster
4:17PM INF Retrieved 16 resources from collector name="Helm v3"
4:17PM INF Loaded ruleset name=custom.rego.tmpl
4:17PM INF Loaded ruleset name=deprecated-1-16.rego
4:17PM INF Loaded ruleset name=deprecated-1-22.rego
4:17PM INF Loaded ruleset name=deprecated-1-25.rego
4:17PM INF Loaded ruleset name=deprecated-1-26.rego
4:17PM INF Loaded ruleset name=deprecated-future.rego
__________________________________________________________________________________________
>>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND                NAMESPACE     NAME             API_VERSION      REPLACE_WITH (SINCE)
PodSecurityPolicy   <undefined>   eks.privileged   policy/v1beta1   <removed> (1.21.0)

Ele também pode ser usado para escanear arquivos de manifesto estáticos e pacotes helm. É recomendável executar kubent como parte de um processo de integração contínua (CI) para identificar problemas antes que os manifestos sejam implantados. A varredura de manifestos também é mais precisa do que a varredura de clusters ativos.

Kube-no-trouble fornece um exemplo de conta de serviço e função com as permissões apropriadas para escanear o cluster.

Plutão

Outra opção é o pluto, que é semelhante kubent porque suporta a digitalização de um cluster ativo, arquivos de manifesto, gráficos de leme e tem uma GitHub ação que você pode incluir em seu processo de CI.

pluto detect-all-in-cluster

NAME             KIND                VERSION          REPLACEMENT   REMOVED   DEPRECATED   REPL AVAIL
eks.privileged   PodSecurityPolicy   policy/v1beta1                 false     true         true

Recursos

Para verificar se seu cluster não usa APIs obsoletas antes da atualização, você deve monitorar:

kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

apiserver_requested_deprecated_apis{group="policy",removed_release="1.25",resource="podsecuritypolicies",subresource="",version="v1beta1"} 1

CLUSTER="<cluster_name>"
QUERY_ID=$(aws logs start-query \
 --log-group-name /aws/eks/${CLUSTER}/cluster \
 --start-time $(date -u --date="-30 minutes" "+%s") # or date -v-30M "+%s" on MacOS \
 --end-time $(date "+%s") \
 --query-string 'fields @message | filter `annotations.k8s.io/deprecated`="true"' \
 --query queryId --output text)

echo "Query started (query id: $QUERY_ID), please hold ..." && sleep 5 # give it some time to query

aws logs get-query-results --query-id $QUERY_ID

Que produzirão linhas se APIs obsoletas estiverem em uso:

{
    "results": [
        [
            {
                "field": "@message",
                "value": "{\"kind\":\"Event\",\"apiVersion\":\"audit.k8s.io/v1\",\"level\":\"Request\",\"auditID\":\"8f7883c6-b3d5-42d7-967a-1121c6f22f01\",\"stage\":\"ResponseComplete\",\"requestURI\":\"/apis/policy/v1beta1/podsecuritypolicies?allowWatchBookmarks=true\\u0026resourceVersion=4131\\u0026timeout=9m19s\\u0026timeoutSeconds=559\\u0026watch=true\",\"verb\":\"watch\",\"user\":{\"username\":\"system:apiserver\",\"uid\":\"8aabfade-da52-47da-83b4-46b16cab30fa\",\"groups\":[\"system:masters\"]},\"sourceIPs\":[\"::1\"],\"userAgent\":\"kube-apiserver/v1.24.16 (linux/amd64) kubernetes/af930c1\",\"objectRef\":{\"resource\":\"podsecuritypolicies\",\"apiGroup\":\"policy\",\"apiVersion\":\"v1beta1\"},\"responseStatus\":{\"metadata\":{},\"code\":200},\"requestReceivedTimestamp\":\"2023-10-04T12:36:11.849075Z\",\"stageTimestamp\":\"2023-10-04T12:45:30.850483Z\",\"annotations\":{\"authorization.k8s.io/decision\":\"allow\",\"authorization.k8s.io/reason\":\"\",\"k8s.io/deprecated\":\"true\",\"k8s.io/removed-release\":\"1.25\"}}"
            },
[...]

Atualize as cargas de trabalho do Kubernetes. Use kubectl-convert para atualizar manifestos

Depois de identificar quais cargas de trabalho e manifestos precisam ser atualizados, talvez seja necessário alterar o tipo de recurso em seus arquivos de manifesto (por exemplo, PodSecurityPolicies para PodSecurityStandards). Isso exigirá a atualização da especificação do recurso e pesquisas adicionais, dependendo do recurso que está sendo substituído.

Se o tipo de recurso continuar o mesmo, mas a versão da API precisar ser atualizada, você poderá usar o kubectl-convert comando para converter automaticamente seus arquivos de manifesto. Por exemplo, para converter uma implantação antiga emapps/v1. Para obter mais informações, consulte Instalar o plug-in kubectl convert no site do Kubernetes.

kubectl-convert -f <file> --output-version <group>/<version>

Configuração PodDisruptionBudgets e topologia SpreadConstraints para garantir a disponibilidade de suas cargas de trabalho enquanto o plano de dados é atualizado

Garanta que suas cargas de trabalho tenham a topologia adequada PodDisruptionBudgets SpreadConstraints para garantir a disponibilidade de suas cargas de trabalho enquanto o plano de dados é atualizado. Nem toda carga de trabalho exige o mesmo nível de disponibilidade, então você precisa validar a escala e os requisitos da sua carga de trabalho.

Garantir que as cargas de trabalho estejam distribuídas em várias zonas de disponibilidade e em vários hosts com spreads de topologia proporcionará um maior nível de confiança de que as cargas de trabalho migrarão automaticamente para o novo plano de dados, sem incidentes.

Aqui está um exemplo de carga de trabalho que sempre terá 80% das réplicas disponíveis e distribuirá réplicas entre zonas e hosts

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp
spec:
  minAvailable: "80%"
  selector:
    matchLabels:
      app: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: myapp
        resources:
          requests:
            cpu: "1"
            memory: 256M
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule

O AWS Resilience Hub adicionou o Amazon Elastic Kubernetes Service (Amazon EKS) como um recurso compatível. O Resilience Hub fornece um único local para definir, validar e rastrear a resiliência de seus aplicativos para que você possa evitar o tempo de inatividade desnecessário causado por interrupções operacionais, de software ou de infraestrutura.

Use Managed Node Groups ou Karpenter para simplificar as atualizações do plano de dados

Tanto o Managed Node Groups quanto o Karpenter simplificam as atualizações de nós, mas adotam abordagens diferentes.

Os grupos de nós gerenciados automatizam o provisionamento e o gerenciamento do ciclo de vida dos nós. Isso significa que você pode criar, atualizar automaticamente ou encerrar nós com uma única operação.

Na configuração padrão, o Karpenter cria automaticamente novos nós usando a AMI otimizada EKS compatível mais recente. À medida que o EKS lança AMIs otimizadas do EKS atualizadas ou o cluster é atualizado, o Karpenter começará automaticamente a usar essas imagens. O Karpenter também implementa o Node Expiry para atualizar os nós.

O Karpenter pode ser configurado para usar AMIs personalizadas. Se você usa AMIs personalizadas com o Karpenter, você é responsável pela versão do kubelet.

Confirme a compatibilidade da versão com os nós existentes e o plano de controle

Antes de prosseguir com a atualização do Kubernetes no Amazon EKS, é vital garantir a compatibilidade entre seus grupos de nós gerenciados, nós autogerenciados e o plano de controle. A compatibilidade é determinada pela versão do Kubernetes que você está usando e varia de acordo com os diferentes cenários. Táticas:

Habilitar a expiração do nó para os nós gerenciados pelo Karpenter

Uma maneira pela qual a Karpenter implementa atualizações de nós é usando o conceito de expiração de nós. Isso reduz o planejamento necessário para atualizações de nós. Quando você define um valor para ttl SecondsUntilExpired em seu provisionador, isso ativa a expiração do nó. Depois que os nós atingem a idade definida em segundos, eles são drenados e excluídos com segurança. Isso é verdade mesmo se eles estiverem em uso, permitindo que você substitua os nós por instâncias atualizadas recém-provisionadas. Quando um nó é substituído, o Karpenter usa as AMIs mais recentes EKS-optimized . Para obter mais informações, consulte Disruption no site da Karpenter.

O Karpenter não adiciona automaticamente instabilidade a esse valor. Para evitar interrupções excessivas na carga de trabalho, defina um orçamento de interrupção do pod, conforme mostrado na documentação do Kubernetes.

Se você configurar ttl SecondsUntilExpired em um provisionador, isso se aplica aos nós existentes associados ao provisionador.

Use o recurso Drift para nós gerenciados pelo Karpenter

O recurso Drift do Karpenter pode atualizar automaticamente os Karpenter-provisioned nós para permanecerem sincronizados com o plano de controle EKS. Atualmente, o Karpenter Drift precisa ser ativado usando um portão de recursos. A configuração padrão do Karpenter usa a EKS-Optimized AMI mais recente para a mesma versão principal e secundária do plano de controle do cluster EKS.

Após a conclusão de uma atualização do EKS Cluster, o recurso Drift do Karpenter detectará que os Karpenter-provisioned nós estão usando EKS-Optimized AMIs para a versão anterior do cluster e automaticamente isolará, drenará e substituirá esses nós. Para oferecer suporte à migração de pods para novos nós, siga as melhores práticas do Kubernetes definindo cotas apropriadas de recursos de pod e usando orçamentos de interrupção de pod (PDB). O desprovisionamento da Karpenter ativará previamente os nós de substituição com base nas solicitações de recursos do pod e respeitará os PDBs ao desprovisionar os nós.

Use eksctl para automatizar atualizações para grupos de nós autogerenciados

Grupos de nós autogerenciados são instâncias do EC2 que foram implantadas em sua conta e anexadas ao cluster fora do serviço EKS. Geralmente, eles são implantados e gerenciados por alguma forma de ferramenta de automação. Para atualizar grupos de nós autogerenciados, consulte a documentação de suas ferramentas.

Por exemplo, o eksctl suporta a exclusão e a drenagem de nós autogerenciados.

Algumas ferramentas comuns incluem:

Faça backup do cluster antes da atualização

Novas versões do Kubernetes introduzem mudanças significativas em seu cluster Amazon EKS. Você pode reverter uma atualização em 7 dias, mas recomendamos que você faça backup do cluster antes da atualização.

Você pode fazer backup do seu cluster com o AWS Backup, um serviço totalmente gerenciado. Você também pode usar o Velero, uma ferramenta de código aberto suportada pela comunidade.

Observe que você só pode criar novos clusters para as versões do Kubernetes atualmente suportadas pelo EKS. Se a versão que seu cluster está executando atualmente ainda for suportada e uma atualização falhar, você poderá criar um novo cluster com a versão original e restaurar o plano de dados. Observe que os recursos da AWS, incluindo o IAM, não estão incluídos no backup. Você precisa recriar esses recursos.

Reinicie as implantações do Fargate após atualizar o plano de controle

Para atualizar os nós do plano de dados do Fargate, você precisa reimplantar as cargas de trabalho. Você pode identificar quais cargas de trabalho estão sendo executadas nos nós fargate listando todos os pods com a opção. -o wide Qualquer nome de nó que comece com fargate- precisará ser reimplantado no cluster.

Avalie Blue/Green os clusters como uma alternativa aos upgrades de clusters no local

Alguns clientes preferem fazer uma estratégia de blue/green upgrade. Isso pode trazer benefícios, mas também inclui desvantagens que devem ser consideradas.

Os benefícios são:

Algumas desvantagens incluem:

Embora essa estratégia seja possível, ela é mais cara do que um upgrade no local e exige mais tempo para coordenação e migrações de carga de trabalho. Pode ser necessário em algumas situações e deve ser planejado com cuidado.

Com altos graus de automação e sistemas declarativos GitOps, isso pode ser mais fácil de fazer. Você precisará tomar precauções adicionais com cargas de trabalho com estado para que os dados sejam copiados e migrados para novos clusters.

Revise essas postagens do blog para obter mais informações:

Acompanhe as principais mudanças planejadas no projeto Kubernetes — Pense no futuro

Não olhe apenas para a próxima versão. Analise as novas versões do Kubernetes à medida que forem lançadas e identifique as principais mudanças. Por exemplo, alguns aplicativos usaram diretamente a API docker, e o suporte à Container Runtime Interface (CRI) para Docker (também conhecido como Dockershim) foi removido no Kubernetes. 1.24 Esse tipo de mudança exige mais tempo para se preparar.

Analise todas as alterações documentadas da versão para a qual você está atualizando e anote as etapas de atualização necessárias. Além disso, observe quaisquer requisitos ou procedimentos específicos dos clusters gerenciados pelo Amazon EKS.

Orientação específica sobre remoções de recursos

Remoção do Dockershim na versão 1.25 - Use o detector para Docker Socket (DDS)

A AMI otimizada do EKS para 1.25 não inclui mais suporte para Dockershim. Se você depende do Dockershim, por exemplo, está montando o soquete Docker, precisará remover essas dependências antes de atualizar seus nós de trabalho para 1,25.

Encontre instâncias em que você dependa do soquete Docker antes de fazer o upgrade para 1.25. Recomendamos usar o Detector for Docker Socket (DDS), um plug-in kubectl. .

Remoção da PodSecurityPolicy versão 1.25 - Migre para os padrões de segurança do pod ou para uma solução de política como código

PodSecurityPolicyfoi descontinuado no Kubernetes 1.21 e foi removido no Kubernetes 1.25. Se você estiver usando PodSecurityPolicy em seu cluster, deverá migrar para os Padrões de Segurança de Pod (PSS) integrados do Kubernetes Pod ou para uma solução de política como código antes de atualizar seu cluster para a versão 1.25 para evitar interrupções em suas cargas de trabalho.

A AWS publicou uma seção detalhada de perguntas frequentes na documentação do EKS.

Analise as melhores práticas dos Padrões de Segurança de Pod (PSS) e de Admissão de Segurança de Pod (PSA).

Leia a postagem do blog PodSecurityPolicy Deprecation no site do Kubernetes.

Descontinuação do driver de In-Tree armazenamento na versão 1.23 - Migre para drivers de interface de armazenamento em contêiner (CSI)

A Container Storage Interface (CSI) foi projetada para ajudar o Kubernetes a substituir seus mecanismos de driver de armazenamento existentes na árvore. O recurso de migração Container Storage Interface (CSI) do Amazon EBS é habilitado por padrão em clusters 1.23 e posteriores do Amazon EKS. Se você tiver pods em execução em uma versão 1.22 ou em um cluster anterior, deverá instalar o driver CSI do Amazon EBS antes de atualizar seu cluster para a versão anterior 1.23 para evitar a interrupção do serviço.

Analise as perguntas frequentes sobre a migração do Amazon EBS CSI.

Recursos adicionais

ClowdHaus Orientação de atualização do EKS

ClowdHaus O EKS Upgrade Guidance é uma CLI para ajudar na atualização de clusters do Amazon EKS. Ele pode analisar um cluster em busca de possíveis problemas a serem corrigidos antes da atualização.

GoNoGo

GoNoGoé uma ferramenta de estágio alfa para determinar a confiança de upgrade de seus complementos de cluster.