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 di gestione temporanea degli aggiornamenti per 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 alle etichette dei membri o del 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. Assegna cluster membri a Gruppi di aggiornamento usando la proprietà Update Group del cluster o la corrispondenza basata su etichette in anteprima usando le etichette dei membri. 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.

    • Numero massimo di errori consentiti (anteprima): usare la configurazione Numero massimo di errori consentiti per controllare il numero di errori di aggiornamento del cluster membro tollerati prima dell'arresto dell'esecuzione dell'aggiornamento. È possibile configurare questo comportamento sia a livello di fase che di gruppo.

    • Gates: Sospendono l'esecuzione dell'aggiornamento finché la condizione non è soddisfatta.

      • Gate di approvazione (anteprima): possono essere configurati prima o dopo ogni fase o gruppo. Le approvazioni sospendono l'esecuzione dell'aggiornamento, consentendo all'utente o alle automazione configurate di verificare che sia OK per continuare. Dopo che tu o l'automazione concede l'approvazione, l'esecuzione dell'aggiornamento continuerà.

      • Gate di avvio pianificati (anteprima): possono essere configurati prima di ogni fase o gruppo. Le attività di controllo dell'avvio pianificato sospendono l'esecuzione dell'aggiornamento fino al giorno e all'ora specificati. L'attività di controllo viene completata automaticamente quando viene raggiunto l'orario pianificato oppure è possibile completarla manualmente per procedere in qualsiasi momento.

• 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.

Quando si configura Numero massimo errori consentiti, la soglia di errore influisce sullo stato del gruppo di aggiornamento, della fase di aggiornamento e dell'esecuzione dell'aggiornamento. Non influisce sullo stato di un singolo cluster membro. Se l'aggiornamento di un cluster membro non riesce, il relativo stato è ancora impostato su Failed.

• Se il numero di errori per il gruppo o la fase supera la soglia configurata maxAllowedFailures , il gruppo o la fase viene contrassegnata come Failed con un messaggio di errore di riepilogo e l'esecuzione dell'aggiornamento interrompe l'avanzamento. Se non maxAllowedFailures è configurato (o è impostato su 0), un singolo errore arresta l'intera esecuzione.
• Se il numero di errori è compreso nella maxAllowedFailures soglia, l'esecuzione dell'aggiornamento continua ad aggiornare i membri successivi. Per altre informazioni, vedere Numero massimo di errori consentiti.

Stato completato

Uno Completed stato indica che l'esecuzione dell'aggiornamento ha raggiunto uno stato del ciclo di vita del terminale. Quando si usa Massimo errori consentiti, Completed significa che la soglia di errore configurata non è stata superata quando Fleet Manager ha deciso se continuare a pianificare il lavoro. Non garantisce un tasso minimo di successo o risultati integri. Controllare sempre FailureCount, gli stati dei membri e i messaggi di errore.

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.

Panoramica dei 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. 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.

Il canale di aggiornamento automatico SecurityPatch è meno problematico perché usa l'applicazione di patch live del sistema operativo quando possibile, riducendo al minimo l'interruzione del nodo mantenendo i nodi protetti da vulnerabilità note. Quando il patching live non è possibile, viene invece distribuita un'immagine del nodo già patchata.

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.

Raggruppare i cluster usando le etichette dei membri (anteprima)

Le etichette dei membri possono essere usate per raggruppare i cluster e configurare la sequenza di aggiornamento con i selettori di etichetta di tipo Kubernetes. In questo modo, è possibile assegnare più etichette ai cluster membri e usarle per strategie diverse anziché essere limitate a un singolo gruppo di aggiornamento per ogni cluster. È possibile raggruppare i cluster nella strategia con le relative etichette membro configurando memberSelector nella strategia a due livelli:

• Livello di fase: seleziona i cluster per l'intera fase. Quando non sono definiti gruppi, tutti i cluster corrispondenti formano un singolo gruppo implicito. Quando si definiscono anche i gruppi, il selettore a livello di fase funge da filtro preliminare prima dell'applicazione della corrispondenza a livello di gruppo.
• Livello di gruppo: seleziona i cluster per un gruppo specifico all'interno di una fase, abilitando subset paralleli con limiti di concorrenza diversi.

memberSelector usa un selettore di etichette basato su stringa analizzato usando la sintassi standard del selettore di etichette Kubernetes. Gli operatori supportati sono: =, ==!=, in, notin, exists, e !exists.

Per istruzioni sull'assegnazione delle etichette dei membri e sull'uso memberSelector in una strategia, vedere Creare una strategia di aggiornamento usando i selettori dei membri.

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.

Numero massimo di errori consentiti (anteprima)

Maximum allowed failures è un'impostazione di strategia di aggiornamento facoltativa che controlla il modo in cui Fleet Manager risponde agli errori durante gli aggiornamenti multicluster.

Per impostazione predefinita, gli aggiornamenti seguono un modello fail-fast: un singolo errore del cluster arresta altri aggiornamenti. Quando si configura maximum allowed failures, l'esecuzione dell'aggiornamento diventa a tolleranza di errore e gli aggiornamenti continuano tra i cluster fino a quando non viene raggiunta la soglia di errore specificata.

Questa impostazione offre un equilibrio intenzionale tra il rilevamento degli errori iniziali e il mantenimento dello slancio della distribuzione. Impostare maximum allowed failures a due livelli:

• Livello di fase: definisce il numero massimo di errori di aggiornamento dei membri tollerati in tutti i gruppi in una fase prima che la fase venga contrassegnata come non riuscita.
• Livello di gruppo: definisce il numero massimo di errori di aggiornamento dei membri tollerati all'interno di un gruppo specifico prima che il gruppo venga contrassegnato come non riuscito.

Maximum allowed failures accetta due forme di valore:

• Numero intero fisso: ad esempio, "3" consente fino a tre errori del cluster membro prima che il gruppo o la fase sia contrassegnata come non riuscita.
• Percentuale: ad esempio, "25%" consente errori fino a 25% dei cluster membri. 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 al momento della creazione dell'esecuzione dell'aggiornamento, utilizzando l'arrotondamento per eccesso; ad esempio, il 25% di 5 cluster equivale a 2.

Fleet Manager valuta maxAllowedFailures unicamente in base al numero degli aggiornamenti dei membri non riusciti. Non valuta il tasso di successo e non richiede alcun numero minimo di membri riusciti. Quando questa impostazione è presente, Completed significa che la soglia di errore configurata non è stata superata al momento in cui Fleet Manager ha preso le decisioni di pianificazione. Completed non significa che l'implementazione sia integra o riuscita.

Esempio: completato con 0% di successo

Si supponga che un gruppo abbia quattro membri e group.maxAllowedFailures sia impostato su "4". Se tutti e quattro gli aggiornamenti dei membri hanno esito negativo, il gruppo può comunque essere contrassegnato come Completed. Questo risultato è previsto e intenzionale, non un bug, perché quattro errori equivalgono alla tolleranza configurata e pertanto non superano la soglia. In altre parole, un gruppo può essere Completed anche quando 100% dei relativi membri non sono riusciti.

Usare tale soglia solo quando tale comportamento corrisponde alle aspettative di implementazione.

Scegliere attentamente i valori soglia

