Procedure consigliate per gli aggiornamenti dei cluster - Amazon EKS
PanoramicaPrima dell'aggiornamentoMantieni il tuo cluster up-to-dateConsulta il calendario dei rilasci EKSScopri come si applica il modello di responsabilità condivisa agli aggiornamenti del clusterAggiorna i cluster sul postoAggiorna il piano di controllo e il piano dati in sequenzaUsa la EKS documentazione per creare una lista di controllo per l'aggiornamentoAggiorna componenti aggiuntivi e componenti utilizzando Kubernetes APIVerifica i requisiti di base prima dell'aggiornamento EKSEsegui la migrazione ai componenti aggiuntivi EKSIdentifica e correggi l'APIutilizzo rimosso prima di aggiornare il piano di controlloAggiorna i carichi di lavoro Kubernetes. Usa kubectl-convert per aggiornare i manifestiConfigura PodDisruptionBudgets e garantisci topologySpreadConstraints la disponibilità dei tuoi carichi di lavoro durante l'aggiornamento del piano datiUtilizza Managed Node Groups o Karpenter per semplificare gli aggiornamenti del piano datiConferma la compatibilità della versione con i nodi esistenti e il piano di controlloAbilita la scadenza dei nodi per i nodi gestiti da KarpenterUsa la funzione Drift per i nodi gestiti da KarpenterUsa eksctl per automatizzare gli aggiornamenti per i gruppi di nodi autogestitiBackup del cluster prima dell'aggiornamentoRiavvia gli schieramenti di Fargate dopo aver aggiornato il piano di controlloValuta i cluster blu/verdi come alternativa agli aggiornamenti del cluster sul postoTieni traccia delle principali modifiche pianificate nel progetto Kubernetes: pensa al futuroLinee guida specifiche sulla rimozione delle funzionalitàRisorse aggiuntive

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 dei cluster come pianificare ed eseguire la loro strategia di EKS upgrade di Amazon. Descrive inoltre come aggiornare i nodi autogestiti, i gruppi di nodi gestiti, i nodi Karpenter e i nodi Fargate. Non include indicazioni su EKS Anywhere, Kubernetes, AWS Outposts o Local Zones autogestiti. AWS

Panoramica

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. Oltre alla AWS gestione e all'aggiornamento del piano di controllo, l'aggiornamento dei nodi di lavoro nel piano dati è responsabilità dell'utente.

  • Piano di controllo: la versione del piano di controllo è determinata dal server API Kubernetes. Nei EKS cluster Amazon, AWS si occupa della gestione di questo componente. Gli aggiornamenti del piano di controllo possono essere avviati tramite. AWS API

  • Piano dati: la versione del piano dati è associata alle versioni di Kubelet in esecuzione sui singoli nodi. È possibile avere nodi nello stesso cluster che eseguono versioni diverse. Puoi controllare le versioni di tutti i nodi eseguendokubectl get nodes.

Prima dell'aggiornamento

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

Mantieni il tuo cluster up-to-date

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

  • Politica sulle versioni supportate: in linea con la community Kubernetes, Amazon fornisce EKS in genere tre versioni di Kubernetes attive. Una versione secondaria di Kubernetes è soggetta al supporto standard in Amazon EKS per i primi 14 mesi dopo il suo rilascio. Una volta superata la data di fine del supporto standard, una versione passa al supporto esteso per i 12 mesi successivi. Gli avvisi di obsolescenza vengono emessi almeno 60 giorni prima che una versione raggiunga la fine della data di supporto standard. Per maggiori dettagli, consulta la documentazione relativa al ciclo di vita della versioneEKS.

  • Politica di aggiornamento automatico: consigliamo vivamente di rimanere sincronizzati con gli aggiornamenti di Kubernetes nel cluster. EKS I cluster in esecuzione su una versione di Kubernetes che ha completato il ciclo di vita di 26 mesi (14 mesi di supporto standard più 12 mesi di supporto esteso) verranno aggiornati automaticamente alla versione successiva. Tieni presente che puoi disabilitare il supporto esteso. Il mancato aggiornamento proattivo prima di una versione end-of-life attiva un aggiornamento automatico, che potrebbe interrompere i carichi di lavoro e i sistemi. Per ulteriori informazioni, consulta la versione. EKS FAQs

  • Create Upgrade Runbook: stabilite un processo ben documentato per la gestione degli aggiornamenti. Come parte del vostro approccio proattivo, sviluppate runbook e strumenti specializzati su misura per il vostro processo di aggiornamento. Ciò non solo migliora la preparazione, ma semplifica anche le transizioni complesse. Trasformate l'aggiornamento dei cluster almeno una volta all'anno come prassi standard. Questa pratica ti allinea ai continui progressi tecnologici, aumentando così l'efficienza e la sicurezza del tuo ambiente.

