Usando AWS re:Post, accetti AWS re:Post Termini di utilizzo
AWS re:Postre:Post

Come posso pianificare una strategia di aggiornamento per un cluster Amazon EKS?

9 minuti di lettura
0

Quando effettuo l’aggiornamento del mio cluster Amazon Elastic Kubernetes Service (Amazon EKS), desidero seguire le best practice.

Breve descrizione

Le nuove versioni di Kubernetes possono introdurre modifiche significative al cluster Amazon EKS. Dopo l’aggiornamento del cluster, non puoi effettuare il suo downgrade. Quando esegui l’aggiornamento a una versione più recente di Kubernetes, puoi migrare a nuovi cluster anziché eseguire aggiornamenti dei cluster locali (in-place). Se scegli di migrare a nuovi cluster, possono esserti d’aiuto strumenti di backup e ripristino cluster quali Velero di VMware. Per ulteriori informazioni, consulta Velero sul sito Web di GitHub.

Per visualizzare le versioni attuali e precedenti di Kubernetes disponibili per Amazon EKS, consulta la sezione Amazon EKS Kubernetes release calendar.

Soluzione

Preparati per l’aggiornamento

Prima di iniziare l’aggiornamento del cluster, tieni presente i seguenti requisiti:

Verifica gli aggiornamenti principali per Amazon EKS e Kubernetes

Verifica tutte le modifiche documentate per la versione di aggiornamento e prendi nota di tutti i passaggi di aggiornamento necessari. Inoltre, prendi nota di eventuali requisiti o procedure specifici dei cluster gestiti di Amazon EKS.

Fai riferimento alle seguenti risorse per eventuali aggiornamenti principali alle versioni della piattaforma cluster Amazon EKS e alle versioni Kubernetes:

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

Understand the Kubernetes deprecation policy

Quando si effettua l’aggiornamento di un'API, l'API precedente viene dichiarata obsoleta e infine rimossa. Per capire come le API potrebbero essere rese obsolete in una versione più recente di Kubernetes, leggi la policy sull’obsolescenza disponibile sul sito Web di Kubernetes.

Per verificare se utilizzi versioni API obsolete nel tuo cluster, utilizza Kube No Trouble (kubent) sul sito Web di GitHub. Se utilizzi versioni API obsolete, effettua l’upgrade dei carichi di lavoro prima di aggiornare il cluster Kubernetes.

Per convertire i file manifesto di Kubernetes tra diverse versioni API, usa il plugin kubectl convert. Per ulteriori informazioni, consulta Install kubectl convert plugin sul sito Web di Kubernetes.

Cosa aspettarsi durante un aggiornamento di Kubernetes

Quando effettui l’aggiornamento del cluster, Amazon EKS lancia nuovi nodi del server API con la versione aggiornata di Kubernetes per sostituire quelli esistenti. Se uno di questi controlli ha esito negativo, Amazon EKS ripristina l’implementazione dell'infrastruttura e il cluster resta alla versione precedente di Kubernetes. Tuttavia, questo ripristino non influisce sulle applicazioni in esecuzione ed è possibile ripristinare qualsiasi cluster, in caso di necessità. 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 Amazon EKS, devi aggiornare due componenti principali: il piano di controllo (control-plane) e il piano dati. Quando aggiorni questi componenti, tieni presente le seguenti considerazioni.

Aggiornamento del cluster Amazon EKS locale

Per gli aggiornamenti locali, puoi eseguire l'aggiornamento solo alla versione minore successiva di Kubernetes. Se sono presenti più versioni tra la versione corrente del cluster e quella di destinazione, è necessario eseguire l'aggiornamento a ciascuna versione in sequenza. Per ogni aggiornamento del cluster Kubernetes locale, completa le seguenti attività:

  • Aggiorna i tuoi manifesti Kubernetes e aggiorna le API obsolete o rimosse, in base alle necessità.
  • Esegui l’aggiornamento del piano di controllo (control-plane) del cluster.
  • Aggiorna i nodi del cluster.
  • Aggiorna i componenti aggiuntivi e i controller personalizzati di Kubernetes, in base alle necessità.

Per ulteriori informazioni, consulta Pianificazione ed esecuzione degli aggiornamento delle versioni di Kubernetes in Amazon EKS in Pianificazione degli aggiornamenti di Kubernetes con Amazon EKS. Consulta inoltre la sezione Best practice per gli aggiornamenti dei cluster sul sito Web di GitHub.

