Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Procedure consigliate per gli aggiornamenti dei cluster

Questa guida mostra agli amministratori di cluster come pianificare ed eseguire la loro strategia di aggiornamento di Amazon EKS. Descrive inoltre come aggiornare i nodi autogestiti, i gruppi di nodi gestiti, i nodi Karpenter e i nodi Fargate. Non include linee guida su EKS Anywhere, Kubernetes autogestito, AWS Outposts o AWS Local Zones.

Panoramica di

Una versione di Kubernetes comprende sia il piano di controllo che il piano dati. Per garantire un funzionamento regolare, sia il piano di controllo che il piano dati devono eseguire la stessa versione secondaria di Kubernetes, ad esempio 1.24. Mentre AWS gestisce e aggiorna il piano di controllo, l'aggiornamento dei nodi di lavoro nel piano dati è una tua responsabilità.

Prima dell'aggiornamento

Se hai intenzione di aggiornare la tua versione di Kubernetes in Amazon EKS, ci sono alcune politiche, strumenti e procedure importanti da mettere in atto prima di iniziare un aggiornamento.

Mantieni aggiornato il tuo cluster

Rimanere aggiornati con gli aggiornamenti di Kubernetes è fondamentale per un ambiente EKS sicuro ed efficiente, che riflette il modello di responsabilità condivisa di Amazon EKS. Integrando queste strategie nel flusso di lavoro operativo, ti stai posizionando per mantenere cluster aggiornati e sicuri che sfruttano appieno le funzionalità e i miglioramenti più recenti. Tattiche:

Consulta il calendario delle versioni di EKS

Consulta il calendario delle versioni di EKS Kubernetes per sapere quando arriveranno nuove versioni e quando terminerà il supporto per versioni specifiche. Generalmente, EKS rilascia tre versioni minori di Kubernetes all'anno e ciascuna versione secondaria è supportata per circa 14 mesi.

Inoltre, consulta le informazioni sulla versione originale di Kubernetes. https://kubernetes.io/releases/

Scopri come il modello di responsabilità condivisa si applica agli aggiornamenti dei cluster

Sei responsabile dell'avvio dell'aggiornamento sia del piano di controllo del cluster che del piano dati. Scopri come avviare un aggiornamento. Quando si avvia un aggiornamento del cluster, AWS gestisce l'aggiornamento del piano di controllo del cluster. Sei responsabile dell'aggiornamento del piano dati, inclusi i pod e i componenti aggiuntivi Fargate. Aggiorna componenti aggiuntivi e componenti utilizzando l'API Kubernetes È necessario convalidare e pianificare gli aggiornamenti per i carichi di lavoro in esecuzione sul cluster per garantire che la loro disponibilità e le loro operazioni non siano influenzate dopo l'aggiornamento del cluster

Aggiorna i cluster sul posto

EKS supporta una strategia di aggiornamento dei cluster sul posto. Ciò mantiene le risorse del cluster e mantiene la configurazione del cluster coerente (ad esempio, API endpoint, OIDC, ENI, load balancer). Ciò comporta meno interruzioni per gli utenti del cluster e utilizzerà i carichi di lavoro e le risorse esistenti nel cluster senza richiedere la ridistribuzione dei carichi di lavoro o la migrazione di risorse esterne (ad esempio, DNS, storage).

Quando si esegue un aggiornamento del cluster sul posto, è importante notare che è possibile eseguire solo un aggiornamento di versione minore alla volta (ad esempio, da 1,24 a 1,25).

Ciò significa che se è necessario aggiornare più versioni, sarà necessaria una serie di aggiornamenti sequenziali. La pianificazione degli aggiornamenti sequenziali è più complicata e comporta un rischio maggiore di tempi di inattività. In questa situazione, vedere. Valuta Blue/Green i cluster come alternativa agli aggiornamenti dei cluster sul posto

Aggiorna il piano di controllo e il piano dati in sequenza

Per aggiornare un cluster è necessario eseguire le seguenti azioni:

Utilizzate la documentazione EKS per creare una checklist per gli aggiornamenti