Consulta il calendario dei rilasci EKS

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

Inoltre, consulta le informazioni sulla release upstream di Kubernetes.

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

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

Aggiorna i cluster sul posto

EKSsupporta una strategia di aggiornamento dei cluster in loco. Ciò mantiene le risorse del cluster e mantiene coerente la configurazione del cluster (ad esempio, API endpoint, OIDCENIs, 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, lo storage). DNS

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, vedi. Valuta i cluster blu/verdi come alternativa agli aggiornamenti del cluster sul posto

Aggiorna il piano di controllo e il piano dati in sequenza

Per aggiornare un cluster è necessario eseguire le seguenti azioni:

  1. Consulta Kubernetes e EKS le note di rilascio.

  2. Effettua un backup del cluster. (opzionale)

  3. Identifica e correggi l'APIutilizzo obsoleto e rimosso nei tuoi carichi di lavoro.

  4. Assicurati che i gruppi di nodi gestiti, se utilizzati, siano sulla stessa versione di Kubernetes del piano di controllo. EKSi gruppi di nodi gestiti e i nodi creati da EKS Fargate Profiles supportano 2 versioni secondarie asimmetriche tra il piano di controllo e il piano dati per Kubernetes versione 1.27 e precedenti. A partire dalla versione 1.28 e successive, i gruppi di nodi EKS gestiti e i nodi creati da EKS Fargate Profiles supportano 3 versioni minori tra il piano di controllo e il piano dati. Ad esempio, se la versione del piano EKS di controllo è la 1.28, è possibile utilizzare in sicurezza versioni di kubelet precedenti alla 1.25. Se la tua EKS versione è 1.27, la versione di kubelet più vecchia che puoi usare è la 1.25.

  5. Aggiorna il piano di controllo del cluster utilizzando la console o la cliAWS.

  6. Verifica la compatibilità dei componenti aggiuntivi. Aggiorna i componenti aggiuntivi e i controller personalizzati di Kubernetes, se necessario.

  7. Aggiorna kubectl.

  8. Aggiorna il piano dati del cluster. Aggiorna i tuoi nodi alla stessa versione secondaria di Kubernetes del cluster aggiornato.

Usa la EKS documentazione per creare una lista di controllo per l'aggiornamento

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

Per indicazioni specifiche sull'aggiornamento di una EKS versione, consulta la documentazione per le modifiche e le considerazioni più importanti per ciascuna versione.

Aggiorna componenti aggiuntivi e componenti utilizzando Kubernetes API

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

Suggerimento

I componenti critici del cluster vengono spesso installati in un namespace *-system

kubectl get ns | grep '-system'

Dopo aver identificato i componenti che si basano su KubernetesAPI, consulta la relativa documentazione per verificare la compatibilità delle versioni e i requisiti di aggiornamento. Ad esempio, consulta la documentazione del AWSLoad Balancer Controller per la compatibilità delle versioni. Potrebbe essere necessario aggiornare alcuni componenti o modificare la configurazione prima di procedere con l'aggiornamento del cluster. Alcuni componenti critici da controllare includono Core DNS, kube-proxy e driver di archiviazione. VPCCNI

I cluster spesso contengono molti carichi di lavoro che utilizzano Kubernetes API e sono necessari per funzionalità di carico di lavoro come controller di ingresso, sistemi di distribuzione continua e strumenti di monitoraggio. Quando si aggiorna un EKS cluster, è 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 di base prima dell'aggiornamento EKS

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

  1. Indirizzi IP disponibili: Amazon EKS richiede fino a cinque indirizzi IP disponibili dalle sottoreti specificate al momento della creazione del cluster per aggiornare il cluster. In caso contrario, aggiorna la configurazione del cluster per includere nuove sottoreti del cluster prima di eseguire l'aggiornamento della versione.

  2. EKSIAMruolo: il IAM ruolo del piano di controllo è ancora presente nell'account con le autorizzazioni necessarie.

  3. Se nel cluster è abilitata la crittografia segreta, assicurati che il IAM ruolo del cluster sia autorizzato a utilizzare la AWS chiave Key Management Service (AWSKMS).

