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à.
Best practice per il rollback delle versioni del cluster
Con il rollback della versione di Amazon Elastic Kubernetes Service (Amazon EKS), puoi ripristinare il piano di controllo Kubernetes del cluster alla versione secondaria precedente entro 7 giorni dall'aggiornamento in loco. Questa pagina descrive le migliori pratiche per pianificare, eseguire e rendere operativo il rollback come parte del flusso di lavoro di aggiornamento.
Scopri come il modello di responsabilità condivisa si applica al rollback
Quando avvii il rollback di una versione del cluster, Amazon EKS gestisce il ripristino del piano di controllo. Sei responsabile del piano dati, dei componenti aggiuntivi e della compatibilità delle applicazioni. Di seguito sono descritte le responsabilità:
-
Amazon EKS gestisce: ripristino del server dell'API Kubernetes e dei componenti del piano di controllo. Per i cluster Auto Mode, Amazon EKS gestisce anche il rollback dei nodi di lavoro.
-
Sei responsabile di: ripristinare i gruppi di nodi gestiti, i nodi autogestiti e i nodi ibridi. È inoltre necessario convalidare la compatibilità dei componenti aggiuntivi e assicurarsi che le applicazioni, i controller personalizzati e gli strumenti di terze parti funzionino correttamente con la versione precedente.
Per ulteriori informazioni sul modello di responsabilità condivisa per gli aggiornamenti, consulta Comprendere in che modo il modello di responsabilità condivisa si applica agli aggiornamenti del cluster.
Pianifica gli aggiornamenti tenendo presente il rollback
Il rollback della versione funziona al meglio quando il flusso di lavoro di aggiornamento è progettato in modo da mantenere aperta la finestra di rollback.
-
Aggiornamenti separati del piano di controllo e del piano dati (cluster non in modalità automatica). Per i cluster che utilizzano gruppi di nodi gestiti o nodi autogestiti, è consigliabile aggiornare prima il piano di controllo e prevedere un periodo di attesa prima di aggiornare i nodi di lavoro. Mentre i nodi rimangono attivi N-1, la versione kubelet skew insight rimane nello stato PASSING. Ciò mantiene il percorso di rollback chiaro senza dover prima ripristinare i nodi.
-
Aggiorna i componenti aggiuntivi a versioni compatibili tra loro. Prima di aggiornare il piano di controllo, assicurati che tutti i componenti aggiuntivi (gestiti e autogestiti) siano compatibili con la versione attuale e quella di destinazione di Kubernetes. Ciò mantiene chiare le informazioni sulla compatibilità dei componenti aggiuntivi sia per l'aggiornamento che per il rollback.
-
Usa i componenti aggiuntivi gestiti di Amazon EKS per trarre vantaggio dalle informazioni sulla preparazione al rollback che verificano automaticamente la compatibilità delle versioni dei componenti aggiuntivi.
-
Evita la gestione automatica di un componente aggiuntivo gestito (ad esempio, sostituendo la versione al di fuori del ciclo di vita del componente aggiuntivo EKS). Durante il rollback, Insights considera la configurazione del componente aggiuntivo gestito come una fonte attendibile e non rileva variazioni di versione introdotte.
-
-
Evita di utilizzare API specifiche della versione durante il periodo di cottura. Se crei risorse che utilizzano API o funzionalità disponibili solo nella nuova versione durante la finestra di 7 giorni, devi rimuoverle prima di eseguire il rollback. Limita l'adozione di API solo per le nuove versioni finché non sei sicuro che l'aggiornamento sia stabile.
-
Effettua l'upgrade prima, non dopo. Con il rollback disponibile, puoi eseguire l'aggiornamento in tutta sicurezza subito dopo il rilascio di una nuova versione anziché attendere scadenze di supporto prolungate. L'aggiornamento anticipato consente di avere più tempo per la convalida e riduce i costi di assistenza estesa.
-
Tieni presente le restrizioni relative al rollback del supporto esteso. Se il cluster è stato aggiornato automaticamente al termine del supporto esteso, non è possibile ripristinare la versione precedente. Se hai ricevuto l'aggiornamento automatico al termine del supporto standard, puoi eseguire il rollback, ma devi prima modificare la politica di aggiornamento in.
EXTENDED
Consulta le informazioni sulla preparazione al rollback prima di eseguire il rollback
Amazon EKS offre informazioni sulla preparazione al rollback point-in-time ROLLBACK_READINESS nella categoria Cluster Insights. Questi controlli sono lo strumento principale per valutare la sicurezza del rollback.
-
Consulta gli approfondimenti subito dopo l'aggiornamento. Non aspettare che qualcosa vada storto. Dopo l'aggiornamento, consulta le informazioni sulla preparazione al rollback in modo da conoscere la tua attuale posizione in materia di rollback.
-
Risolvi le informazioni sugli ERRORI in modo proattivo. Se gli approfondimenti mostrano lo stato di ERRORE poco dopo un aggiornamento, risolvili in anticipo, quando la finestra di 7 giorni è ancora aperta. Più aspettate, più è probabile che lo stato del cluster diverga e che compaiano nuovi blocchi.
-
Scopri cosa coprono e cosa non coprono gli approfondimenti. Insights verifica le versioni dei componenti aggiuntivi gestiti da Amazon EKS, l'utilizzo delle API, l'inclinazione delle versioni e lo stato del cluster. Non controllano i componenti aggiuntivi autogestiti, i controller personalizzati o la compatibilità a livello di applicazione. Mantieni la tua convalida della compatibilità per i componenti aggiuntivi autogestiti (ad esempio, cluster-autoscaler, ingress controller, operatori personalizzati, agenti di monitoraggio).
Prepara i nodi in modalità non automatica per il rollback
Per i cluster che utilizzano gruppi di nodi gestiti, nodi autogestiti o AWS Fargate, sei responsabile di garantire che i nodi di lavoro siano compatibili con la versione di rollback di destinazione.
-
Gruppi di nodi gestiti. È necessario ripristinare i gruppi di nodi gestiti alla versione precedente prima di ripristinare il piano di controllo. Usa l'
UpdateNodegroupVersionoperazione con la versione precedente di Kubernetes. Il rollback rispetta le impostazioni di aggiornamento configurate (maxUnavailablestrategia di aggiornamento). -
Self-managed e nodi ibridi. Aggiorna le AMI o le configurazioni del nodo per utilizzare la versione precedente di Kubernetes prima di ripristinare il piano di controllo.
-
Fargate. Il rollback della versione non è supportato per i nodi di lavoro Fargate. Eliminate i pod Fargate che eseguono la stessa versione del piano di controllo prima di iniziare il rollback o usateli
--forceper bypassare la versione skew insight (che potrebbe causare un comportamento imprevisto fino alla sostituzione dei pod).
Gestisci i controlli delle interruzioni in modalità automatica di Amazon EKS per il rollback
Per i cluster che eseguono Amazon EKS Auto Mode, la fase di rollback del nodo può essere la parte più lunga dell'operazione. I controlli sulle interruzioni determinano direttamente la velocità di completamento del rollback.
-
Esamina i budget relativi alle interruzioni prima di iniziare il rollback. Amazon EKS fornisce informazioni sulla preparazione al rollback per i budget relativi alle NodePool interruzioni. I budget impostati su 0 attivano una analisi ERROR, che blocca il rollback a tempo indeterminato. Budget e PodDisruptionBudgets (PDB) restrittivi attivano WARNING Insights, che possono rallentare il rollback ma consentire progressi futuri. Risolvi gli approfondimenti ERROR prima di iniziare il rollback.
-
Preparati a modificare i budget durante il rollback. Se il rollback richiede più tempo del previsto, puoi modificare i budget e i PDB relativi alle NodePool interruzioni mentre è in corso il
kubectlrollback. L'aumento del budget consente la sostituzione simultanea di più nodi. -
Rimuovi le annotazioni da non interrompere dai nodi di blocco. L'
karpenter.sh/do-not-disruptannotazione sui nodi blocca il rollback a tempo indeterminato. Rimuovila dai nodi che devono essere sostituiti. -
Tieni traccia dell'avanzamento del rollback del nodo.
kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wideDa utilizzare per monitorare quali nodi sono stati sostituiti con l'AMI della versione precedente. -
Utilizzare CancelUpdate se necessario. Se il rollback impiega troppo tempo o causa più problemi di quanti ne risolva, annulla il rollback. Dopo l'annullamento, i nodi convergono alla versione corrente e puoi adottare un approccio diverso.
-
Imposta un timeout appropriato. Utilizzate il
timeoutMinutesparametro inrollbackConfigper allinearvi alle vostre aspettative operative. L'impostazione predefinita è 720 minuti (12 ore). Per i cluster con budget moderati, valuta la possibilità di aumentarlo. Per IaC-managed i cluster, esegui l'allineamento al timeout dello strumento.
Per le procedure complete di rollback in modalità automatica e il relativo CancelUpdate funzionamento, consulta Ripristino dei cluster Amazon EKS Auto Mode.
Monitora l'avanzamento del rollback
Durante un rollback, utilizza quanto segue per tenere traccia dello stato e rilevare i problemi:
-
DescribeUpdate operazione. Utilizzare
describe-updateper controllare lo stato corrente dell'operazione di rollback (InProgress,,SuccessfulFailed,Cancelled). Per tenere traccia dell'avanzamento dell'annullamento, controllate l'cancellationoggetto nella risposta. -
Approfondimenti sui cluster. Amazon EKS ricontrolla le informazioni prima di procedere con il rollback del piano di controllo (dopo il completamento del rollback del nodo per la modalità Auto). Monitora eventuali nuove informazioni sugli ERROR che potrebbero essere apparse.
-
Stato del cluster. Per i cluster in modalità automatica, lo stato del cluster rimane
ACTIVEdurante il rollback del nodo e cambiaUPDATINGsolo durante il rollback del piano di controllo. Non fare affidamento esclusivamente sullo stato del cluster per sapere che è in corso un rollback: usalo.DescribeUpdate -
Versioni dei nodi. Per la modalità automatica, controlla le versioni di Kubernetes del nodo per tenere traccia dell'avanzamento della sostituzione dei nodi. Per i gruppi di nodi gestiti, monitora lo stato di aggiornamento del gruppo di nodi.
Gestisci i cluster gestiti da Infrastructure as Code (IaC)
Gli strumenti Infrastructure as code (IaC) presentano limitazioni di timeout che potrebbero entrare in conflitto con la durata del rollback in modalità automatica.
-
AWS CloudFormation supporta fino a 36 ore per risorsa. Se il rollback supera questo limite, lo CloudFormation considera come un no-op, il che può lasciare il cluster in uno stato diverso in cui il modello non riflette la versione effettiva del cluster. Il timeout di rollback predefinito è di 720 minuti (12 ore).
-
Terraform Enterprise/Cloud ha dei timeout di circa 24 ore, anche se i timeout lato client variano.
-
Allinea
timeoutMinutesil timeout del tuo strumento IAc per evitare che lo strumento IAc scada prima che Amazon EKS completi il rollback. -
Prendi in considerazione l'idea di avviare il rollback CLI/API per i cluster in modalità Auto con budget restrittivi, anziché tramite IAc. Utilizzalo
CancelUpdatedirettamente in caso di timeout del livello IAc. -
Il rollback CloudFormation dello stack AWS non attiva il rollback della versione. Se un aggiornamento CloudFormation dello stack AWS fallisce, il ripristino automatico dello stack a una versione precedente del modello non avvia un rollback della versione del cluster. È necessario avviare esplicitamente un rollback della versione.
Utilizzate il rollback come rete di sicurezza, non come flusso di lavoro di routine
Il rollback della versione è progettato per aiutarti a risolvere i problemi successivi all'aggiornamento. Funziona al meglio se combinato con le pratiche di aggiornamento esistenti.
-
Il rollback integra i test, non li sostituisce. Continua a utilizzare Cluster Insights, i test di pre-aggiornamento in ambienti non di produzione e le implementazioni in fasi. Rollback gestisce i casi che i test non riescono a rilevare, i problemi che emergono solo durante la produzione.
-
Il rollback riduce la necessità di procedure manuali di backup e istantanee come meccanismo di sicurezza principale. Con il rollback nativo disponibile, non è più necessario affidarsi esclusivamente alle istantanee etcd o agli script di rollback personalizzati per il disaster recovery durante gli aggiornamenti.
-
Gli approfondimenti richiedono la massima efficienza e sono puntuali. Amazon EKS li valuta quando attivi il rollback. Le modifiche apportate dopo tale controllo (ad esempio, la creazione di risorse con nuove API) non vengono acquisite e potrebbero causare problemi una volta completato il rollback.
-
Il rollback non garantisce il ripristino dell'applicazione. Amazon EKS ripristina il piano di controllo in modo sicuro, ma è tua responsabilità eseguire la convalida rispetto alla versione precedente delle applicazioni, configurazioni e dipendenze.
Il rollback riduce la necessità di aggiornamenti blu-verdi
Organizations che in precedenza utilizzavano gli aggiornamenti blu-green dei cluster principalmente per disporre di un «percorso di ripristino» possono ora prendere in considerazione gli aggiornamenti sul posto con il rollback della versione come alternativa. In-place gli aggiornamenti con rollback offrono costi di infrastruttura inferiori (nessun cluster duplicato), identità del cluster coerente (stesso endpoint API, provider OpenID Connect (OIDC) e interfacce di rete elastiche (ENI)) e operazioni più semplici.
Blue-green potrebbero comunque essere la soluzione preferita quando è necessario modificare più versioni contemporaneamente, testare in modo approfondito le migrazioni dei carichi di lavoro o mantenere il completo isolamento del traffico durante la convalida. Per ulteriori informazioni, consulta Evaluate Clusters nelle best practice per gli aggiornamenti del Blue/Green cluster.
Risorse correlate
