Aggiorna in sicurezza Kubernetes e le immagini dei nodi tra più cluster

Si applica a: ✔️ Fleet Manager ✔️ Fleet Manager con cluster hub

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 consente di orchestrare gli aggiornamenti in più cluster usando le esecuzioni degli aggiornamenti.

Le esecuzioni degli aggiornamenti sono costituite da fasi, gruppi e strategie. È possibile applicare manualmente le esecuzioni degli aggiornamenti per gli aggiornamenti monouso o automaticamente per gli aggiornamenti regolari in corso usando i profili di aggiornamento automatico. Tutte le esecuzioni degli aggiornamenti, sia manuali che automatizzate, rispettano le finestre di manutenzione del cluster.

Comprendere le esecuzioni di aggiornamento

Un'esecuzione di aggiornamento rappresenta l'applicazione di un aggiornamento a un insieme di cluster AKS. È costituito dall'obiettivo e dalla sequenza di aggiornamento. L'obiettivo di aggiornamento descrive gli aggiornamenti desiderati. Ad esempio, l'aggiornamento a una versione specifica di Kubernetes o l'applicazione di un'immagine del nodo coerente in tutti i cluster.

Per ottenere risultati ottimali quando si usa l'esecuzione degli aggiornamenti, è importante comprendere i concetti seguenti.

• Strategia di aggiornamento: descrive una sequenza di aggiornamento riutilizzabile costituita da fasi e gruppi di cluster. Un cluster viene visualizzato in un gruppo in una fase in base al gruppo di aggiornamento assegnato. Per altre informazioni, vedere Informazioni sulle strategie di aggiornamento.

  • Fase di aggiornamento: una strategia di aggiornamento è suddivisa in fasi di aggiornamento, che vengono applicate in sequenza. Ad esempio, i cluster di ambiente di test si trovano nella prima fase di aggiornamento, mentre i cluster dell'ambiente di produzione passano in una seconda fase di aggiornamento. Una fase di aggiornamento contiene uno o più gruppi di aggiornamento. È possibile usare controlli aggiuntivi, ad esempio la concorrenza massima, i tempi di attesa e i controlli di approvazione per un maggiore controllo sull'esecuzione della fase di aggiornamento.

  • Gruppo di aggiornamento: ogni fase di aggiornamento contiene uno o più gruppi di aggiornamento, che selezionano i cluster da aggiornare. Assegnare i cluster membri ai gruppi di aggiornamento utilizzando la proprietà Gruppo di aggiornamento del cluster. I gruppi di aggiornamento in una fase di aggiornamento vengono aggiornati in parallelo.

  Note

  Il numero massimo di gruppi di aggiornamento in ogni fase dell’aggiornamento è 50.

  • Ulteriori controlli di flusso: sono disponibili più controlli per offrire flessibilità rispetto alla velocità di aggiornamento di una flotta di cluster:

    • Concorrenza massima (anteprima): usare la configurazione massima di concorrenza per modificare il numero di cluster aggiornati in parallelo. È possibile configurare questo comportamento sia a livello di fase che di gruppo.

    • Controlli di approvazione: è possibile configurare questi cancelli prima o dopo ogni fase o gruppo. Le approvazioni sospendono l'esecuzione dell'aggiornamento, che i controlli automatici o manuali usano per determinare se è ok procedere. Dopo che l'approvazione è stata concessa, l'esecuzione dell'aggiornamento continua.

• Profilo di aggiornamento automatico: crea e avvia automaticamente un'esecuzione di aggiornamento quando AKS rende disponibili nuove versioni di Kubernetes o delle immagini del nodo. Per altre informazioni, vedere Informazioni sui profili di aggiornamento automatico.

Aggiornare le opzioni di esecuzione

Le esecuzioni degli aggiornamenti possono applicare tre tipi di aggiornamenti:

• Aggiornare le versioni di Kubernetes per il piano di controllo e i nodi. Questo aggiornamento include l'aggiornamento dell'immagine del nodo.
• Aggiornare le versioni di Kubernetes solo per il piano di controllo dei cluster.
• Eseguire l'aggiornamento solo delle immagini del nodo.

È possibile specificare la versione di Kubernetes di destinazione a cui eseguire l'aggiornamento, ma non è possibile selezionare le versioni dell'immagine del nodo di destinazione. Il sistema seleziona automaticamente le versioni dell'immagine del nodo di destinazione in base alle preferenze:

• Più recente: usare le immagini dei nodi più recenti disponibili nell'area Azure di ogni cluster all'avvio dell'aggiornamento del cluster. Di conseguenza, è possibile usare versioni di immagini diverse in tutta la flotta, a seconda della Azure area in cui si trova un cluster e all'avvio effettivo dell'aggiornamento.
• Coerente: all'avvio dell'esecuzione dell'aggiornamento, selezionare le versioni delle immagini attualmente disponibili in tutte le aree Azure in cui si trovano i cluster in questa esecuzione. Di conseguenza, le versioni delle immagini coerenti vengono usate in tutti i cluster.

Scegliere Più recente per usare le versioni delle immagini più recenti e ridurre al minimo i rischi per la sicurezza. Scegliere Coerente per migliorare l'affidabilità usando e verificando tali immagini nei cluster nelle fasi precedenti prima di usarle nei cluster successivi.

Aggiorna stati di esecuzione

Per comprendere il ciclo di vita di un'esecuzione di aggiornamento, è necessario conoscere ogni stato, le azioni che è possibile eseguire e come viene calcolato lo stato.

Stato in sospeso

• Aggiorna esecuzione: se la fase corrente è nello stato Pending.
• Fase di aggiornamento: se tutti i gruppi di aggiornamento nella fase sono Pending o non ancora avviati, oppure se è presente un gate Pending.
• Gruppo di aggiornamento: se tutti i cluster nel gruppo sono Pending o non avviati o se dispone di un Pending gate. Quando un cluster passa a Pending, l'esecuzione dell'aggiornamento tenta di aggiornare il cluster successivo nel gruppo. Se tutti i membri sono Pending, il gruppo passa a Pending. L'esecuzione dell'aggiornamento attende il completamento di tutti i gruppi in una fase prima di passare alla fase successiva.
• Cluster membro: per uno dei motivi seguenti, che è possibile visualizzare nel campo del messaggio.
  • La finestra di manutenzione non è aperta. Il messaggio indica l'ora di apertura successiva.
  • La versione di Kubernetes o dell'immagine del nodo di destinazione non è ancora disponibile nell'area di Azure del cluster. Il messaggio contiene un collegamento al tracker delle versioni di AKS per controllare lo stato della versione.

Stato ignorato