Verifica gli indirizzi IP disponibili

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

Per verificare che le sottoreti dispongano di indirizzi IP sufficienti 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 VPCCNIMetrics Helper può essere utilizzato per creare una CloudWatch dashboard per le metriche. VPC Amazon EKS consiglia di aggiornare le sottoreti del cluster utilizzando "UpdateClusterConfiguration" API prima di iniziare un aggiornamento della versione di Kubernetes se gli indirizzi IP nelle sottoreti inizialmente specificate durante la creazione del cluster sono esauriti. Verifica che le nuove sottoreti che ti verranno fornite:

  • appartengono allo stesso insieme di AZs quelli selezionati durante la creazione del cluster.

  • appartengono allo stesso VPC fornito durante la creazione del cluster

Valuta la possibilità di associare CIDR blocchi aggiuntivi se gli indirizzi IP nel VPC CIDR blocco esistente si esauriscono. AWSconsente l'associazione di CIDR blocchi aggiuntivi al cluster esistenteVPC, ampliando efficacemente il pool di indirizzi IP. Questa espansione può essere realizzata introducendo intervalli IP privati aggiuntivi (RFC1918) o, se necessario, intervalli IP pubblici (diversi dal RFC 1918). Devi aggiungere nuovi VPC CIDR blocchi e consentire il completamento dell'VPCaggiornamento prima che Amazon EKS possa utilizzare il nuovoCIDR. Dopodiché, puoi aggiornare le sottoreti in base ai CIDR blocchi appena configurati a. VPC

Verifica il ruolo EKS IAM

Per verificare che il IAM ruolo 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 ai componenti aggiuntivi EKS

Amazon installa EKS automaticamente componenti aggiuntivi come il VPC CNI plug-in Amazon per Kubernetes e Core per ogni kube-proxy cluster. DNS I componenti aggiuntivi possono essere gestiti automaticamente o installati come componenti aggiuntivi AmazonEKS. Amazon EKS Add-ons è un modo alternativo per gestire i componenti aggiuntivi utilizzando. EKS API

Puoi utilizzare 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 disponi di EKS componenti aggiuntivi con:

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

EKSI componenti aggiuntivi non vengono aggiornati automaticamente durante un aggiornamento del piano di controllo. È necessario avviare gli aggiornamenti dei EKS componenti aggiuntivi e selezionare la versione desiderata.

Scopri di più su quali componenti sono disponibili come EKS componenti aggiuntivi e su come iniziare.

Scopri come fornire una configurazione personalizzata a un EKS componente aggiuntivo.

Identifica e correggi l'APIutilizzo rimosso prima di aggiornare il piano di controllo

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

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

Un Kubernetes obsoleto non significa API che sia stato rimosso. API Dovresti controllare la politica di deprecazione di Kubernetes per capire in che modo la rimozione influisce sui tuoi carichi di lavoro. API

Cluster Insights

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

Per visualizzare informazioni dettagliate su un EKS cluster, 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 output 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 EKSconsole Amazon. Dopo aver selezionato il cluster dall'elenco dei cluster, i risultati degli approfondimenti si trovano nella Upgrade Insights scheda.

Se trovi una panoramica del cluster 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"
      }
]

APIsobsoleto:

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

Azione consigliata da intraprendere:

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

Utilizza Cluster Insights tramite la EKS Console o CLI contribuisci a velocizzare il processo di aggiornamento EKS corretto delle versioni del cluster. Scopri di più con le seguenti risorse: * EKSDocumenti ufficiali* Blog di lancio di Cluster Insights.

K ube-no-trouble

K ube-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 rapporto con ciò che APIs verrà obsoleto e rimosso.

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 della distribuzione dei manifesti. La scansione dei manifesti è inoltre più accurata rispetto alla scansione dei cluster live.

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 grafici helm 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

Risorse

Per verificare che il cluster non utilizzi la versione deprecata APIs prima dell'aggiornamento, è necessario monitorare:

  • metrica a partire apiserver_requested_deprecated_apis da Kubernetes v1.19:

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à le righe se sono in uso quelle APIs 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 cambiare 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 che verrà sostituita.

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

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

Configura PodDisruptionBudgets e garantisci topologySpreadConstraints la disponibilità dei tuoi carichi di lavoro durante l'aggiornamento del piano dati