La documentazione della versione EKS Kubernetes include un elenco dettagliato delle modifiche per ciascuna versione. Crea una lista di controllo per ogni aggiornamento.

Per una guida specifica sull'aggiornamento della versione EKS, consulta la documentazione per le modifiche e le considerazioni importanti per ciascuna versione.

Aggiorna componenti aggiuntivi e componenti utilizzando l'API Kubernetes

Prima di aggiornare un cluster, dovresti capire quali versioni dei componenti Kubernetes stai utilizzando. Fai l'inventario dei componenti del cluster e identifica i componenti che utilizzano direttamente l'API Kubernetes. Ciò include componenti critici del cluster come agenti di monitoraggio e registrazione, scalatori automatici del cluster, driver di storage per container (ad esempio EBS CSI, EFS CSI), controller di ingresso e qualsiasi altro carico di lavoro o componente aggiuntivo che si basa direttamente sull'API Kubernetes.

kubectl get ns | grep '-system'

Una volta identificati i componenti che si basano sull'API Kubernetes, consulta la relativa documentazione per verificare la compatibilità delle versioni e i requisiti di aggiornamento. Ad esempio, consulta la documentazione di AWS Load Balancer Controller per la compatibilità delle versioni. Potrebbe essere necessario aggiornare alcuni componenti o modificare la configurazione prima di procedere con l'aggiornamento di un cluster. Alcuni componenti critici da controllare includono CoreDNS, kube-proxy, VPC CNI e driver di archiviazione.

I cluster spesso contengono molti carichi di lavoro che utilizzano l'API Kubernetes e sono necessari per la funzionalità dei carichi di lavoro, ad esempio controller di ingresso, sistemi di distribuzione continua e strumenti di monitoraggio. Quando si aggiorna un cluster EKS, è necessario aggiornare anche i componenti aggiuntivi e gli strumenti di terze parti per assicurarsi che siano compatibili.

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

Verifica i requisiti EKS di base prima dell'aggiornamento

AWS richiede determinate risorse nel tuo account per completare il processo di aggiornamento. Se queste risorse non sono presenti, il cluster non può essere aggiornato. L'aggiornamento del piano di controllo richiede le seguenti risorse:

Verifica gli indirizzi IP disponibili

Per aggiornare il cluster, Amazon EKS richiede fino a cinque indirizzi IP disponibili dalle sottoreti specificate al momento della creazione del cluster.

Per verificare che le sottoreti abbiano un numero sufficiente di indirizzi IP per aggiornare il cluster, puoi eseguire il seguente 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 |
+---------------------------+--------------+-------+

Il VPC CNI Metrics Helper può essere utilizzato per creare una dashboard per le metriche VPC. CloudWatch Amazon EKS consiglia di aggiornare le sottoreti del cluster utilizzando l'API "UpdateClusterConfiguration" prima di iniziare l'aggiornamento della versione di Kubernetes se si stanno esaurendo gli indirizzi IP nelle sottoreti inizialmente specificate durante la creazione del cluster. Verifica che le nuove sottoreti che ti verranno fornite:

Prendi in considerazione l'associazione di blocchi CIDR aggiuntivi se gli indirizzi IP nel blocco CIDR VPC esistente si esauriscono. AWS consente l'associazione di blocchi CIDR aggiuntivi con il cluster VPC esistente, ampliando efficacemente il pool di indirizzi IP. Questa espansione può essere ottenuta introducendo intervalli IP privati aggiuntivi (RFC 1918) o, se necessario, intervalli IP pubblici (non RFC 1918). È necessario aggiungere nuovi blocchi CIDR VPC e consentire il completamento dell'aggiornamento del VPC prima che Amazon EKS possa utilizzare il nuovo CIDR. Successivamente, puoi aggiornare le sottoreti in base ai blocchi CIDR appena configurati sul VPC.

Verifica il ruolo EKS IAM

Per verificare che il ruolo IAM sia disponibile e abbia la corretta politica di assunzione del ruolo nel tuo account, puoi eseguire i seguenti comandi:

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"
        }
    ]
}

Esegui la migrazione a EKS Add-ons