• Esecuzione di aggiornamento: il sistema ha rilevato che tutte le fasi erano Skipped.
• Fase di aggiornamento: un utente ha contrassegnato la fase o tutti i gruppi nella fase come Skipped.
• Aggiorna gruppo: un utente ha contrassegnato il gruppo o tutti i cluster nel gruppo come Skipped.
• Cluster membro: per uno dei motivi seguenti, che è possibile visualizzare nel campo del messaggio.
  • L'utente ha ignorato in modo esplicito il cluster, il gruppo o la fase.
  • Il cluster è già nella versione di Kubernetes di destinazione (se la modalità di esecuzione dell'aggiornamento è Full o ControlPlaneOnly) e tutti i pool di nodi si trovano nella versione dell'immagine del nodo di destinazione.
  • Quando è selezionata un'immagine del nodo coerente e non è possibile trovare la versione dell'immagine di destinazione per uno dei pool di nodi. Questa situazione può verificarsi quando viene aggiunto un nuovo pool di nodi con un nuovo SKU di macchina virtuale dopo l'avvio di un'esecuzione dell'aggiornamento.

Stato non riuscito

Lo stato di errore si propaga a catena dai cluster, come illustrato. Un messaggio di errore di riepilogo visualizza la causa dell'aggiornamento del cluster non riuscito.

• Esecuzione dell'aggiornamento: almeno un cluster nel gruppo corrente ha avuto esito negativo.
• Fase di aggiornamento: almeno un cluster in un gruppo della fase ha avuto esito negativo.
• Gruppo di aggiornamento: almeno un cluster nel gruppo ha avuto esito negativo.
• Cluster membro: l'aggiornamento non è riuscito e lo stato del cluster è impostato su Failed.

Finestre di manutenzione pianificata

Gli aggiornamenti rispettano le finestre di manutenzione pianificate impostate a livello di cluster AKS.

I cluster del servizio Azure Kubernetes supportano due finestre di manutenzione distinte, una per gli aggiornamenti di Kubernetes (piano di controllo) e una per gli aggiornamenti delle immagini del nodo. Le finestre di manutenzione definiscono i periodi in cui gli aggiornamenti possono essere applicati a un cluster, ma non sono un trigger di aggiornamento.

Le esecuzioni degli aggiornamenti di Fleet Manager rispettano le finestre di manutenzione di AKS come segue:

L'esecuzione dell'aggiornamento assegna priorità all'aggiornamento dei cluster in base alla manutenzione pianificata nell'ordine seguente:

1. Cluster con una finestra di manutenzione aperta e in corso.
2. Cluster con finestra di manutenzione aperta nelle quattro ore successive.
3. Cluster senza finestra di manutenzione.
4. Cluster con finestra di manutenzione chiusa.

Informazioni sui profili di aggiornamento automatico

Usa i profili di aggiornamento automatico per avviare automaticamente le esecuzioni degli aggiornamenti quando sono disponibili nuove versioni di Kubernetes o delle immagini dei nodi per AKS.

In un profilo di aggiornamento automatico, si configurano:

• un canale (Rapid, Stable, TargetKubernetesVersion, NodeImage, SecurityPatch (anteprima)) che determina il tipo di aggiornamento applicato ai cluster.
• UpdateStrategy che configura la sequenza in cui vengono aggiornati i cluster. Se non si fornisce una strategia, i cluster aggiornano uno alla volta in sequenza.
• NodeImageSelectionType (Latest, Consistent) per specificare la modalità di selezione dell'immagine del nodo durante l'aggiornamento della versione di Kubernetes.

Canale Rapid

Il canale Rapid è sempre la versione secondaria di Kubernetes supportata dal servizio Azure Kubernetes più recente. Le versioni secondarie del cluster cambiano automaticamente quando AKS rilascia una nuova versione secondaria di Kubernetes.

Esempi:

• La versione secondaria supportata più recente è la 1.30. Qualsiasi versione patch nell'intervallo secondario 1.30 viene considerata per gli aggiornamenti del canale Rapido.
• Viene pubblicata una nuova versione secondaria di Kubernetes 1.31. 1.30 passa al canale Stable. Qualsiasi cluster che riceve in precedenza gli aggiornamenti dalla versione 1.30 viene aggiornato alla patch più recente per la versione 1.31 che è ora il canale Rapid.

Canale stabile

Il canale Stable è sempre la versione secondaria prima del canale Rapid . In alcuni casi, le persone fanno riferimento a Stable come "N-1", dove "N" è la versione secondaria più recente (canale Rapido) supportata da Kubernetes. Le versioni secondarie del cluster cambiano automaticamente quando AKS rilascia una nuova versione secondaria di Kubernetes.

Esempi:

• La versione secondaria più recente supportata di Kubernetes è la 1.30. Qualsiasi versione patch nell'intervallo della versione secondaria 1.29 viene considerata per gli aggiornamenti del canale Stable.
• Viene pubblicata una nuova versione secondaria di Kubernetes 1.31. Il canale Stabile considera qualsiasi versione patch nell'intervallo secondario 1.30 per gli aggiornamenti. Qualsiasi cluster che riceve in precedenza gli aggiornamenti dalla versione 1.29 viene aggiornato alla patch più recente per la versione 1.30.

Canale TargetKubernetesVersion

Il canale TargetKubernetesVersion consente di controllare quando spostare i cluster alla versione secondaria di Kubernetes successiva. È necessario specificare la versione di Kubernetes di destinazione nel formato "{major}. {minor}" (ad esempio, "1.33"). Fleet Manager aggiorna automaticamente i cluster alla versione patch più recente della versione di Kubernetes di destinazione specificata quando la patch è disponibile. Fleet Manager non esegue l'aggiornamento alla successiva versione minor finché la versione Kubernetes di destinazione del profilo di aggiornamento automatico non viene aggiornata.

Esempi:

• È possibile creare un profilo di aggiornamento automatico utilizzando il canale TargetKubernetesVersion e specificando una versione Kubernetes di destinazione pari a "1.30". Viene pubblicata una nuova patch versione 1.30.5. Viene creata automaticamente un'esecuzione di aggiornamento con la destinazione 1.30.5.
• Per creare un profilo di aggiornamento automatico, usare il canale TargetKubernetesVersion, specificare una versione di Kubernetes di destinazione "1.29" e abilitare LongTermSupport (LTS) nel profilo di aggiornamento automatico. La versione minor supportata dalla community più recente è "1.33". Viene pubblicata una nuova patch versione 1.29.5. Viene creata automaticamente un'esecuzione di aggiornamento con la destinazione 1.29.5. Se l'esecuzione dell'aggiornamento generato include cluster senza LTS abilitato, l'operazione ha esito negativo.

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). Quando gli amministratori gestiscono una gamma eterogenea di versioni di Kubernetes, devono innanzitutto usare una o più operazioni di aggiornamento per portare i cluster a un insieme di release con versioni coerenti, in modo che gli aggiornamenti del canale configurati con Stable o Rapid garantiscano il mantenimento della coerenza anche in futuro.

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 sono 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 dei nodi sono testate per il servizio Azure Kubernetes, completamente gestite e applicate con procedure di distribuzione sicure.

I nodi in sistemi operativi diversi vengono 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.

Informazioni sugli snapshot e sugli aggiornamenti delle immagini del nodo

