Aiutaci a migliorare questa pagina
Vuoi contribuire a questa guida per l'utente? Scorri fino alla fine di questa pagina e seleziona Modifica questa pagina su GitHub. I tuoi contributi contribuiranno a rendere la nostra guida utente migliore per tutti.
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à.
Aggiorna il cluster esistente alla nuova versione di Kubernetes
Quando una nuova Kubernetes versione è disponibile in AmazonEKS, puoi aggiornare il tuo EKS cluster Amazon alla versione più recente.
Importante
Una volta aggiornato un cluster, non è possibile effettuare il downgrade a una versione precedente. Prima di eseguire l'aggiornamento a una nuova versione di Kubernetes, è consigliabile esaminare le informazioni contenute in Comprendi il ciclo di vita delle Kubernetes versioni su EKS e nella procedura di aggiornamento descritta in questo argomento.
Le nuove versioni di Kubernetes hanno introdotto modifiche significative. Pertanto ti consigliamo di verificare il comportamento delle applicazioni rispetto alla nuova versione di Kubernetes prima di eseguire l'aggiornamento sui cluster di produzione. Puoi eseguire questa operazione mediante la creazione di un flusso di lavoro di integrazione continua per testare il comportamento totale dell'applicazione prima di passare a una nuova versione di Kubernetes.
Il processo di aggiornamento consiste nel EKS lancio da parte di Amazon di nuovi nodi API server con la Kubernetes versione aggiornata per sostituire quelli esistenti. Amazon EKS esegue controlli standard dell'infrastruttura e dello stato di preparazione del traffico di rete su questi nuovi nodi per verificare che funzionino come previsto. Tuttavia, una volta avviato l'aggiornamento del cluster, non è possibile metterlo in pausa o interromperlo. Se uno di questi controlli fallisce, Amazon EKS ripristina la distribuzione dell'infrastruttura e il cluster rimane nella Kubernetes versione precedente. Le applicazioni in esecuzione non sono interessate e il cluster non viene mai lasciato in uno stato non deterministico o irrecuperabile. Amazon esegue EKS regolarmente il backup di tutti i cluster gestiti ed esistono meccanismi per ripristinare i cluster, se necessario. Stiamo valutando e migliorando costantemente i nostri processi di gestione dell'infrastruttura di Kubernetes.
Per aggiornare il cluster, Amazon EKS richiede fino a cinque indirizzi IP disponibili dalle sottoreti che hai specificato al momento della creazione del cluster. Amazon EKS crea nuove interfacce di rete elastiche per cluster (interfacce di rete) in tutte le sottoreti che hai specificato. Assicurati quindi che le regole del gruppo di sicurezza consentano la comunicazione necessaria con il cluster per una delle sottoreti specificate al momento della creazione del cluster. Se questa sottorete non esiste, se non ha abbastanza indirizzi IP disponibili o se non dispone di regole del gruppo di sicurezza per la comunicazione con il cluster, l'aggiornamento potrebbe non riuscire.
Nota
Per garantire che l'endpoint del API server per il tuo cluster sia sempre accessibile, Amazon EKS fornisce un piano di Kubernetes controllo ad alta disponibilità ed esegue aggiornamenti continui delle istanze del API server durante le operazioni di aggiornamento. Per tenere conto della modifica degli indirizzi IP delle istanze del API server che supportano l'endpoint del Kubernetes API server, è necessario assicurarsi che i client API server gestiscano le riconnessioni in modo efficace. Versioni recenti dikubectl
e ilKubernetesclientelibrerie
Aggiorna la Kubernetes versione per il tuo EKS cluster Amazon
Aggiornamento della versione di Kubernetes per il cluster
-
Confronta la versione di Kubernetes del piano di controllo (control-plane) del cluster con la versione di Kubernetes dei nodi.
-
Ottieni la versione di Kubernetes del piano di controllo (control-plane) del cluster.
kubectl version
-
Ottieni la versione di Kubernetes dei tuoi nodi. Questo comando restituisce tutti i nodi Amazon e Fargate autogestiti EC2 e gestiti. Ogni Pod Fargate è presente nell'elenco assieme al rispettivo nodo.
kubectl get nodes
Prima di aggiornare il piano di controllo (control-plane) a una nuova versione di Kubernetes, assicurati che la versione secondaria di Kubernetes dei nodi gestiti e dei nodi Fargate nel cluster sia la stessa della versione corrente del piano di controllo (control-plane). Ad esempio, se il piano di controllo è in esecuzione
1.29
e uno dei nodi è in esecuzione1.28
, è necessario aggiornare i nodi alla versione1.29
prima di aggiornare il piano di controllo alla versione 1.30. Prima di aggiornare il piano di controllo, si consiglia inoltre di aggiornare i nodi autogestiti alla stessa versione del piano di controllo. Per ulteriori informazioni, consulta Aggiorna un gruppo di nodi gestiti per il tuo cluster e Aggiorna i nodi autogestiti per il tuo cluster. Se hai nodi Fargate con una versione secondaria inferiore rispetto alla versione del piano di controllo (control-plane), devi prima eliminare il Pod rappresentato dal nodo. a aggiornare il piano di controllo (control-plane). Dopo averli implementati di nuovo, tutti i Pods rimanenti verranno aggiornati alla nuova versione. -
-
Se la versione di Kubernetes su cui è stato originariamente implementato il cluster era Kubernetes
1.25
o successiva, puoi ignorare questo passaggio.Per impostazione predefinita, il controller di ammissione delle policy di Pod sicurezza è abilitato sui EKS cluster Amazon. Assicurarsi che siano presenti le policy di sicurezza dei Pod appropriate prima di eseguire l'aggiornamento del cluster, al fine di evitare problemi. È possibile verificare la policy di default con il comando
kubectl get psp eks.privileged
.kubectl get psp eks.privileged
Se ricevi il seguente errore, consulta Policy di sicurezza Pod predefinita di Amazon EKS prima di procedere.
Error from server (NotFound): podsecuritypolicies.extensions "eks.privileged" not found
-
Se la versione di Kubernetes su cui è stato originariamente implementato il cluster era Kubernetes
1.18
o successiva, puoi ignorare questo passaggio.potrebbe essere necessario rimuovere un termine interrotto dal manifesto CoreDNS.
-
Controllare se il manifesto CoreDNS ha una riga contenente solo la parola
upstream
.kubectl get configmap coredns -n kube-system -o jsonpath='{$.data.Corefile}' | grep upstream
Se non viene restituito alcun output, il manifesto non presenta alcun riga ed è possibile passare alla fase successiva. Se come risultato viene restituita la parola
upstream
è necessario rimuoverla. -
Modificare il file configmap, rimuovendo la riga vicino alla parte superiore del file contenente solo la parola
upstream
. Non apportare ulteriori modifiche al file. Dopo aver rimosso la riga, salvare le modifiche.kubectl edit configmap coredns -n kube-system -o yaml
-
-
Aggiorna il cluster utilizzando
eksctl
, il AWS Management Console, o il AWS CLI.Importante
-
Se stai eseguendo l'aggiornamento alla versione
1.23
e utilizzi EBS volumi Amazon nel tuo cluster, devi installare il EBS CSI driver Amazon nel cluster prima di aggiornare il cluster alla versione per1.23
evitare interruzioni del carico di lavoro. Per ulteriori informazioni, consulta Kubernetes1.23 e Archivia Kubernetes volumi con Amazon EBS. -
Kubernetes
1.24
e versioni successive utilizzanocontainerd
come runtime del container predefinito. Se stai passando al runtimecontainerd
e hai già configurato Fluentd per Container Insights, devi eseguire la migrazione di Fluentd a Fluent Bit prima di aggiornare il cluster. I Fluentd parser sono configurati per analizzare solo i messaggi di log in formato. JSON Al contrariodockerd
, il runtime delcontainerd
contenitore contiene messaggi di registro che non sono in JSON formato. Se non esegui la migrazione a Fluent Bit, alcuni dei parser Fluentd's configurati genereranno un'enorme quantità di errori all'interno del container Fluentd. Per ulteriori informazioni sulla migrazione, consulta Configurare Fluent Bit come invio DaemonSet di log a Logs. CloudWatch -
Poiché Amazon EKS utilizza un piano di controllo ad alta disponibilità, puoi aggiornare solo una versione secondaria alla volta. Per ulteriori informazioni su questo requisito, consulta Versione di Kubernetes e policy per il supporto Skew della versione
. Supponiamo che la versione corrente del cluster sia 1.28
e che desideri aggiornarlo alla versione1.30
. Devi prima aggiornare la versione1.28
del cluster alla versione1.29
, quindi aggiornare la versione1.29
del cluster alla versione1.30
. -
Verifica la discrepanza di versione tra
kube-apiserver
ekubelet
di Kubernetes sui nodi.-
A partire dalla versione
1.28
di Kubernetes,kubelet
può essere fino a tre versioni minori precedenti rispetto akube-apiserver
. Consulta la sezione Kubernetes upstream version skew policy. -
Se
kubelet
sui nodi gestiti e Fargate è nella versione1.25
o più recente di Kubernetes, è possibile aggiornare il cluster fino a tre versioni successive senza aggiornare la versione dikubelet
. Ad esempio, se la versionekubelet
è attiva1.25
, puoi aggiornare la versione EKS del cluster Amazon da1.25
a1.26
1.27
, a e a1.28
mentre la versionekubelet
rimane attiva1.25
. -
Se
kubelet
sui nodi gestiti e Fargate è nella versione1.24
o precedente di Kubernetes, può essere al massimo di due versioni minori precedenti rispetto akube-apiserver
. In altre parole, sekubelet
è nella versione1.24
o precedente, è possibile aggiornare il cluster solo fino a due versioni successive. Ad esempio, se la versionekubelet
è1.21
attiva, puoi aggiornare la versione del EKS cluster Amazon da1.21
a1.22
e verso1.23
, ma non sarai in grado di aggiornare il cluster a1.24
mentrekubelet
rimane attivo1.21
.
-
-
Come best practice prima di iniziare un aggiornamento, assicurati che il
kubelet
sui tuoi nodi sia alla stessa versione di Kubernetes del tuo piano di controllo. -
Se il cluster è configurato con una versione di Amazon VPC CNI plugin for Kubernetes precedente a
1.8.0
, è preferibile aggiornare il plug-in all'ultima versione prima di aggiornare il cluster. Per aggiornare il plug-in, consulta Lavorare con il EKS componente aggiuntivo Amazon VPC CNI plugin for Kubernetes Amazon. -
Se stai aggiornando il cluster alla versione
1.25
o successiva e hai AWS Load Balancer Controller distribuito nel cluster, aggiorna il controller alla versione2.4.7
o successiva prima di aggiornare la versione del cluster a1.25
. Per ulteriori informazioni, consulta le note di rilascio di Kubernetes1,25.
-
-
Una volta completato l'aggiornamento del cluster, aggiorna i nodi alla stessa versione secondaria di Kubernetes del cluster aggiornato. Per ulteriori informazioni, consulta Aggiorna i nodi autogestiti per il tuo cluster e Aggiorna un gruppo di nodi gestiti per il tuo cluster. Tutti i nuovi Pods avviati in Fargate hanno una versione di
kubelet
che corrisponde alla versione del cluster. I Pods Fargate esistenti non vengono modificati. -
(Facoltativo) Se hai implementato Kubernetes Cluster Autoscaler nel cluster prima di aggiornarlo, aggiorna Cluster Autoscaler alla versione più recente che corrisponde alla versione principale e secondaria di Kubernetes per cui è stato eseguito l'aggiornamento.
-
Apri la pagina delle versioni
di Cluster Autoscaler in un browser Web e trova la versione più recente di Cluster Autoscaler corrispondente alla versione principale e secondaria di Kubernetes del cluster. Ad esempio, se la versione di Kubernetes del cluster è 1.30
, cerca la versione più recente di Cluster Autoscaler che inizia con1.30
. Registra il numero di versione semantica (1.30.n
, ad esempio) per tale versione da utilizzare nella fase successiva. -
Impostare il tag image di Cluster Autoscaler sulla versione registrata nella fase precedente mediante il comando seguente. Se necessario, sostituire
con il valore in proprio possesso.1.30
.n
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:v
1.30
.n
-
-
(Solo cluster con GPU nodi) Se il cluster dispone di gruppi di nodi con GPU supporto (ad esempio,
p3.2xlarge
), è necessario aggiornare il plug-in del NVIDIA dispositivo KubernetesDaemonSet sul cluster.
Sostituiscilo con la s-device-plugin versione NVIDIA/k8vX.X.X
desiderata prima di eseguire il comando seguente. kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/
vX.X.X
/deployments/static/nvidia-device-plugin.yml -
Aggiorna Amazon VPC CNI plugin for Kubernetes, CoreDNS e i componenti aggiuntivi
kube-proxy
. È preferibile aggiornare i componenti aggiuntivi alle versioni minime elencate nei Token dell'account di servizio.-
Se utilizzi EKS componenti aggiuntivi Amazon, seleziona Clusters nella EKS console Amazon, quindi seleziona il nome del cluster che hai aggiornato nel riquadro di navigazione a sinistra. Le notifiche vengono visualizzate nella console Ti viene segnalato che è disponibile una nuova versione per ogni componente aggiuntivo per cui è disponibile un aggiornamento. Per aggiornare un componente aggiuntivo, seleziona la scheda Add-ons (Componenti aggiuntivi). In una delle caselle relative al componente aggiuntivo che dispone di un aggiornamento disponibile, selezionare Aggiorna ora, selezionare una versione disponibile e quindi selezionare Aggiorna.
-
In alternativa, puoi utilizzare AWS CLI o per aggiornare i componenti aggiuntivi
eksctl
. Per ulteriori informazioni, consulta Aggiornamento di un EKS componente aggiuntivo Amazon.
-
-
Se necessario, aggiorna la tua versione di
kubectl
. È necessario utilizzare unakubectl
versione che rientri in una differenza di versione minore del piano di controllo del EKS cluster Amazon. Ad esempio, un clientkubectl
1.29
funziona con i cluster Kubernetes1.28
,1.29
e1.30
. Puoi controllare la versione attualmente installata con il seguente comando.kubectl version --client
Effettua il downgrade della Kubernetes versione per un cluster Amazon EKS
Non è possibile effettuare il downgrade Kubernetes di un EKS cluster Amazon. Invece, crea un nuovo cluster su una EKS versione precedente di Amazon e migra i carichi di lavoro.