Migrazione di cluster Amazon EKS blu/verdi o canary

Una strategia per aggiornamenti blu/verdi o canary può essere più complessa, ma consente di effettuare l’aggiornamento con funzionalità di ripristino semplificate e senza tempi di inattività. Per un aggiornamento e blu/verde o canary, consulta la sezione Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads.

Aggiornamento dei gruppi di nodi gestiti Amazon EKS

Importante: il kubelet di un nodo non può essere più recente di kube-apiserver. Inoltre, non possono esistere più di due versioni minor precedenti a kube-apiserver. Supponiamo, ad esempio, che kube-apiserver sia alla versione 1.24. In questo caso, sono supportati solo kubelet nelle versioni 1.24, 1.23 e 1.22.

Per l’aggiornamento completo di gruppi di nodi gestiti, completa i seguenti passaggi:

  1. Effettua l’aggiornamento dei componenti del piano di controllo (control-plane) del cluster Amazon EKS alla versione più recente.
  2. Aggiorna i nodi nel gruppo di nodi gestiti.

Esegui la migrazione ai gruppi di nodi gestiti di Amazon EKS

Se utilizzi gruppi di nodi autogestiti, puoi migrare il carico di lavoro su gruppi di nodi gestiti di Amazon EKS senza tempi di inattività. Per ulteriori informazioni, consulta la sezione Migrare senza problemi i carichi di lavoro dal gruppo di nodi autogestito EKS ai gruppi di nodi gestiti da EKS.

Identifica ed effettua l’aggiornamento delle dipendenze a valle (componenti aggiuntivi)

I cluster contengono spesso prodotti esterni, quali controller in ingresso, sistemi di distribuzione continua, strumenti di monitoraggio e altri flussi di lavoro. Quando aggiorni il cluster Amazon EKS, devi anche effettuare l’aggiornamento dei componenti aggiuntivi e degli strumenti di terze parti. Assicurati di comprendere come funzionano i componenti aggiuntivi con il cluster e come vengono aggiornati.

Nota: è consigliabile utilizzare componenti aggiuntivi gestiti anziché autogestiti.

Consulta i seguenti esempi dei componenti aggiuntivi più comuni e la relativa documentazione di aggiornamento:

Aggiornamento dei nodi AWS Fargate

Per aggiornare un nodo Fargate, elimina il pod rappresentato dal nodo. Quindi, dopo aver aggiornato il piano di controllo (control-plane), implementa di nuovo il pod. Tutti i nuovi pod lanciati su Fargate presentano una versione kubelet corrispondente alla versione del cluster. I pod Fargate esistenti non vengono modificati.

Nota: per proteggere i pod Fargate, Amazon EKS deve periodicamente applicare delle patch. Amazon EKS cerca di effettuare l’aggiornamento dei pod secondo modalità che ne riducono gli effetti. Tuttavia, se i pod non possono essere rimossi con successo, Amazon EKS li elimina. Per ridurre al minimo le interruzioni, consulta la sezione Fargate OS patching.

Effettua l’aggiornamento groupless dei nodi creati da Karpenter

Quando si imposta un valore per ttlSecondsUntilExpired, tale valore attiva la scadenza del nodo. Dopo che i nodi hanno raggiunto l'età definita in secondi, Amazon EKS li elimina. L’eliminazione avviene anche se i nodi sono in uso. Questo processo consente di sostituire i nodi con istanze recentemente allocate e quindi di aggiornarli. Quando viene sostituito un nodo, Karpenter utilizza le AMI più recenti ottimizzate per Amazon EKS. Per ulteriori informazioni, consulta la sezione Interruzione sul sito Web di Karpenter.

L'esempio seguente mostra un nodo senza provisioning con ttlSecondsUntilExpired e quindi 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 jitter a questo valore. Se crei più istanze in un breve lasso di tempo, tali istanze scadono quasi contemporaneamente. Per evitare interruzioni eccessive dei carichi di lavoro, definisci un budget per le interruzioni dei pod. Per ulteriori informazioni, consulta la sezione Specifying a disruption budget for your application sul sito Web di Kubernetes.

Argomenti
Container
Tag
Amazon Elastic Kubernetes Service
Lingua
Italiano
AWS UFFICIALE
AWS UFFICIALEAggiornata 2 mesi fa

Contenuto pertinente