Assicurati che i carichi di lavoro siano adeguati PodDisruptionBudgetse garantisci topologySpreadConstraintsla 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. Gli spread topologici offriranno un maggiore livello di fiducia nella migrazione automatica dei carichi di lavoro al nuovo piano dati senza incidenti.

Ecco un esempio di carico di lavoro in cui l'80% delle repliche sarà sempre disponibile e distribuirà le repliche tra 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

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

Utilizza 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 versione compatibile di Optimized. EKS AMI Man mano che le EKS versioni di EKS Optimized vengono aggiornate AMIs 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 l'utilizzo personalizzato. AMIs Se usi custom AMIs 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 AmazonEKS, è 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 a diversi scenari. Tattiche:

  • Kubernetes v1.28+ — * * A partire dalla versione 1.28 di Kubernetes e successive, esiste una politica di versione più favorevole per i componenti principali. In particolare, l'inclinazione supportata tra il API server Kubernetes e il kubelet è stata estesa con una versione minore, che va da n-2 a n-3. Ad esempio, se la versione del tuo EKS control plane è la 1.28, puoi tranquillamente utilizzare versioni di kubelet precedenti alla 1.25. Questa versione skew è supportata in AWSFargate, nei gruppi di nodi gestiti e nei nodi autogestiti. Consigliamo vivamente di conservare le versioni di Amazon Machine Image (AMI) up-to-date per motivi di sicurezza. Le versioni precedenti di kubelet potrebbero comportare rischi per la sicurezza a causa di potenziali vulnerabilità ed esposizioni comuni (CVEs), che potrebbero superare i vantaggi dell'utilizzo di versioni precedenti di kubelet.

  • Kubernetes < v1.28 — Se utilizzi una versione precedente alla v1.28, l'inclinazione supportata tra il server e il kubelet è n-2. API Ad esempio, se la tua EKS versione è 1.27, la versione di kubelet più vecchia che puoi utilizzare è la 1.25. Questa versione asimmetrica è applicabile a AWSFargate, ai gruppi di nodi gestiti e ai nodi autogestiti.

Abilita la scadenza dei nodi per i nodi gestiti da Karpenter

Un modo in cui Karpenter implementa gli aggiornamenti dei nodi consiste nell'utilizzare il concetto di scadenza dei nodi. Ciò riduce la pianificazione richiesta per gli aggiornamenti dei nodi. Quando si imposta un valore per ttlSecondsUntilExpired nel provider, viene attivata la scadenza del nodo. Dopo che i nodi hanno raggiunto l'età definita in pochi secondi, vengono svuotati ed eliminati in modo sicuro. Questo vale anche se sono in uso e consente di sostituire i nodi con istanze aggiornate di nuova generazione. Quando un nodo viene sostituito, Karpenter utilizza l'ultima versione ottimizzata. EKS AMIs Per ulteriori informazioni, consulta Deprovisioning sul sito Web di Karpenter.

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

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

Usa la funzione Drift per i nodi gestiti da Karpenter

La funzione Drift di Karpenter può aggiornare automaticamente i nodi forniti da Karpenter per rimanere sincronizzati con il piano di controllo. EKS Karpenter Drift attualmente deve essere abilitato utilizzando un feature gate. La configurazione predefinita di Karpenter utilizza l'ultima versione EKS -Optimized AMI per la stessa versione principale e secondaria del piano di controllo del cluster. EKS

Una volta completato l'aggiornamento del EKS cluster, la funzionalità Drift di Karpenter rileverà che i nodi forniti da Karpenter utilizzano EKS -Optimized AMIs per la versione precedente del cluster e isolerà, drenerà e sostituirà automaticamente tali nodi. Per supportare il trasferimento dei pod su nuovi nodi, segui le best practice di Kubernetes impostando le quote di risorse appropriate per i pod e utilizzando i budget di interruzione dei pod (). PDB Il deprovisioning di Karpenter preavvierà i nodi sostitutivi in base alle richieste di risorse dei pod e rispetterà i nodi al momento del deprovisioning. PDBs

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

I gruppi di nodi autogestiti sono EC2 istanze distribuite nell'account e collegate al cluster all'esterno del servizio. EKS Di solito vengono implementati e gestiti mediante 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:

Backup del cluster prima dell'aggiornamento

Le nuove versioni di Kubernetes introducono modifiche significative al tuo cluster Amazon. EKS Dopo aver aggiornato un cluster, non puoi effettuarne il downgrade.