Amazon EKS installa automaticamente componenti aggiuntivi come il plug-in Amazon VPC CNI per Kubernetes e CoreDNS per ogni cluster. kube-proxy Add-ons può essere autogestito o installato come Amazon EKS. Add-ons Amazon EKS Add-ons è un modo alternativo per gestire i componenti aggiuntivi utilizzando l'API EKS.

Puoi usare Amazon EKS Add-ons per aggiornare le versioni con un solo comando. Ad esempio:

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

Verifica se hai un EKS Add-ons con:

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

Scopri di più sui componenti disponibili come EKS Add-ons e su come iniziare.

Scopri come fornire una configurazione personalizzata a un EKS Add-on.

Identifica e correggi l'utilizzo delle API rimosse prima di aggiornare il piano di controllo

È necessario identificare l'utilizzo delle API rimosse prima di aggiornare il piano di controllo EKS. A tale scopo, consigliamo di utilizzare strumenti in grado di controllare un cluster in esecuzione o i file manifest di Kubernetes statici e renderizzati.

L'esecuzione del controllo sui file manifest statici è generalmente più accurata. Se eseguiti su cluster attivi, questi strumenti potrebbero restituire falsi positivi.

Un'API Kubernetes obsoleta non significa che l'API sia stata rimossa. Dovresti controllare la politica di deprecazione di Kubernetes per capire in che modo la rimozione delle API influisce sui tuoi carichi di lavoro.

Cluster Insights

Cluster Insights è una funzionalità che fornisce informazioni su problemi che possono influire sulla capacità di aggiornare un cluster EKS alle versioni più recenti di Kubernetes. Questi risultati sono curati e gestiti da Amazon EKS e offrono consigli su come risolverli. Sfruttando Cluster Insights, puoi ridurre al minimo gli sforzi spesi per l'aggiornamento alle versioni più recenti di Kubernetes.

Per visualizzare gli approfondimenti di un cluster EKS, puoi eseguire il 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."
        }
    ]
}

Per un risultato più descrittivo sulle informazioni ricevute, puoi eseguire il comando:

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

Hai anche la possibilità di visualizzare gli approfondimenti nella console Amazon EKS. Dopo aver selezionato il cluster dall'elenco dei cluster, i risultati delle informazioni si trovano nella Upgrade Insights scheda.

Se trovi un cluster insight con"status": ERROR, devi risolvere il problema prima di eseguire l'aggiornamento del cluster. Esegui il aws eks describe-insight comando che condividerà i seguenti consigli di riparazione:

Risorse interessate:

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

API obsolete:

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

Azioni consigliate da intraprendere:

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

L'utilizzo delle informazioni sui cluster tramite la console EKS o la CLI aiuta a velocizzare il processo di aggiornamento corretto delle versioni dei cluster EKS. Scopri di più con le seguenti risorse: * Documenti ufficiali EKS * Blog di lancio di Cluster Insights.

Kube-no-trouble

Kube-no-troubleè un'utilità da riga di comando open source con il comandokubent. Quando viene eseguito kubent senza argomenti, utilizzerà il KubeConfig contesto corrente, scansionerà il cluster e stamperà un report con le API obsolete e rimosse.

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)

Può anche essere usato per scansionare file manifest statici e pacchetti helm. Si consiglia di eseguirlo kubent come parte di un processo di integrazione continua (CI) per identificare i problemi prima che i manifesti vengano distribuiti. La scansione dei manifesti è inoltre più accurata rispetto alla scansione dei cluster attivi.

Kube-no-trouble fornisce un esempio di account e ruolo di servizio con le autorizzazioni appropriate per la scansione del cluster.

Plutone

Un'altra opzione è pluto, che è simile kubent perché supporta la scansione di un cluster live, di file manifest, di helm chart e ha un' GitHub azione che puoi includere nel tuo processo CI.

pluto detect-all-in-cluster

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

Resources

Per verificare che il cluster non utilizzi API obsolete prima dell'aggiornamento, è necessario monitorare:

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

Che produrrà delle righe se sono in uso API obsolete:

