Funzionamento degli aggiornamenti del cluster del servizio Azure Kubernetes

Servizio Azure Kubernetes (AKS) esegue aggiornamenti in sequenza per ridurre al minimo le interruzioni ai carichi di lavoro in esecuzione.

Per la maggior parte dei carichi di lavoro di produzione, AKS Automatic è la scelta predefinita consigliata, ove applicabile. AKS Automatic include configurazioni predefinite idonee per l'ambiente di produzione per le operazioni di aggiornamento, ad esempio aggiornamenti automatici delle versioni di Kubernetes, aggiornamenti automatici delle immagini del sistema operativo (OS), operazioni gestite dei nodi di sistema e meccanismi di protezione integrati che riducono l'intervento manuale. Per altre informazioni, vedere Introduzione ad AKS Automatic.

Questo articolo illustra i meccanismi di aggiornamento del servizio Azure Kubernetes ed evidenzia la differenza tra il servizio Azure Kubernetes Automatic e AKS Standard.

Prerequisiti

Modello di aggiornamento: AKS Automatic e AKS Standard

Le modalità del cluster AKS Automatic e AKS Standard usano gli stessi concetti fondamentali per l'aggiornamento di Kubernetes, ma differiscono in base alle impostazioni predefinite e alla proprietà operativa.

Problema di aggiornamento AKS Automatico Servizio Azure Kubernetes Standard
Posizionamento di produzione Impostazione predefinita consigliata per la maggior parte dei carichi di lavoro di produzione, se applicabile Modello flessibile con una configurazione più manuale per impostazione predefinita
Aggiornamenti delle versioni secondarie di Kubernetes Canale di aggiornamento automatico preconfigurato Manuale per impostazione predefinita, canale automatico facoltativo
Aggiornamenti delle immagini del sistema operativo del nodo Canale immagine del sistema operativo del nodo automatico preconfigurato Manuale per impostazione predefinita, canale automatico facoltativo
Operazioni del pool di nodi di sistema Gestito da AKS Gestito dal cliente
Finestre di manutenzione pianificata Disponibile per impostazione predefinita Configurazione facoltativa
Controlli di interruzione del carico di lavoro Di proprietà del cliente, inclusi strategia di replica, comportamento di disponibilità e criteri relativi alle interruzioni Di proprietà del cliente, inclusi strategia di replica, comportamento di disponibilità e criteri relativi alle interruzioni

Note

AKS Automatic semplifica le operazioni della piattaforma, ma rimane valido il modello di responsabilità condivisa. La progettazione della disponibilità a livello di carico di lavoro e il comportamento del criterio di espulsione restano responsabilità del cliente.

Comportamento dell'aggiornamento progressivo in AKS

AKS aggiorna i pool di nodi usando una modalità progressiva che mantiene la capacità durante la sostituzione o la reimpostazione dell'immagine dei nodi. Questo comportamento è lo stesso in tutte le modalità del cluster AKS.

In linea generale, AKS:

  1. Aggiunge capacità di aumento temporaneo in base alle impostazioni di aggiornamento.
  2. Isola e svuota i nodi per spostare i carichi di lavoro.
  3. Ricrea l'immagine o sostituisce i nodi nella versione di destinazione.
  4. Rimuove la capacità di picco temporanea dopo il completamento.

Esempio di aggiornamento in sequenza

Questo esempio illustra l'aggiornamento di un cluster a due nodi da Kubernetes 1.30 a 1.31 con maxSurge impostato su 1.

Passaggio 1: Configurazione iniziale

Il cluster inizia con due nodi che eseguono la versione 1.30, ognuno dei quali ospita i pod dell'applicazione.

Diagramma che mostra la configurazione iniziale del cluster con due nodi che eseguono la versione 1.30, ogni pod dell'applicazione che ospita e un nodo Surge appena creato.

  • Nodo 1: Pod A, Pod B
  • Nodo 2: Pod C, Pod D
  • Nodo surge: vuoto (ad eccezione di DaemonSet e nuovi pod)

Passaggio 2: Isolare e poi svuotare il primo nodo

AKS blocca il nodo 1 per impedire la pianificazione di nuovi pod, quindi draina i pod esistenti.

Diagramma che mostra che il nodo 1 viene bloccato e svuotato, con i pod rimossi e sostituiti in altri nodi disponibili.

  • Pod A → rimosso e sostituito nel nodo Surge
  • Pod B → rimosso e sostituito nel nodo 2

Passaggio 3: Aggiornare il primo nodo

Il nodo 1 viene ricreato con Kubernetes versione 1.31 mentre i pods continuano a funzionare sugli altri nodi.