Velero è uno strumento open source supportato dalla community che può essere utilizzato per eseguire backup di cluster esistenti e applicarli a un nuovo cluster.

Tieni presente che puoi creare nuovi cluster solo per le versioni di Kubernetes attualmente supportate da. EKS Se la versione attualmente in esecuzione sul cluster è ancora supportata e un aggiornamento non riesce, puoi creare un nuovo cluster con la versione originale e ripristinare il piano dati. Tieni presente che AWS le risorseIAM, incluse, non sono incluse nel backup di Velero. Queste risorse dovrebbero essere ricreate.

Riavvia 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. È possibile 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 i cluster blu/verdi come alternativa agli aggiornamenti del cluster sul posto

Alcuni clienti preferiscono adottare una strategia di aggiornamento blu/verde. Ciò può comportare vantaggi, ma include anche aspetti negativi che devono essere considerati.

I vantaggi includono:

  • Possibilità di modificare più EKS versioni contemporaneamente (ad esempio da 1.23 a 1.25)

  • In grado di tornare al vecchio cluster

  • Crea un nuovo cluster che può essere gestito con sistemi più recenti (ad esempio terraform)

  • I carichi di lavoro possono essere migrati individualmente

Alcuni aspetti negativi includono:

  • APIendpoint e OIDC modifica che richiedono l'aggiornamento dei consumatori (ad esempio kubectl e CI/CD)

  • Richiede l'esecuzione di 2 cluster in parallelo durante la migrazione, il che può essere costoso e limitare la capacità della regione

  • È necessario un maggiore coordinamento se i carichi di lavoro dipendono l'uno dall'altro per essere migrati insieme

  • I sistemi di bilanciamento del carico e quelli esterni DNS non possono estendersi facilmente su più cluster

Sebbene questa strategia sia possibile, è più costosa di un aggiornamento in loco e richiede più tempo per il coordinamento e le migrazioni dei carichi di lavoro. In alcune situazioni può essere necessaria e deve essere pianificata con attenzione.

Con alti gradi di automazione e sistemi dichiarativi come GitOps, questo potrebbe essere più facile da fare. Dovrai adottare ulteriori precauzioni per i carichi di lavoro con stato, in modo che i dati vengano sottoposti a backup e migrati in nuovi cluster.

Per ulteriori informazioni, consulta i post di questi blog:

Tieni traccia delle principali modifiche pianificate nel progetto Kubernetes: pensa al futuro

Non guardare solo alla prossima versione. Rivedi le nuove versioni di Kubernetes non appena vengono rilasciate e identifica le modifiche principali. Ad esempio, alcune applicazioni utilizzavano direttamente il docker API e il supporto per Container Runtime Interface (CRI) per Docker (noto anche come Dockershim) è stato rimosso in Kubernetes. 1.24 Questo tipo di modifica richiede più tempo per prepararsi.

Esamina tutte le modifiche documentate per la versione a cui stai eseguendo l'aggiornamento e annota eventuali passaggi di aggiornamento richiesti. Inoltre, prendi nota di eventuali requisiti o procedure specifici per i cluster EKS gestiti da Amazon.

Linee guida specifiche sulla rimozione delle funzionalità

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

L'EKSOptimized AMI for 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 nodi di lavoro alla versione 1.25.

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

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

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

AWSFAQne EKS ha pubblicato un dettaglio nella documentazione.

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 archiviazione In-Tree nella versione 1.23 - Migrazione ai driver dell'interfaccia di storage container () CSI

La Container Storage Interface (CSI) è stata progettata per aiutare Kubernetes a sostituire i meccanismi esistenti dei driver di storage in-tree. La funzionalità di migrazione di Amazon EBS Container Storage Interface (CSI) è abilitata per impostazione predefinita in Amazon EKS 1.23 e nei cluster successivi. Se disponi di pod in esecuzione su una versione 1.22 o su un cluster precedente, devi installare il EBSCSIdriver Amazon prima di aggiornare il cluster alla versione per 1.23 evitare interruzioni del servizio.

Consulta le domande frequenti EBS CSI sulla migrazione ad Amazon.

Risorse aggiuntive

ClowdHaus EKSGuida all'aggiornamento

ClowdHaus EKSUpgrade Guidance è un CLI aiuto nell'aggiornamento dei cluster AmazonEKS. Può analizzare un cluster alla ricerca di eventuali problemi potenziali da risolvere prima dell'aggiornamento.

GoNoGo

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

📝 Modifica questa pagina su GitHub