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 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 la pianificazione, l'esecuzione e l'operatività del rollback come parte del flusso di lavoro di aggiornamento.
Per i dettagli sui prerequisiti, le procedure dettagliate e i riferimenti alle API, vedi Rollback cluster alla versione precedente di Kubernetes. https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html
Scopri come il modello di responsabilità condivisa si applica al rollback
Quando avvii il rollback di una versione del cluster, Amazon EKS gestisce il rollback del piano di controllo. Sei responsabile del piano dati, dei componenti aggiuntivi e della compatibilità delle applicazioni. Di seguito vengono descritte le responsabilità:
-
Amazon EKS gestisce: Ripristino del server 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: ripristino dei gruppi di nodi gestiti, dei nodi autogestiti e dei 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, vedi Comprendere come il modello di responsabilità condivisa si applica agli aggiornamenti dei cluster.
Pianifica gli aggiornamenti pensando al rollback
Il rollback della versione funziona meglio quando il flusso di lavoro di aggiornamento è progettato per 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, valuta la possibilità di aggiornare prima il piano di controllo e di concedere un periodo di attesa prima di aggiornare i nodi di lavoro. Mentre i nodi rimangono attivi N-1, lo stato di skew insight della versione kubelet rimane PASSING. Ciò mantiene chiaro il percorso di rollback senza dover prima ripristinare i nodi.
-
Aggiorna i componenti aggiuntivi a versioni intercompatibili. Prima di aggiornare il piano di controllo, assicurati che tutti i componenti aggiuntivi (gestiti e autogestiti) siano compatibili sia con la versione corrente che con 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 da Amazon EKS per trarre vantaggio dalle informazioni sulla disponibilità al rollback che verificano automaticamente la compatibilità delle versioni dei componenti aggiuntivi.
-
Evita la gestione automatica di un componente aggiuntivo gestito (ad esempio, sovrascrivendo la versione al di fuori del ciclo di vita del componente aggiuntivo EKS). Durante il rollback, gli approfondimenti considerano la configurazione gestita del componente aggiuntivo come fonte di verità e non rilevano le variazioni di versione introdotte.
-
-
Evita di utilizzare API specifiche della versione durante il periodo di attesa. Se crei risorse che utilizzano API o funzionalità disponibili solo nella nuova versione durante la finestra di 7 giorni, devi rimuoverle prima del 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 prolungate per il supporto. L'aggiornamento anticipato ti dà 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 puoi tornare alla versione precedente. Se hai effettuato l'upgrade automatico al termine del supporto standard, puoi eseguire il rollback, ma devi prima modificare la politica di aggiornamento in.
EXTENDED
Per indicazioni generali sulla pianificazione degli aggiornamenti, comprese le politiche di deprecazione, le note di rilascio e la compatibilità dei componenti aggiuntivi, consulta Best Practices for Cluster Upgrades.
Rivedi le informazioni sulla preparazione al rollback prima di eseguire il rollback
Amazon EKS fornisce informazioni sulla preparazione al rollback point-in-time nella categoria Cluster Insights. ROLLBACK_READINESS Questi controlli sono lo strumento principale per valutare la sicurezza del rollback.
-
Rivedi gli approfondimenti subito dopo l'aggiornamento. Non aspettate che qualcosa vada storto. Dopo l'aggiornamento, controlla le informazioni sulla preparazione al rollback in modo da conoscere la tua attuale posizione di rollback.
-
Gestisci le informazioni sugli ERRORI in modo proattivo. Se gli approfondimenti mostrano lo stato di ERRORE subito dopo un aggiornamento, risolvili in anticipo mentre la finestra di 7 giorni è ancora aperta. Più aspetti, più è probabile che lo stato del cluster diverga e compaiano nuovi blocchi.
-
Scopri cosa coprono e cosa non riguardano gli approfondimenti. Gli approfondimenti controllano le versioni dei componenti aggiuntivi gestiti da Amazon EKS, l'utilizzo delle API, la distorsione 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, controller di ingresso, operatori personalizzati, agenti di monitoraggio).
Per l'elenco completo dei controlli approfonditi e del comportamento dello stato, vedi Rollback cluster alla versione precedente di Kubernetes. https://docs.aws.amazon.com/eks/latest/userguide/rollback-cluster.html
Prepara i nodi in modalità non automatica per il rollback
Per i cluster che utilizzano Managed Node Groups, 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 (maxUnavailable, strategia di aggiornamento). -
Self-managed e nodi ibridi. Aggiorna le AMI o le configurazioni del tuo 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. Elimina i pod Fargate che eseguono la stessa versione del piano di controllo prima di iniziare il rollback, oppure usali
--forceper bypassare le informazioni sullo skew insight della versione (il che potrebbe comportare un comportamento imprevisto fino alla sostituzione dei pod).
Per informazioni sulla configurazione PodDisruptionBudget e sulla distribuzione della topologia per garantire la disponibilità del carico di lavoro durante gli aggiornamenti dei nodi, consulta Best Practices for Cluster Upgrade. Procedure consigliate per gli aggiornamenti dei cluster
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.
-
Rivedi i budget per le interruzioni prima di avviare il rollback. Amazon EKS fornisce informazioni sulla preparazione al rollback per i budget relativi alle NodePool interruzioni. I budget impostati su 0 generano una visualizzazione ERROR, che blocca il rollback a tempo indeterminato. I budget restrittivi e PodDisruptionBudgets (PDB) attivano informazioni di AVVISO, che possono rallentare il rollback ma consentire progressi in avanti. Risolvi le informazioni relative agli ERRORI prima di avviare il rollback.
-
Preparati a modificare i budget durante il rollback. Se il rollback richiede più tempo del previsto, puoi modificare i budget per le NodePool interruzioni e i PDB
kubectlmentre il rollback è in corso. L'aumento del budget consente di effettuare più sostituzioni simultanee dei nodi. -
Rimuovi le annotazioni «Do-Not-Disrupt» dai nodi bloccanti. L'
karpenter.sh/do-not-disruptannotazione sui nodi blocca il rollback a tempo indeterminato. Rimuoverla dai nodi che devono essere sostituiti. -
Tieni traccia dell'avanzamento del rollback dei nodi.
kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wideUtilizzato per monitorare quali nodi sono stati sostituiti con la versione precedente dell'AMI. -
Usare CancelUpdate se necessario. Se il rollback richiede troppo tempo o causa più problemi di quanti ne risolva, annulla il rollback. Dopo l'annullamento, i nodi tornano 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 ridotti, valuta la possibilità di aumentarlo. Per IaC-managed i cluster, allineati al timeout dello strumento.
Per le procedure complete di rollback in modalità automatica e il CancelUpdate funzionamento, consulta Ripristinare i 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.
describe-updateDa utilizzare per verificare lo stato corrente dell'operazione di rollback (InProgress,,SuccessfulFailed,Cancelled). Per tenere traccia dell'avanzamento dell'annullamento, controlla 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à automatica). Monitora le nuove informazioni sugli ERRORI che potrebbero essere apparse.
-
Stato del cluster. Per i cluster in modalità automatica, lo stato del cluster rimane
ACTIVEdurante il rollback del nodo e passaUPDATINGsolo durante il rollback del piano di controllo. Non fare affidamento esclusivamente sullo stato del cluster per sapere se è in corsoDescribeUpdateun rollback: usalo. -
Versioni dei nodi. Per la modalità automatica, controlla le versioni Kubernetes del nodo per tenere traccia dell'avanzamento della sostituzione del nodo. Per i gruppi di nodi gestiti, monitora lo stato di aggiornamento del gruppo di nodi.
Gestisci l'infrastruttura come cluster gestiti da codice (IaC)
Gli strumenti Infrastructure as code (IaC) presentano limitazioni di timeout che potrebbero entrare in conflitto con la durata del rollback della modalità automatica.
-
AWS CloudFormation supporta fino a 36 ore per risorsa. Se il rollback supera questo limite, lo CloudFormation considera 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 sul lato client variano.
-
timeoutMinutesAllineati al timeout dello strumento IaC per evitare che lo strumento IaC scada prima che Amazon EKS completi il rollback. -
Prendi in considerazione la possibilità di avviare il rollback CLI/API per i cluster in modalità automatica con budget restrittivi, anziché tramite IaC. Usalo
CancelUpdatedirettamente se il livello IaC scade. -
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 il rollback della versione del cluster. È necessario avviare esplicitamente un rollback della versione.
Usa 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 le informazioni sui cluster, i test di pre-aggiornamento in ambienti non di produzione e le implementazioni graduali. Rollback gestisce i casi che i test non riescono a rilevare, ovvero i problemi che emergono solo in fase di produzione.
-
Il rollback riduce la necessità di procedure manuali di backup e snapshot 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 sono la cosa migliore da fare e sono puntuali. Amazon EKS li valuta quando si attiva 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 delle applicazioni. Amazon EKS ripristina il piano di controllo in modo sicuro, ma è tua responsabilità convalidare le applicazioni, le configurazioni e le dipendenze rispetto alla versione precedente.
Il rollback riduce la necessità di aggiornamenti blu-verdi
Le organizzazioni che in precedenza utilizzavano gli aggiornamenti dei cluster blu-verdi principalmente per avere 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 preferibili quando è necessario modificare più versioni contemporaneamente, testare ampiamente le migrazioni dei carichi di lavoro o mantenere il completo isolamento del traffico durante la convalida. Per ulteriori informazioni, consulta Evaluate Clusters nelle Blue/Green best practice per gli aggiornamenti dei cluster.
Risorse correlate