Diagramma che mostra Node 1 reimpostato con l'immagine alla versione 1.31 mentre i pod dell'applicazione continuano a essere eseguiti su Node 2 e sul Surge Node.

  • Nodo 1: aggiornato alla versione 1.31
  • Nodo 2: Pod B, Pod C, Pod D
  • Nodo Surge: Pod A

Passaggio 4: Isolare e drenare il secondo nodo

AKS ripete il processo per Nodo 2, i pod vengono rimossi e lo schedulatore li ridistribuisce ai nodi disponibili più idonei.

Diagramma che mostra che il nodo 2 viene bloccato e svuotato, con pod rimossi e sostituiti nel nodo 1 aggiornato e nel nodo Surge.

  • Pod C, B → rimosso e sostituito nel nodo 1
  • Pod D → rimosso e sostituito nel nodo Surge
  • Nodo 2: Isolato e reinstallato alla versione 1.31

Passaggio 5: Rimuovere il nodo di picco

Dopo l'aggiornamento di tutti i nodi permanenti, il nodo Surge viene bloccato, svuotato ed eliminato.

Diagramma che mostra il nodo Surge in fase di svuotamento ed eliminazione, con pod rimossi e sostituiti nei nodi permanenti aggiornati.

  • Pod A → rimosso e sostituito nel nodo 1
  • Pod D → rimosso e sostituito nel nodo 2
  • Nodo surge: eliminato

Stato finale

Tutti i nodi eseguono ora Kubernetes versione 1.31 con pod schedulati nel cluster.

  • Nodo 1 (v1.31): Pod A, Pod C
  • Nodo 2 (v1.31): Pod B, Pod D

Comportamento restrittivo del Pod Disruption Budget (PDB)

Se un PDB restrittivo blocca l'eliminazione, lo svuotamento dei nodi può essere ritardato o impedito. AKS può usare il comportamento del nodo non svuotabile Cordon per continuare ad aggiornare altri nodi idonei, a seconda del comportamento configurato. I nodi bloccati potrebbero rimanere in una versione precedente fino a quando non viene risolta la condizione di blocco.

Esempio di PDB restrittivo

Questo esempio mostra l'aggiornamento di un cluster a due nodi da Kubernetes 1.30 a 1.31 con maxSurge impostato su 2 e un PDB che blocca l'operazione di svuotamento del primo nodo.

Passaggio 1: Configurazione iniziale con PDB restrittivo

Il cluster inizia con due nodi che eseguono la versione 1.30, con un PDB che protegge pod A dalla rimozione.

Diagramma che mostra il cluster iniziale con due nodi, un nodo di surge e un Pod Disruption Budget che protegge il Pod A dall'espulsione.

  • Nodo 1: Pod A (protetto da PDB), Pod B
  • Nodo 2: Pod C, Pod D
  • Nodi aggiuntivi: 2 nodi appena creati
  • PDB: impedisce l'evacuazione del Pod A

Passaggio 2: Tentare di svuotare il primo nodo (bloccato)

AKS isola il nodo 1, ma non riesce a drenare il pod A a causa dei vincoli del PDB.

Diagramma che mostra il Nodo 1 isolato ma con il drain bloccato dal Pod Disruption Budget, con il Pod A bloccato e il Pod B sfrattato sul nodo Surge.

  • Nodo 1: isolato e contrassegnato come in quarantena (pod A bloccato)
  • Pod B → Espulso e sostituito sul Nodo Surge 1, mentre il Nodo Surge 2 non viene utilizzato temporaneamente
  • Stato: Aggiornamento del nodo 1 bloccato

Passaggio 3: Procedere al secondo nodo

Con il nodo 1 messo in quarantena, AKS continua ad aggiornare il nodo 2.

Diagramma che mostra il nodo 1 rimasto in quarantena mentre il nodo 2 viene bloccato e svuotato correttamente, con i pod spostati nel nodo Surge.

  • Nodo 1: rimane in quarantena (v1.30)
  • Nodo 2: isolato e svuotato correttamente
  • Pod C → rimosso e sostituito su Surge Node 2
  • Pod D → rimosso e sostituito nel nodo Surge 2

Passaggio 4: Aggiornare il secondo nodo

Il nodo 2 è stato reimpostato correttamente alla versione 1.31 di Kubernetes.

Diagramma che mostra che il nodo 2 è stato aggiornato correttamente alla versione 1.31 mentre il nodo 1 rimane in quarantena con pod A.

  • Nodo 1: ancora in quarantena (v1.30) con Pod A
  • Nodo 2: aggiornato alla versione 1.31
  • Nodo Surge 1: Pod B
  • Surge Nodo 2: Pod C, Pod D