Quando un cluster dispone di pool di agenti creati da uno snapshot del pool di nodi, il risultato dell'aggiornamento dell'immagine del nodo dipende dalla selezione dell'immagine del nodo nell'esecuzione dell'aggiornamento di Fleet Manager.

Canale SecurityPatch (anteprima)

Aggiornare i nodi Linux del cluster membro con solo correzioni di sicurezza a cadenza settimanale. Canonical Ubuntu e Azure Linux rendono disponibili le patch di sicurezza del sistema operativo una volta al giorno. Microsoft testa queste patch e le aggrega in aggiornamenti settimanali alle immagini del nodo.

Questo canale di aggiornamento automatico di Fleet Manager è meno invasivo grazie all'applicazione live delle patch del sistema operativo, ma richiede l’archiviazione nella sottoscrizione di immagini disco (VHD) con patch applicate da usare per i nodi di cui viene eseguito il provisioning, con un costo nominale.

Solo i nodi basati su Linux vengono aggiornati quando si usano SecurityPatche i nodi basati su Windows vengono ignorati automaticamente.

Se sono necessarie correzioni di bug fornite con nuove immagini del nodo (VHD) o un'esperienza coerente con i nodi Windows, scegliere invece il canale NodeImage.

Informazioni sulle strategie di aggiornamento

Gli amministratori possono controllare l'ordine in cui i cluster vengono aggiornati creando strategie di aggiornamento riutilizzabili usando una serie di fasi di aggiornamento e gruppi. Possono configurare quando le approvazioni e le pause devono essere eseguite all'interno di tali fasi e gruppi. L'intera configurazione può essere salvata come strategia di aggiornamento che può essere gestita indipendentemente dalle esecuzioni di aggiornamento o dai profili di aggiornamento automatico, consentendo di riutilizzare le strategie in base alle esigenze.

Concorrenza massima (anteprima)

Maximum concurrency è un'impostazione facoltativa nella strategia di aggiornamento che controlla il numero di cluster che possono eseguire l'aggiornamento simultaneo. È possibile impostare Maximum concurrency a due livelli:

• Livello di fase: definisce il numero massimo di cluster che possono eseguire l'aggiornamento contemporaneamente in tutti i gruppi in una fase. Funge da limite massimo globale per il palcoscenico.
• Livello di gruppo: definisce il numero massimo di cluster che possono eseguire l'aggiornamento simultaneo all'interno di un gruppo specifico.

La concorrenza massima accetta due formati di valore:

• Numero intero fisso: ad esempio, "3" limita la concorrenza a tre cluster esattamente.
• Percentuale: ad esempio, "25%" limita la concorrenza a una percentuale di cluster. Per le impostazioni a livello di fase, la percentuale viene calcolata da tutti i cluster nella fase. Per le impostazioni a livello di gruppo, la percentuale viene calcolata dai cluster in tale gruppo. Le percentuali vengono calcolate in fase di esecuzione, arrotondate all'intero inferiore e applicate con un valore minimo di 1.

Suggerimenti per il controllo della concorrenza

Se si vuole eseguire l'aggiornamento con sicurezza (minore velocità, ma meno probabile che termini con più cluster interrotti): impostare la concorrenza massima su un valore inferiore. Se si vuole eseguire l'aggiornamento con velocità (maggiore velocità, ma più probabile terminare con più cluster interrotti): impostare la concorrenza massima su un valore maggiore.

Interazione tra fasi e limiti di gruppo

La concorrenza massima a livello di fase funge sempre da limite complessivo. Anche se i singoli gruppi consentono una concorrenza più elevata, il limite di fase ha la precedenza. La concorrenza a livello di gruppo potrebbe essere inferiore a quella configurata a causa del limite a livello di fase, delle dimensioni del gruppo o delle condizioni specifiche dei membri.

Esempio 1: Limiti fissi

Risultato: fino a quattro cluster totali, con un massimo di due per gruppo.

Esempio 2. Gruppi di limitazioni di fase

Risultato: solo due cluster vengono aggiornati contemporaneamente perché il limite di fase ha la precedenza.

Esempio 3: Implementazione basata su percentuale

Una fase ha 20 cluster in due gruppi: gruppo A (otto cluster) e gruppo B (12 cluster).

Risultato: fino a cinque aggiornamenti simultanei totali, distribuiti tra gruppi in base ai singoli limiti.

Passaggi successivi

• Guida: aggiornare più cluster tramite esecuzioni di aggiornamento di Azure Kubernetes Fleet Manager.
• Come: aggiornare automaticamente più cluster usando Azure Kubernetes Fleet Manager.
• Come monitorare le esecuzioni degli aggiornamenti per Azure Kubernetes Fleet Manager.
• Domande frequenti sugli aggiornamenti multi-cluster.