{
    "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\"}}"
            },
[...]

Aggiorna i carichi di lavoro Kubernetes. Usa kubectl-convert per aggiornare i manifesti

Dopo aver identificato quali carichi di lavoro e manifesti devono essere aggiornati, potrebbe essere necessario modificare il tipo di risorsa nei file manifest (ad esempio to). PodSecurityPolicies PodSecurityStandards Ciò richiederà l'aggiornamento delle specifiche delle risorse e ulteriori ricerche a seconda della risorsa da sostituire.

Se il tipo di risorsa rimane lo stesso ma la versione dell'API deve essere aggiornata, puoi usare il kubectl-convert comando per convertire automaticamente i tuoi file manifest. Ad esempio, per convertire una distribuzione precedente inapps/v1. Per ulteriori informazioni, consulta Installare il plug-in di conversione kubectl sul sito web di Kubernetes.

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

Configurazione PodDisruptionBudgets e topologia SpreadConstraints per garantire la disponibilità dei carichi di lavoro durante l'aggiornamento del piano dati

Assicurati che i carichi di lavoro abbiano la topologia corretta PodDisruptionBudgets SpreadConstraints per garantire la disponibilità dei carichi di lavoro durante l'aggiornamento del piano dati. Non tutti i carichi di lavoro richiedono lo stesso livello di disponibilità, quindi è necessario convalidare la scalabilità e i requisiti del carico di lavoro.

Assicurati che i carichi di lavoro siano distribuiti in più zone di disponibilità e su più host con topologie diverse per garantire un maggiore livello di sicurezza che i carichi di lavoro migreranno automaticamente sul nuovo piano dati senza incidenti.

Ecco un esempio di carico di lavoro che avrà sempre l'80% delle repliche disponibili e le distribuirà su zone e host

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

AWS Resilience Hub ha aggiunto Amazon Elastic Kubernetes Service (Amazon EKS) come risorsa supportata. Resilience Hub offre un unico punto in cui definire, convalidare e monitorare la resilienza delle applicazioni in modo da evitare inutili tempi di inattività causati da interruzioni del software, dell'infrastruttura o operative.

Usa Managed Node Groups o Karpenter per semplificare gli aggiornamenti del piano dati

Managed Node Groups e Karpenter semplificano entrambi gli aggiornamenti dei nodi, ma adottano approcci diversi.

I gruppi di nodi gestiti automatizzano il provisioning e la gestione del ciclo di vita dei nodi. Ciò significa che è possibile creare, aggiornare automaticamente o terminare i nodi con una singola operazione.

Nella configurazione predefinita, Karpenter crea automaticamente nuovi nodi utilizzando l'ultima EKS Optimized AMI compatibile. Man mano che EKS rilascia le AMI EKS Optimized aggiornate o il cluster viene aggiornato, Karpenter inizierà automaticamente a utilizzare queste immagini. Karpenter implementa anche Node Expiry per aggiornare i nodi.

Karpenter può essere configurato per utilizzare AMI personalizzate. Se utilizzi AMI personalizzate con Karpenter, sei responsabile della versione di kubelet.

Conferma la compatibilità della versione con i nodi esistenti e il piano di controllo

Prima di procedere con un aggiornamento di Kubernetes in Amazon EKS, è fondamentale garantire la compatibilità tra i gruppi di nodi gestiti, i nodi autogestiti e il piano di controllo. La compatibilità è determinata dalla versione di Kubernetes in uso e varia in base ai diversi scenari. Tattiche:

Abilita la scadenza dei nodi per i nodi gestiti da Karpenter

Un modo in cui Karpenter implementa gli aggiornamenti dei nodi è utilizzare il concetto di scadenza dei nodi. Ciò riduce la pianificazione richiesta per gli aggiornamenti dei nodi. Quando imposti un valore per ttl SecondsUntilExpired nel tuo provisioner, si attiva la scadenza del nodo. Una volta raggiunta l'età definita in pochi secondi, i nodi vengono svuotati ed eliminati in modo sicuro. Ciò è vero anche se sono in uso, poiché consente di sostituire i nodi con istanze aggiornate appena eseguite il provisioning. Quando un nodo viene sostituito, Karpenter utilizza le AMI più recenti. EKS-optimized Per ulteriori informazioni, consulta Disruption sul sito Web di Karpenter.