Passaggio 5: un nodo Surge diventa il sostituto permanente mentre un altro nodo viene rimosso

Poiché il nodo 1 rimane in quarantena, il nodo surge 1 diventa il sostituto permanente che esegue la versione 1.31 e il nodo surge 2 viene eliminato.

Diagramma che mostra che il nodo Surge diventa una sostituzione permanente che esegue la versione 1.31 mentre il nodo 1 rimane in quarantena.

  • Nodo 1: In quarantena (v1.30) - richiede l'intervento manuale
  • Pod C, Pod D → espulsi dal nodo Surge 2 e sostituiti su Node 2
  • Surge Node 1 (v1.31): Pod B (now permanent)
  • Nodo di picco 2 (v1.31): eliminato

Stato finale

L'aggiornamento viene completato con un nodo in quarantena che richiede l'intervento manuale.

  • Nodo 1: messo in quarantena (v1.30) con pod A - Il cliente deve risolvere manualmente (vedere Risolvere i nodi non restrittivi)
  • Nodo 2 (v1.31): in esecuzione normalmente
  • Precedente nodo Surge (v1.31): Ora sostituito permanentemente

Importante

Il nodo in quarantena (nodo 1) rimane la responsabilità del cliente di gestire. È necessario:

  • Modificare il PDB per consentire la rimozione del pod A.
  • Eliminare manualmente il pod A.
  • Eliminare e ricreare il nodo dopo aver corretto la condizione di blocco.

Considerazioni principali per gli aggiornamenti bloccati da PDB

  • Comportamento del nodo non restrittivo: impostare su Cordon per il pool di nodi per abilitare questo comportamento di quarantena.
  • Responsabilità del cliente: i nodi in quarantena richiedono l'intervento manuale per la risoluzione.
  • Capacità del cluster: il nodo di picco diventa permanente e potenzialmente influisce sulla pianificazione della capacità del cluster.
  • Monitoraggio: tenere traccia dei nodi in quarantena tramite Monitoraggio di Azure o kubectl per garantire una risoluzione tempestiva.

Suggerimento

Per evitare completamente lo scenario di quarantena, è possibile usare la gestione PDB automatica per aumentare automaticamente le repliche di distribuzione in modo che i vincoli PDB vengano soddisfatti prima dell'inizio dello svuotamento. Ciò consente alla rimozione di procedere senza blocchi, eliminando la necessità di una gestione manuale della quarantena.

Blue-Green aggiornamenti del pool di nodi (controllo manuale)

Blue-Green gli aggiornamenti offrono un approccio di aggiornamento più controllato creando manualmente un set completo di nuovi pool di nodi prima della migrazione dei carichi di lavoro. Questo approccio manuale consente di controllare completamente il processo di aggiornamento e la tempistica.

Per altre informazioni, vedi Aggiornamenti Blue-Green del pool di nodi in AKS.

Quando usare gli aggiornamenti Blue-Green

Gli aggiornamenti manuali Blue-Green dei pool di nodi sono una strategia avanzata per esigenze specifiche, come punti di controllo espliciti della migrazione, controlli di validazione personalizzati o transizioni strettamente controllate.

Usare Blue-Green manuale quando è necessario:

  • Fasi di migrazione controllate dall'operatore.
  • Criteri di convalida e accettazione personalizzati prima del commit.
  • Coreografia di rollback esplicita legata ai runbook interni.

Per la maggior parte dei carichi di lavoro di produzione, laddove applicabile, il comportamento predefinito degli aggiornamenti di AKS Automatic rappresenta il punto di partenza preferibile, mentre il Blue-Green manuale è in genere riservato a casi eccezionali.

Concetti chiave

  • Pool di nodi blu: il pool di nodi esistente che esegue la versione corrente di Kubernetes.
  • Pool di nodi verdi: nuovo pool di nodi creato eseguendo la versione di Kubernetes di destinazione.
  • Controllo manuale: è possibile gestire tutti gli aspetti del processo di migrazione.
  • Punti di controllo della convalida: decidi quando procedere, mettere in pausa o eseguire il rollback.

Vantaggi degli aggiornamenti di Blue-Green

  • Controllo completo: si decide esattamente quando si verifica ogni passaggio.
  • Convalida personalizzata: implementare criteri di convalida e tempi personalizzati.
  • Migrazione graduale: spostare i carichi di lavoro al ritmo preferito.
  • Ripristino semplice: i nodi originali rimangono disponibili finché non li elimini.

Considerazioni principali per gli aggiornamenti di Blue-Green

  • Lavoro manuale: richiede la gestione attiva durante tutto il processo.
  • Requisiti di quota: richiede 2 volte la capacità del nodo durante l'aggiornamento.
  • Pianificazione: documentare i criteri di convalida e le procedure di rollback.

