Aggiornare l'orchestrazione tra più cluster membri

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 delle versioni dell’immagine del sistema operativo del nodo, l'aggiornamento delle versioni di Kubernetes) in modo sicuro e prevedibile. Per risolvere questo problema, Gestione flotta Kubernetes di Azure consente di orchestrare gli aggiornamenti in più cluster usando esecuzioni degli aggiornamenti, fasi, gruppi e strategie.

• 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 in cui applicare gli aggiornamenti a più cluster membri, espresso 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: la strategia di aggiornamento descrive la sequenza di aggiornamento con fasi e gruppi. È possibile riutilizzare una strategia nelle esecuzioni degli aggiornamenti anziché definire ripetutamente la sequenza in ogni esecuzione.

Attualmente, le operazioni di aggiornamento supportate nel cluster sono upgrade. 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 i piani di controllo dei cluster
• Eseguire l’upgrade solo delle immagini del nodo.

È possibile specificare la versione di Kubernetes di destinazione da sottoporre all'upgrade, ma non è possibile specificare le versioni esatte dell'immagine del nodo di destinazione perché le versioni più recenti dell'immagine del nodo disponibili possono variare a seconda della zona del cluster (per ulteriori informazioni, utilizzare il rilevatore delle versioni). Le versioni dell'immagine del nodo di destinazione vengono selezionate automaticamente in base alle preferenze:

• Latest: usare le immagini dei nodi più recenti disponibili nella zona di un cluster all'avvio dell'upgrade del cluster. Di conseguenza, è possibile usare versioni di immagini differenti a seconda della zona in cui si trova il cluster e all'avvio effettivo dell'upgrade.
• Consistent: all'avvio dell'esecuzione dell'upgrade, vengono selezionate le versioni più recenti e comuni delle immagini nelle aree dei cluster membri in tale esecuzione, in modo che le stesse versioni delle immagini vengano usate nei cluster con coerenza.

È 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:

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

Stati di esecuzione dell’aggiornamento

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

• Non iniziato: stato dell'esecuzione dell'aggiornamento prima dell'avvio.

• In esecuzione: l'aggiornamento è in corso per almeno uno dei cluster nell'esecuzione dell'aggiornamento.

• In sospeso.

  • Cluster membro: un cluster membro può essere in sospeso per uno dei motivi seguenti, che compaiono sotto il campo del messaggio.
    • Finestra di manutenzione non aperta. Il messaggio indica l'ora di apertura successiva.
    • La versione di Kubernetes di destinazione non è ancora disponibile nella zona 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 nella zona 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 stato Pending se tutti i membri dei gruppi sono nello stato Pending o Non iniziato. 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 nello stato Pending, il gruppo passa allo stato Pending. Tutti i gruppi devono trovarsi nello stato finale prima di passare alla fase successiva. Ovvero, se un gruppo è nello stato Pending, l'esecuzione dell'aggiornamento attende il completamento prima di passare alla fase successiva per l'esecuzione.
  • Fase: una fase è nello stato Pending se tutti i gruppi di tale fase sono nello stato Pending o Non iniziato.
  • Esecuzione: un'esecuzione è nello stato Pending se la fase corrente che dovrebbe essere in esecuzione è nello stato Pending.

• Ignorato: tutti i livelli dell'esecuzione di un aggiornamento possono essere ignorati e questo potrebbe essere rilevato dal sistema o avviato dall'utente.

  • Membro:
    • È stato ignorato l'upgrade per un membro o per uno dei suoi parent.
    • 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 l'esecuzione di un upgrade, se non è possibile trovare la versione dell'immagine di destinazione per uno dei pool di nodi, l'upgrade viene ignorato per tale cluster. Una situazione di esempio è quando viene aggiunto un nuovo pool di nodi con un nuovo SKU di macchina virtuale dopo l'avvio dell'esecuzione dell'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 nello 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 upgrade del cluster), tale operazione non viene interrotta per quel singolo cluster.
  • Se si verifica un errore durante l'esecuzione dell'aggiornamento (come ad esempio upgrade non andati a buon fine in uno dei cluster), l'intera esecuzione dell’aggiornamento viene eseguito entra in uno stato di arresto e non vengono eseguite operazioni per nessun cluster successivo nell’esecuzione dell’aggiornamento.

• Non riuscito: un errore nel corso dell’aggiornamento di un cluster comporterà 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.

Passaggi successivi

• Orchestrare gli aggiornamenti in più cluster membri.