Aggiornare le immagini kubernetes e dei nodi in più cluster membri

Articolo
11/05/2024

Gli amministratori della piattaforma che gestiscono un numero elevato di cluster spesso presentano problemi con la gestione temporanea degli aggiornamenti di più cluster (ad esempio, l'aggiornamento dell'immagine del sistema operativo del nodo o le versioni di Kubernetes) in modo sicuro e prevedibile. Per risolvere questa sfida, Azure Kubernetes Fleet Manager (Fleet) consente di orchestrare gli aggiornamenti in più cluster usando le esecuzioni degli aggiornamenti.

Le esecuzioni degli aggiornamenti sono costituite da fasi, gruppi e strategie e possono essere applicate manualmente, per gli aggiornamenti occasionali o automaticamente, per gli aggiornamenti regolari continui usando profili di aggiornamento automatico. Tutte le esecuzioni di aggiornamento (manuale o automatizzato) rispettano le finestre di manutenzione del cluster membro.

Informazioni sulle esecuzioni degli aggiornamenti

L'immagine seguente visualizza un'esecuzione di aggiornamento contenente due fasi di aggiornamento, ognuna contenente due gruppi di aggiornamento con due cluster membri. Tra le prime e le seconde fasi viene configurato un periodo di attesa.

Esecuzione dell'aggiornamento: l'esecuzione di aggiornamento rappresenta un aggiornamento applicato a una raccolta di cluster del servizio Azure Kubernetes (AKS), costituito dall'obiettivo e dalla sequenza di aggiornamento. L'obiettivo di aggiornamento descrive gli aggiornamenti desiderati (come ad esempio l'aggiornamento a Kubernetes versione 1.28.3). La sequenza di aggiornamento descrive l'ordine esatto per applicare l'aggiornamento a più cluster membri, espressi usando fasi e gruppi. Se non specificato, tutti i cluster membri vengono aggiornati uno per uno in sequenza. L'esecuzione di aggiornamento può essere arrestata e avviata.
Fase di aggiornamento: le esecuzioni degli aggiornamenti sono suddivise in fasi, che vengono applicate in sequenza. Ad esempio, una prima fase di aggiornamento potrebbe aggiornare i cluster membri dell'ambiente di test e una seconda fase di aggiornamento aggiornerebbe successivamente i cluster membri dell'ambiente di produzione. È possibile specificare un tempo di attesa per ritardare l'applicazione delle fasi di aggiornamento successive.
Gruppo di aggiornamento: ogni fase di aggiornamento contiene uno o più gruppi di aggiornamento, usati per selezionare i cluster membri da aggiornare. I gruppi di aggiornamento vengono usati anche per ordinare l'applicazione degli aggiornamenti ai cluster membri. All'interno di una fase di aggiornamento, gli aggiornamenti vengono applicati in parallelo a tutti i differenti gruppi di aggiornamento; all'interno di un gruppo di aggiornamento, i cluster membri vengono aggiornati in sequenza. Ogni cluster membro della flotta può far parte di un solo gruppo di aggiornamento.
Strategia di aggiornamento: una strategia di aggiornamento descrive la sequenza di aggiornamento con fasi e gruppi e consente di riutilizzare una configurazione di esecuzione degli aggiornamenti anziché definire ripetutamente la sequenza in ogni esecuzione. Una strategia di aggiornamento non include le versioni desiderate di Kubernetes o dell'immagine del nodo.

Attualmente, le operazioni di aggiornamento supportate nel cluster membro sono aggiornamenti. Esistono tre tipi di aggiornamenti tra cui scegliere:

Eseguire l’upgrade delle versioni di Kubernetes per il piano di controllo Kubernetes e i nodi (che includono l'upgrade delle immagini del nodo).
Aggiornare le versioni di Kubernetes solo per il piano di controllo dei cluster.
Eseguire l’upgrade solo delle immagini del nodo.

È possibile specificare la versione di Kubernetes di destinazione a cui eseguire l'aggiornamento, ma non è possibile specificare la versione esatta dell'immagine del nodo di destinazione. Ciò è dovuto al fatto che la versione più recente dell'immagine del nodo disponibile può variare a seconda dell'area di Azure del cluster (per altre informazioni, vedere lo strumento di rilevamento delle versioni del servizio Azure Kubernetes ).

Le versioni dell'immagine del nodo di destinazione vengono selezionate automaticamente in base alle preferenze:

Latest: usare le immagini dei nodi più recenti disponibili nell'area di Azure di un cluster all'avvio dell'aggiornamento del cluster. Di conseguenza, è possibile usare versioni di immagini diverse a seconda dell'area di Azure in cui si trova un cluster e all'avvio effettivo dell'aggiornamento.
Consistent: all'avvio dell'esecuzione dell'aggiornamento, seleziona le versioni più recenti delle immagini comuni nelle aree di Azure dei cluster membri in questa esecuzione, in modo che le stesse versioni delle immagini coerenti vengano usate nei cluster.

È consigliabile scegliere Latest di usare le versioni delle immagini più aggiornate, di ridurre al minimo i rischi per la sicurezza nonché scegliere di Consistent migliorare l'affidabilità usando e verificando tali immagini nei cluster nelle fasi precedenti prima di usarle nei cluster successivi.

Manutenzione pianificata

Le esecuzioni degli aggiornamenti rispettano le finestre di manutenzione pianificata impostate a livello di cluster del servizio Azure Kubernetes (AKS).

Durante l'esecuzione di un aggiornamento (per entrambe le esecuzioni di aggiornamento: uno ad uno o in fasi), la priorità all'upgrade dei cluster viene assegnata nell'ordine seguente:

Membro con una finestra di manutenzione in corso aperta.
Membro con una finestra di manutenzione aperta nelle prossime quattro ore.
Membro senza finestra di manutenzione.
Membro con una finestra di manutenzione chiusa.

Stati di esecuzione dell’aggiornamento

L'esecuzione dell’aggiornamento può essere in uno degli stati seguenti:

NotStarted: l'esecuzione dell'aggiornamento non è stata avviata.
Esecuzione: l'aggiornamento è in corso per almeno uno dei cluster membri nell'esecuzione dell'aggiornamento.
In sospeso:
- Cluster membro: un cluster membro può trovarsi nello stato in sospeso per uno dei motivi seguenti che possono essere visualizzati nel campo del messaggio.
  - La finestra di manutenzione non è aperta. Il messaggio indica l'ora di apertura successiva.
  - La versione di Kubernetes di destinazione non è ancora disponibile nell'area di Azure del membro. Un messaggio rimanda al rilevatore delle versioni in modo da poter controllare lo stato della versione in tutte le zone.
  - La versione dell'immagine del nodo di destinazione non è ancora disponibile nell'area di Azure del membro. Un messaggio rimanda al rilevatore delle versioni in modo da poter controllare lo stato della versione in tutte le zone.
- Gruppo: un gruppo è nello Pending stato se tutti i membri del gruppo sono in Pending stato o non sono avviati. Quando un membro passa a Pending, l'esecuzione dell'aggiornamento tenterà di effettuare l’upgrade del membro successivo nel gruppo. Se tutti i membri sono Pending, il gruppo passa allo Pending stato. Se un gruppo è in Pending stato, l'esecuzione dell'aggiornamento attende il completamento del gruppo prima di passare alla fase successiva per l'esecuzione.
- Fase: una fase è in Pending stato se tutti i gruppi in tale fase sono in Pending stato o non sono avviati.
- Esecuzione: un'esecuzione è nello stato Pending se la fase corrente che dovrebbe essere in esecuzione è nello stato Pending.
Ignorato: tutti i livelli di un'esecuzione di aggiornamento possono essere ignorati. Ignorare può essere avviato dal sistema o dall'utente.
- Membro:
  - È stato ignorato l'aggiornamento per un membro, un gruppo o una fase.
  - Il cluster membro è già nella versione di Kubernetes di destinazione (se la modalità di esecuzione dell'aggiornamento è Full o ControlPlaneOnly).
  - Il cluster membro si trova già nella versione di Kubernetes di destinazione e tutti i pool di nodi si trovano nella versione dell'immagine del nodo di destinazione.
  - Quando si seleziona un'immagine del nodo coerente per un'esecuzione di aggiornamento, se non è possibile trovare la versione dell'immagine di destinazione per uno dei pool di nodi, l'aggiornamento viene ignorato per tale cluster. Ad esempio, ciò può verificarsi quando viene aggiunto un nuovo pool di nodi con un nuovo SKU di macchina virtuale (VM) dopo l'avvio di un'esecuzione di aggiornamento.
- Group (Gruppo):
  - Tutti i cluster membri sono stati rilevati come Skipped dal sistema.
  - È stato avviato un salto a livello di gruppo.
- Fase:
  - Tutti i gruppi nella fase sono stati rilevati come Skipped dal sistema.
  - È stato avviato un salto a livello di fase.
- Eseguire:
  - Tutte le fasi sono state rilevate come Skipped dal sistema.
Arrestato: tutti i livelli dell’esecuzione di un aggiornamento possono essere arrestati. Esistono due possibilità per entrare in uno stato arrestato:
- Arrestare l'esecuzione dell'aggiornamento: in questo caso l'esecuzione dell'aggiornamento interrompe il rilevamento di tutte le operazioni. Se un'operazione è già stata avviata dall'esecuzione dell'aggiornamento (ad esempio, è in corso un aggiornamento del cluster), tale operazione non viene interrotta per quel singolo cluster.
- Se si verifica un errore durante l'esecuzione dell'aggiornamento ,ad esempio gli aggiornamenti non riusciti in uno dei cluster, l'intero aggiornamento viene eseguito in uno stato arrestato. Le operazioni non vengono tentate per alcun cluster successivo nell'esecuzione dell'aggiornamento.
Operazione non riuscita: un errore di aggiornamento di un cluster comporta le azioni seguenti:
- Contrassegna MemberUpdateStatus come Failed nel cluster membro.
- Contrassegna tutti gli elementi parent (gruppo - fase > esecuzione > esecuzione) come Failed con un messaggio di errore di riepilogo.
- Impedisci che l'esecuzione dell'aggiornamento prosegua.

Nota

È possibile eseguire nuovamente un aggiornamento in qualsiasi momento per riapplicare gli aggiornamenti che potrebbero essere stati ignorati o non riusciti.

Informazioni sui profili di aggiornamento automatico (anteprima)

I profili di aggiornamento automatico vengono usati per attivare automaticamente le esecuzioni degli aggiornamenti quando vengono rese disponibili nuove versioni delle immagini del nodo o Kubernetes per il servizio Azure Kubernetes.

Importante

Le funzionalità di anteprima di Gestione flotta Kubernetes di Azure sono disponibili in modalità self-service e acconsentono esplicitamente. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime di Gestione flotta Kubernetes di Azure sono parzialmente coperte dal supporto clienti in base al massimo impegno. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione.

In un profilo di aggiornamento automatico è possibile configurare:

un Channel oggetto (Stable, Rapid, NodeImage) che determina il tipo di aggiornamento automatico applicato ai cluster.
che UpdateStrategy configura la sequenza in cui vengono aggiornati i cluster. Se non viene fornita una strategia, i cluster vengono aggiornati uno per uno in sequenza.
( NodeImageSelectionType Latest, Consistent) per specificare la modalità di selezione dell'immagine del nodo durante l'aggiornamento della versione di Kubernetes.

Canale stabile

Il canale Stable è sempre la versione più recente della patch Kubernetes supportata dal servizio Azure Kubernetes nella versione secondaria N-1, dove N è la versione secondaria supportata più recente.

Esempi:

La versione secondaria più recente supportata di Kubernetes è la 1.30. Tutte le versioni patch nell'intervallo secondario 1.29 vengono considerate per gli aggiornamenti del canale Stabile.
Viene pubblicata una nuova versione secondaria di Kubernetes 1.31 . Qualsiasi versione patch nell'intervallo secondario 1.30 verrebbe considerata per gli aggiornamenti del canale Stabile. Qualsiasi cluster che riceve in precedenza gli aggiornamenti dalla versione 1.29 verrà aggiornato alla patch più recente per la versione 1.30.

Canale rapido

Il canale Rapid è sempre la versione secondaria di Kubernetes supportata dal servizio Azure Kubernetes più recente.

Esempi:

La versione secondaria supportata più recente è la 1.30. Qualsiasi versione patch nell'intervallo secondario 1.30 verrebbe considerata per gli aggiornamenti del canale Rapido.
Viene pubblicata una nuova versione secondaria di Kubernetes 1.31 . 1.30 passa al canale Stabile. Tutti i cluster che in precedenza ricevono gli aggiornamenti dalla versione 1.30 verranno aggiornati alla patch più recente per la versione 1.31 , che è ora il canale Rapid.

Canale NodeImage

I nodi del cluster membro vengono aggiornati con un nuovo disco rigido virtuale con patch contenente correzioni di sicurezza e correzioni di bug a cadenza settimanale. L'aggiornamento al nuovo disco rigido virtuale causa interruzioni, in base alle finestre di manutenzione e le impostazioni di picco. Quando si sceglie questa opzione, non viene addebitato alcun costo aggiuntivo per il disco rigido virtuale.

Se si usa questo canale, gli aggiornamenti automatici di Linux vengono disabilitati per impostazione predefinita. Gli aggiornamenti delle immagini del nodo supportano le versioni patch deprecate, purché la versione secondaria di Kubernetes sia ancora supportata. Le immagini del nodo sono testate dal servizio Azure Kubernetes, completamente gestite e applicate con procedure di distribuzione sicure.

I nodi in sistemi operativi diversi verranno aggiornati in base alle versioni dell'immagine del nodo allineate a tali sistemi operativi.

Esempio:

Un cluster include nodi con nodeImage del servizio Azure KubernetesWindows-2022-containerd della versione 20348.2582.240716. Viene rilasciata una nuova versione NodeImage 20348.2582.240916 e i nodi del cluster vengono aggiornati automaticamente alla versione 20348.2582.240916.

Comportamento di ignorare la versione secondaria

L'aggiornamento automatico non sposta i cluster tra le versioni secondarie di Kubernetes quando è presente più di una differenza di versione secondaria di Kubernetes ( ad esempio: da 1.28 a 1.30). Se gli amministratori hanno un set diversificato di versioni di Kubernetes, è consigliabile usare prima una o più esecuzioni di aggiornamento per portare i cluster membri in un set di versioni con controllo delle versioni coerente in modo che gli aggiornamenti configurati Stable o Rapid dei canali garantiscano che la coerenza venga mantenuta in futuro.