Come posso pianificare un aggiornamento del mio cluster Amazon EKS?

Risoluzione

Comprendi l'effetto di un aggiornamento

Le nuove versioni di Kubernetes possono apportare modifiche significative a un cluster Amazon EKS. Dopo aver aggiornato il cluster, non è possibile effettuare il downgrade.

Se esegui l'aggiornamento a una versione successiva di Kubernetes, non è necessario eseguire un aggiornamento locale (in-place) del cluster. Puoi invece eseguire la migrazione a un nuovo cluster. Se esegui la migrazione a un nuovo cluster, è consigliabile utilizzare strumenti di backup e ripristino del cluster, come Velero. Per ulteriori informazioni, consulta Velero sul sito web GitHub.

Per le versioni attuali e precedenti di Kubernetes, consulta Calendario di rilascio di Amazon EKS Kubernetes.

Soddisfa i requisiti di aggiornamento

Per aggiornare il cluster, devi soddisfare i seguenti requisiti:

• Devi avere fino a cinque indirizzi IP disponibili nelle sottoreti specificate quando crei il cluster.
• Il ruolo AWS Identity and Access Management (AWS IAM) e il gruppo di sicurezza del cluster devono essere nell'account AWS.
• Se attivi la crittografia dei segreti, il ruolo IAM del cluster deve avere le autorizzazioni per la chiave del Servizio AWS di gestione delle chiavi (AWS KMS).

Verifica gli aggiornamenti principali per Amazon EKS e Kubernetes

Esegui queste azioni:

• Esamina tutte le modifiche documentate per la versione di aggiornamento, quindi annota i passaggi di aggiornamento richiesti.
• Esamina i requisiti o le procedure specifici dei cluster gestiti di Amazon EKS.

Per informazioni sui principali aggiornamenti alle versioni della piattaforma dei cluster Amazon EKS e delle versioni Kubernetes, consulta la seguente documentazione:

• Comprendi il ciclo di vita delle versioni Kubernetes su Amazon EKS
• Visualizza le versioni della piattaforma Amazon EKS per ogni versione di Kubernetes
• Aggiorna il cluster esistente alla nuova versione di Kubernetes

Per informazioni sulle versioni upstream di Kubernetes e sugli aggiornamenti principali, consulta la seguente documentazione:

• Kubernetes release notes (Note di rilascio di Kubernetes) sul sito web Kubernetes
• Kubernetes changelog (Changelog di Kubernetes) sul sito web GitHub

Comprendi e verifica le API obsolete

Quando aggiorna un'API, Kubernetes rimuove anche l'API precedente.

Per gestire le API obsolete, intraprendi le seguenti azioni:

• Per capire come Kubernetes rende obsolete le API in una versione successiva di Kubernetes, consulta Kubernetes deprecation policy (Policy di obsolescenza di Kubernetes) sul sito web Kubernetes.
• Per verificare la presenza di versioni di API obsolete nel cluster, utilizza lo strumento Kube No Trouble (kubent). Per ulteriori informazioni, consulta kube-no-trouble sul sito web GitHub. Se utilizzi versioni di API obsolete, effettua l’aggiornamento dei carichi di lavoro prima di aggiornare il cluster Kubernetes.
• Per convertire i file manifesto di Kubernetes tra diverse versioni di API, utilizza il plugin kubectl convert. Per ulteriori informazioni, consulta Install kubectl convert plugin (Installa il plugin kubectl convert) sul sito web Kubernetes.

Comprendi cosa aspettarti durante un aggiornamento di Kubernetes

Se aggiorni il cluster, Amazon EKS avvia nuovi nodi del server API con la versione aggiornata di Kubernetes per sostituire i nodi esistenti. Amazon EKS esegue anche una serie di controlli interni. Se un controllo ha esito negativo, Amazon EKS ripristina la distribuzione dell'infrastruttura e il cluster rimane alla versione precedente di Kubernetes. Il rollback non influisce sulle applicazioni in esecuzione ed è possibile ripristinare i cluster.