Esempio di processo di aggiornamento manuale Blue-Green

Questo esempio illustra l'aggiornamento manuale di un cluster a due nodi da Kubernetes 1.30 a 1.31 usando la distribuzione Blue-Green.

Passaggio 1: Creare un pool di nodi verdi

Per iniziare, creare manualmente un nuovo pool di nodi con la versione di Kubernetes di destinazione insieme al pool di nodi esistente.

Diagramma che mostra Blue-Green configurazione iniziale con il pool di nodi Blu che esegue la versione 1.30 e il pool di nodi Verde appena creato che esegue la versione 1.31.

  • Pool di nodi blu (v1.30): Pod A, Pod B, Pod C, Pod D (esistenti)
  • Pool di nodi verdi (v1.31): vuoto (creato manualmente dall'utente)
  • Azione: az aks nodepool add con la nuova versione di Kubernetes

Passaggio 2: Isolare manualmente i nodi blu

Bloccare i nodi blu per impedire la pianificazione di nuovi pod mantenendo i pod esistenti in esecuzione.

  • La tua azione: kubectl cordon in ogni nodo blu
  • Nodi blu: Bloccati, nessun nuovo pod pianificato
  • Nodi verdi: pronti per ricevere i carichi di lavoro

Passaggio 3: Svuotare manualmente i nodi blu (ritmo controllato)

È possibile controllare il ritmo della migrazione svuotando manualmente i nodi uno alla volta o in batch.

Diagramma che mostra lo svuotamento del nodo Blu con pod rimossi e sostituiti nel pool di nodi Verdi e il secondo nodo Blu che viene svuotato con i pod rimanenti migrati al pool di nodi Verde.

  • Azione: kubectl drain nei nodi blu selezionati
  • Migrazione dei pod: i pod vengono automaticamente riprogrammati sui nodi verdi
  • Convalida: verificare i carichi di lavoro nei nodi verdi prima di procedere

Passaggio 4: Convalidare e decidere

Dopo la migrazione dei carichi di lavoro, convalidare le prestazioni dell'applicazione nei nodi verdi.

Diagramma che mostra la fase di convalida con tutti i carichi di lavoro in esecuzione nel pool di nodi verdi, mentre il pool di nodi Blu rimane disponibile per il rollback.

Durante questa fase, è possibile:

  • Monitoraggio: controllare le metriche e i log dell'applicazione
  • Test: eseguire test di convalida nel pool di nodi verdi
  • Decidere: eseguire il commit a verde o eseguire il rollback a blu

Passaggio 5: eseguire il commit o il rollback

In base alla convalida, è possibile completare manualmente l'aggiornamento o il rollback.

Opzione A - Conferma (operazione completata con successo):

Diagramma che mostra il commit con esito positivo con il pool di nodi Blu eliminato e il pool di nodi verdi diventa il pool di nodi primario.

  • Azione: Eliminare il pool di nodi blu usando az aks nodepool delete
  • Risultato: il pool di nodi verdi diventa primario

Opzione B - Eseguire il rollback (rilevati problemi):

Diagramma che mostra il rollback, con i carichi di lavoro che tornano al pool di nodi Blue mentre il pool di nodi Green viene eliminato.

  • Azione richiesta: rimuovere il cordon dai nodi blu usando kubectl uncordon, svuotare i nodi verdi usando kubectl drain, ed eliminare il pool di nodi verdi usando az aks nodepool delete
  • Risultato: i carichi di lavoro tornano ai nodi Blu

Considerazioni sulla produzione per la pianificazione dell'aggiornamento

  • Configurazione di picco (maxSurge): controlla il numero di nodi di picco creati durante gli aggiornamenti. I valori più elevati velocizzano gli aggiornamenti, ma utilizzano più risorse.
  • Budget di interruzione per i pod (PDB): configurare i PDB per garantire la disponibilità delle applicazioni durante il processo di aggiornamento.
  • Aggiornamenti del pool di nodi: ogni pool di nodi si aggiorna in modo indipendente. Pianificare di conseguenza la strategia di aggiornamento.
  • Capacità e quota: convalidare i requisiti di capacità temporanea e stabile prima delle finestre di aggiornamento.
  • Monitoraggio e avvisi: configurare il monitoraggio e gli avvisi prima dell'avvio dell'aggiornamento.

In AKS Automatic, diverse opzioni di aggiornamento a livello di piattaforma sono preconfigurate per l'uso in produzione. In AKS Standard, i team in genere effettuano queste scelte in modo esplicito.

Contenuti correlati

  • Last updated on