Karpenter non aggiunge automaticamente jitter a questo valore. Per evitare un'eccessiva interruzione del carico di lavoro, definisci un budget per le interruzioni dei pod, come mostrato nella documentazione di Kubernetes.

Se configuri ttl SecondsUntilExpired su un provisioner, ciò si applica ai nodi esistenti associati al provisioner.

Usa la funzionalità Drift per i nodi gestiti da Karpenter

La funzione Drift di Karpenter può aggiornare automaticamente i Karpenter-provisioned nodi per rimanere sincronizzati con il piano di controllo EKS. Karpenter Drift deve attualmente essere abilitato utilizzando un feature gate. https://karpenter.sh/docs/reference/settings/#feature-gates La configurazione predefinita di Karpenter utilizza l' EKS-OptimizedAMI più recente per la stessa versione principale e secondaria del piano di controllo del cluster EKS.

Una volta completato l'aggiornamento del cluster EKS, la funzionalità Drift di Karpenter rileverà che Karpenter-provisioned i nodi utilizzano le EKS-Optimized AMI per la versione precedente del cluster e li isolerà, eliminerà e sostituirà automaticamente tali nodi. Per supportare il passaggio dei pod su nuovi nodi, segui le best practice di Kubernetes impostando le quote di risorse dei pod appropriate e utilizzando i pod disruption budgets (PDB). https://kubernetes.io/docs/concepts/workloads/pods/disruptions/ Il deprovisioning di Karpenter attiverà preventivamente i nodi sostitutivi in base alle richieste di risorse del pod e rispetterà i PDB durante il deprovisioning dei nodi.

Usa eksctl per automatizzare gli aggiornamenti per i gruppi di nodi autogestiti

I gruppi di nodi autogestiti sono istanze EC2 distribuite nel tuo account e collegate al cluster al di fuori del servizio EKS. Di solito vengono implementati e gestiti da una qualche forma di strumenti di automazione. Per aggiornare i gruppi di nodi autogestiti, è necessario fare riferimento alla documentazione degli strumenti.

Ad esempio, eksctl supporta l'eliminazione e il drenaggio dei nodi autogestiti.

Alcuni strumenti comuni includono:

Effettua il backup del cluster prima dell'aggiornamento

Le nuove versioni di Kubernetes introducono modifiche significative al cluster Amazon EKS. Puoi ripristinare un aggiornamento entro 7 giorni, ma ti consigliamo di eseguire il backup del cluster prima dell'aggiornamento.

Puoi eseguire il backup del cluster con AWS Backup, un servizio completamente gestito. Puoi anche usare Velero, uno strumento open source supportato dalla community.

Tieni presente che puoi creare nuovi cluster solo per le versioni di Kubernetes attualmente supportate da EKS. Se la versione attualmente in esecuzione nel cluster è ancora supportata e un aggiornamento non riesce, puoi creare un nuovo cluster con la versione originale e ripristinare il piano dati. Nota che le risorse AWS, incluso IAM, non sono incluse nel backup. È necessario ricreare queste risorse.

Riavviare gli schieramenti di Fargate dopo aver aggiornato il piano di controllo

Per aggiornare i nodi del piano dati Fargate è necessario ridistribuire i carichi di lavoro. Puoi identificare quali carichi di lavoro sono in esecuzione sui nodi Fargate elencando tutti i pod con l'opzione. -o wide Qualsiasi nome di nodo che inizia con fargate- dovrà essere ridistribuito nel cluster.

Valuta Blue/Green i cluster come alternativa agli aggiornamenti dei cluster sul posto

Alcuni clienti preferiscono adottare una blue/green strategia di upgrade. Ciò può comportare vantaggi, ma include anche aspetti negativi che dovrebbero essere considerati.

I vantaggi includono:

Alcuni aspetti negativi includono:

Sebbene questa strategia sia possibile, è più costosa di un aggiornamento sul posto e richiede più tempo per il coordinamento e le migrazioni dei carichi di lavoro. Può essere necessario in alcune situazioni e deve essere pianificato attentamente.

Con alti livelli di automazione e sistemi dichiarativi simili GitOps, questo potrebbe essere più facile da fare. Dovrai prendere ulteriori precauzioni per i carichi di lavoro statici, in modo che i dati vengano sottoposti a backup e migrati su nuovi cluster.

Per ulteriori informazioni, consulta questi post di blog:

Tieni traccia delle principali modifiche pianificate nel progetto Kubernetes: Think ahead

Non guardare solo alla prossima versione. Esamina le nuove versioni di Kubernetes man mano che vengono rilasciate e identifica le principali modifiche. Ad esempio, alcune applicazioni hanno utilizzato direttamente l'API docker e il supporto per Container Runtime Interface (CRI) per Docker (noto anche come Dockershim) è stato rimosso in Kubernetes. 1.24 Questo tipo di cambiamento richiede più tempo per prepararsi.

Rivedi tutte le modifiche documentate per la versione a cui stai effettuando l'aggiornamento e annota tutti i passaggi di aggiornamento richiesti. Inoltre, annota eventuali requisiti o procedure specifici dei cluster gestiti di Amazon EKS.

Linee guida specifiche sulla rimozione delle funzionalità

Rimozione di Dockershim nella versione 1.25 - Use Detector for Docker Socket (DDS)

L'AMI ottimizzata EKS per la versione 1.25 non include più il supporto per Dockershim. Se hai una dipendenza da Dockershim, ad esempio stai montando il socket Docker, dovrai rimuovere tali dipendenze prima di aggiornare i tuoi nodi di lavoro alla versione 1.25.

Trova i casi in cui hai una dipendenza dal socket Docker prima di eseguire l'aggiornamento alla versione 1.25. Ti consigliamo di usare Detector for Docker Socket (DDS), un plugin per kubectl. .

Rimozione della versione PodSecurityPolicy 1.25 - Migrazione agli standard di sicurezza Pod o a una soluzione basata sulla policy as code

PodSecurityPolicyè stato dichiarato obsoleto in Kubernetes 1.21 ed è stato rimosso in Kubernetes 1.25. Se lo utilizzi PodSecurityPolicy nel tuo cluster, devi migrare ai Kubernetes Pod Security Standards (PSS) integrati o a una soluzione policy-as-code prima di aggiornare il cluster alla versione 1.25 per evitare interruzioni dei carichi di lavoro.

AWS ha pubblicato una FAQ dettagliata nella documentazione EKS.

Consulta le best practice Pod Security Standards (PSS) e Pod Security Admission (PSA).

Leggi il post del blog PodSecurityPolicy Deprecation sul sito web di Kubernetes.

Deprecazione del driver di In-Tree archiviazione nella versione 1.23: migrazione ai driver CSI (Container Storage Interface)

La Container Storage Interface (CSI) è stata progettata per aiutare Kubernetes a sostituire i meccanismi esistenti dei driver di archiviazione integrati nell'albero. La funzionalità di migrazione dell'interfaccia di archiviazione dei container (CSI) di Amazon EBS è abilitata per impostazione predefinita su cluster Amazon EKS 1.23 e successivi. Se hai pod in esecuzione su una versione 1.22 o su un cluster precedente, devi installare il driver Amazon EBS CSI prima di aggiornare il cluster alla versione per evitare interruzioni del servizio. 1.23

Consulta le domande frequenti sulla migrazione di Amazon EBS CSI.

Risorse aggiuntive

ClowdHaus Guida all'aggiornamento di EKS

ClowdHaus EKS Upgrade Guidance è una CLI che aiuta ad aggiornare i cluster Amazon EKS. È in grado di analizzare un cluster per individuare eventuali problemi da risolvere prima dell'aggiornamento.

GoNoGo

GoNoGoè uno strumento in fase alfa per determinare l'affidabilità degli aggiornamenti dei componenti aggiuntivi del cluster.