Nota: durante il processo di aggiornamento, potrebbero verificarsi brevi interruzioni del servizio.

Aggiorna il piano di controllo (control-plane) e il piano dati

Per aggiornare un cluster, devi aggiornare il piano di controllo (control-plane) e il piano dati.

Per aggiornare i piani, scegli uno dei seguenti metodi:

• Aggiornamento locale (in-place) del cluster
• Aggiornamento blu/verde o canary
• Aggiornamento del gruppo di nodi gestiti

Aggiornamento locale (in-place) del cluster

Importante: per gli aggiornamenti locali (in-place), puoi eseguire l'aggiornamento solo alla versione secondaria successiva più recente di Kubernetes. Se sono presenti più versioni tra la versione corrente del cluster e la versione di destinazione, è necessario eseguire l'aggiornamento sequenziale a ciascuna versione.

Per ogni aggiornamento locale (in-place) del cluster Kubernetes, completa i seguenti passaggi:

1. Aggiorna i manifesti Kubernetes e le API obsolete.
2. Aggiorna il piano di controllo (control-plane) del cluster.
3. Aggiorna i nodi del cluster.
4. Aggiorna i componenti aggiuntivi e i controller personalizzati di Kubernetes.

Per ulteriori informazioni, consulta Planning and executing Kubernetes version upgrades in Amazon EKS (Pianificazione ed esecuzione degli aggiornamento delle versioni di Kubernetes in Amazon EKS) in Planning Kubernetes Upgrades with Amazon EKS (Pianificazione degli aggiornamenti di Kubernetes con Amazon EKS). Inoltre, consulta Procedure consigliate per gli aggiornamenti dei cluster.

Aggiornamento blu/verde o canary

Per un aggiornamento e blu/verde o canary, consulta Blue/Green or Canary Amazon EKS clusters migration for stateless ArgoCD workloads (Migrazione dei cluster Amazon EKS blu/verde o canary per carichi di lavoro ArgoCD stateless).

Aggiornamento del gruppo di nodi gestiti

Importante: il kubelet di un nodo non può essere successivo a kube-apiserver. Inoltre, il kubelet non può essere di più di due versioni secondarie precedenti a kube-apiserver. Ad esempio, se kube-apiserver è alla versione 1.24, Amazon EKS supporta un kubelet solo nelle versioni 1.24, 1.23 e 1.22.

Per aggiornare un gruppo di nodi gestiti, aggiorna i nodi nel gruppo di nodi gestiti.

Esegui la migrazione a un gruppo di nodi gestiti da Amazon EKS

Se utilizzi gruppi di nodi self-managed, puoi eseguire la migrazione del carico di lavoro verso gruppi di nodi gestiti da Amazon EKS senza tempi di inattività.

Identifica e aggiorna le dipendenze a valle

I cluster possono contenere componenti aggiuntivi e strumenti di terze parti, come controller di ingresso, sistemi di distribuzione continua, strumenti di monitoraggio e altri flussi di lavoro. Se aggiorni il cluster, devi aggiornare anche i componenti aggiuntivi e gli strumenti di terze parti. Assicurati di aver compreso come funzionano i componenti aggiuntivi con il cluster e come vengono aggiornati.

Nota: è consigliabile utilizzare componenti aggiuntivi gestiti anziché self-managed.

Consulta i seguenti esempi di componenti aggiuntivi comuni e la documentazione di aggiornamento:

• Determina il componente aggiuntivo Amazon Virtual Private Cloud Container Network Interface (Amazon VPC CNI) da utilizzare per ogni versione del cluster. Per ulteriori informazioni, consulta Assegna indirizzi IP ai pod con Amazon VPC CNI. Inoltre, consulta Configurare il plugin Amazon VPC CNI per utilizzare IRSA.
• Per un componente aggiuntivo kube-proxy self-managed, esegui l'aggiornamento all'ultima versione disponibile dell'immagine del container kube-proxy per ogni versione del cluster. Per ulteriori informazioni, consulta Gestione di kube-proxy nei cluster Amazon EKS.
• Per CoreDNS, aggiorna all'ultima versione disponibile dell'immagine del container CoreDNS per ogni versione del cluster. Per ulteriori informazioni, consulta Gestisci CoredNS per DNS nei cluster Amazon EKS.
• AWS Load Balancer Controller 2.5.0 o versioni successive richiede Kubernetes 1.22 o versioni successive. Per ulteriori informazioni, consulta AWS Load Balancer Controller releases (Versioni di AWS Load Balancer Controller) sul sito web GitHub. Per informazioni sull'installazione, consulta Indirizza il traffico Internet con AWS Load Balancer Controller.
• La versione 1.25.0 o successiva del driver CSI Amazon Elastic Block Store (Amazon EBS) richiede la versione 1.23 o successiva di Kubernetes. Per ulteriori informazioni, consulta aws-ebs-csi-driver sul sito web GitHub. Per informazioni sull'installazione e l'aggiornamento, consulta Fase 2: scarica il driver CSI di Amazon EBS.
• La versione 1.5.8 o successiva del driver CSI Amazon Elastic File System (Amazon EFS) richiede Kubernetes 1.22 o successiva. Per ulteriori informazioni, consulta aws-efs-csi-driver sul sito web GitHub. Per informazioni sull'installazione e l'aggiornamento, consulta Usa lo storage elastico del file system con Amazon EFS.

Aggiorna i nodi Fargate

Per aggiornare un nodo AWS Fargate, completa i seguenti passaggi:

1. Elimina il pod rappresentato dal nodo.
2. Aggiorna il piano di controllo (control-plane).
3. Ridistribuisci il pod.

I nuovi pod avviati su Fargate ora hanno una versione del kubelet che corrisponde alla versione del cluster. L'aggiornamento non influisce sui pod Fargate esistenti.

Nota: Amazon EKS deve applicare periodicamente patch ai pod Fargate per mantenerli protetti. Quando aggiorna i pod, Amazon EKS riduce al minimo gli effetti della patch. Se Amazon EKS non è in grado di rimuovere i pod, Amazon EKS li elimina. Per ridurre al minimo le interruzioni, consulta Imposta azioni per gli eventi di patching del sistema operativo di AWS Fargate.

Aggiorna i nodi non gestiti creati da Karpenter

Il valore impostato per ttlSecondsUntilExpired attiva la scadenza del nodo. Dopo che i nodi hanno raggiunto l'età specificata in secondi, Amazon EKS li elimina. L'eliminazione avviene anche quando i carichi di lavoro o le applicazioni Amazon EKS utilizzano i nodi. Utilizza ttlSecondsUntilExpired per sostituire i nodi con le nuove istanze assegnate in modo da poterle aggiornare. Karpenter utilizza le ultime AMI (Amazon Machine Image) ottimizzate per Amazon EKS per i nodi sostituiti. Per ulteriori informazioni sul modo in cui Karpenter interrompe i nodi, consulta Disruption (Interruzione) sul sito web Karpenter.

L'esempio seguente mostra un nodo senza provisioning con ttlSecondsUntilExpired successivamente sostituito con un'istanza aggiornata:

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: '*'

Nota: Karpenter non aggiunge automaticamente il jitter al valore ttlSecondsUntilExpired. Se crei più istanze in un breve lasso di tempo, le istanze scadono contemporaneamente. Per evitare interruzioni eccessive del carico di lavoro, imposta un budget per le interruzioni del pod. Per ulteriori informazioni, consulta Specifying a disruption budget for your application (Come specificare un budget per le interruzioni di un'applicazione) sul sito web Kubernetes.