• I valori assoluti sono facili da comprendere, ma possono produrre risultati controintuitivi in piccoli gruppi. Ad esempio, consentire "2" errori in un gruppo di due membri significa che il gruppo può terminare come Completed anche se nessuno dei membri ha avuto esito positivo.
• I valori percentuali si adattano meglio a gruppi di dimensioni diverse, quindi sono consigliati alla maggior parte degli utenti.
• Evitare di impostare maxAllowedFailures sul numero totale dei membri, a meno che non si voglia intenzionalmente un comportamento che impedisca effettivamente l'esito negativo dovuto a errori dei membri. Se questo comportamento è intenzionale, 100% in genere scala più chiaramente di un numero fisso.
• Prestare particolare attenzione ai gruppi di piccole dimensioni, in cui un singolo errore può rappresentare una percentuale elevata dell'implementazione.
• Rivalutare la soglia man mano che cresce la flotta. Un valore sicuro per cinque cluster potrebbe essere troppo rigoroso o troppo permissivo per 500 cluster.

Informazioni su FailureCount

I FailureCount campi segnalano le metriche. Vengono conteggiati gli aggiornamenti dei membri non riusciti. Non sono rapporti o percentuali e non corrispondono alla soglia di imposizione configurata.

• UpdateRun.FailureCount: totale di aggiornamenti dei membri non riusciti in tutte le fasi e in tutti i gruppi durante l'esecuzione.
• Stage.FailureCount: Totale degli aggiornamenti non riusciti dei membri in tutti i gruppi in quella fase.
• Group.FailureCount: totale degli aggiornamenti dei membri non riusciti all'interno del gruppo.

Esaminare sempre questi conteggi insieme a stati, condizioni e messaggi di errore a livello di membro prima di decidere se il risultato dell'implementazione è accettabile.

Perché FailureCount può superare maxAllowedFailures

maxAllowedFailures regola il processo decisionale di Fleet Manager in merito alla prosecuzione della pianificazione di nuove attività. Non è il limite superiore fisso del numero finale di errori segnalati.

Se si consentono aggiornamenti paralleli dei membri usando maxConcurrency, diversi membri possono non riuscire quasi contemporaneamente prima che Fleet Manager rilevi che la soglia è stata superata e smetta di pianificare altro lavoro. Di conseguenza, è possibile e previsto che FailureCount sia maggiore del valore configurato maxAllowedFailures .

Come interagiscono i limiti di errore della fase e del gruppo

Il livello di gruppo e il livello maxAllowedFailures di fase vengono valutati in modo indipendente:

• Ogni gruppo tiene traccia del proprio numero di errori rispetto alla propria soglia.
• Anche gli errori del gruppo vengono implementati nel FailureCount della fase.
• Se una delle due soglie viene superata, Fleet Manager interrompe la pianificazione di nuovi lavori per tale segmento.
• Gli aggiornamenti dei membri già avviati potrebbero ancora essere completati, il che potrebbe aumentare il FailureCount finale segnalato dopo che è stata presa la decisione di arresto.

Il livello maxAllowedFailures di fase funge da limite complessivo per la tolleranza di errore in una fase. Anche se i singoli gruppi consentono un numero di errori superiore, il limite di fase ha la precedenza. Se il numero di errori di un gruppo supera il proprio maxAllowedFailures, tale gruppo viene contrassegnato come non riuscito indipendentemente dall'impostazione a livello di fase.

Esempio 1: Limiti di errore fissi

Risultato: il gruppo A tollera fino a due errori e il gruppo B tollera fino a tre. Se gli errori totali nella fase superano cinque, la fase ha esito negativo.

Esempio 2: Tolleranza in base alla percentuale

Una fase include 19 cluster in due gruppi: gruppo A con 7 cluster e gruppo B con 12 cluster.

Usi consigliati e non consigliati

Utilizzare soglie più elevate o basate su percentuali quando si stanno aggiornando flotte di grandi dimensioni, si prevedono alcuni errori transitori oppure l'avanzamento dell'implementazione è più importante di un comportamento rigorosamente orientato all'interruzione immediata in caso di errore.

Usare 0 o valori molto piccoli per le implementazioni critiche per la sicurezza, le fasi di produzione strettamente controllate o qualsiasi situazione in cui è necessario arrestare e controllare dopo il primo errore.

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.