Definire strategie di aggiornamento riutilizzabili con Azure Kubernetes Fleet Manager

1. Nel portale di Azure, vai alla risorsa Azure Kubernetes Fleet Manager.

2. Nel menu del servizio, in Impostazioni, selezionare Cluster membri>Aggiungi.

   

3. Selezionare il cluster da aggiungere e quindi selezionare Avanti: Rivedi e aggiungi.

4. Immettere il nome del gruppo di aggiornamento a cui si vuole assegnare il cluster e quindi selezionare Aggiungi.

   

Assegnare un cluster membro a un gruppo di aggiornamento quando si aggiunge il cluster membro alla flotta usando il comando az fleet member create con il parametro --update-group impostato sul nome del gruppo di aggiornamento.

az fleet member create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name member1 \
    --member-cluster-id $CLUSTERID \
    --update-group group-1a

1. Nel portale di Azure, vai alla risorsa Azure Kubernetes Fleet Manager.

2. Nel menu del servizio, in Impostazioni, selezionare Cluster membri.

3. Selezionare i cluster da assegnare a un gruppo di aggiornamento e quindi selezionare Assegna gruppo di aggiornamento

   

4. Immettere il nome del gruppo di aggiornamento a cui si vuole assegnare il cluster e quindi selezionare Assegna.

   

Assegna un membro esistente della flotta a un gruppo di aggiornamento usando il comando az fleet member update con il flag --update-group assegnato al nome del gruppo di aggiornamento.

az fleet member update \
 --resource-group $GROUP \
 --fleet-name $FLEET \
 --name member1 \
 --update-group group-1

1. Nel portale di Azure, vai alla risorsa Azure Kubernetes Fleet Manager.

2. Dal menu del servizio, in Impostazioni, selezionare Strategie di aggiornamento> e quindi Crea.

3. Immettere un nome per la strategia.

4. La prima volta che si visualizza la pagina, viene visualizzato un diagramma di spiegazione della strategia di aggiornamento che consente di visualizzare il funzionamento delle strategie.

   

5. Selezionare Crea fase e immettere:

   • Nome della fase - nomina la fase - deve essere univoco tra tutti i nomi delle fasi nella strategia.
   • (Facoltativo) Approvazioni delle fasi: selezionare questa opzione se si desidera attendere un'approvazione prima che inizi questa fase o dopo che viene completata. Per altre informazioni, vedere Aggiungere approvazioni per aggiornare gruppi e fasi.
   • (Facoltativo) Pausa dopo la fase : selezionare questa opzione se si vuole definire una pausa prima di passare alla fase successiva.
   • (Facoltativo) Sospendere la durata : selezionare una durata predefinita oppure immettere un valore personalizzato in secondi.

   

6. Assegnare uno o più gruppi di aggiornamento alla fase e quindi selezionare Crea.

   Nota

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

   

Per questo scenario vengono create fasi e gruppi in modo che corrispondano ai dettagli usati per il processo del portale di Azure.

1. Creare un file JSON per definire le fasi e i gruppi per l'esecuzione dell'aggiornamento. Le fasi vengono eseguite in sequenza nell'ordine in cui vengono visualizzate nel file JSON. I gruppi vengono eseguiti in parallelo all'interno di ogni fase, quindi l'ordinamento non è importante. Il file di esempio seguente (example-stages.json) definisce una strategia con due fasi e include le impostazioni facoltative maxConcurrency e maxAllowedFailures:

   {
       "stages": [
           {
               "name": "stage-1",
               "maxConcurrency": "7",
               "maxAllowedFailures": "2",
               "groups": [
                   {
                       "name": "group-1",
                       "maxConcurrency": "3",
                       "maxAllowedFailures": "1"
                   },
                   {
                       "name": "group-2",
                       "maxConcurrency": "50%",
                       "maxAllowedFailures": "25%"
                   }
               ],
               "afterStageWaitInSeconds": 300
           },
           {
               "name": "stage-2",
               "maxConcurrency": "100%",
               "maxAllowedFailures": "0",
               "groups": [
                   {
                       "name": "group-3",
                       "maxConcurrency": "2",
                       "maxAllowedFailures": "0"
                   }
               ]
           }
       ]
   }
   

   maxConcurrency

   Il maxConcurrency campo è facoltativo e controlla il numero di cluster che possono eseguire l'aggiornamento simultaneo a livello di fase o di gruppo. Usare un valore più grande per aggiornare i cluster più velocemente all'interno della flotta o un valore inferiore per un'implementazione più controllata che limita il raggio di esplosione in caso di problemi.

   In questo esempio, stage-1 imposta maxConcurrency su "7", il che consente fino a "7" cluster in questa fase di eseguire l'aggiornamento contemporaneamente. All'interno di stage-1, group-1 limita la concorrenza a "3" cluster, il che significa che fino a "3" elementi in questo gruppo possono eseguire l'aggiornamento simultaneamente. group-2 consente l'aggiornamento "50%" simultaneo dei cluster, ad esempio se il gruppo contiene 4 cluster, fino a 2 può eseguire l'aggiornamento contemporaneamente.

   I valori possono essere un numero intero fisso (ad esempio, "3") o una percentuale (ad esempio, "100%"). Se omesso, il sistema applica i valori predefiniti. Per informazioni dettagliate su come questi valori vengono risolti e sui relativi limiti superiori, vedere Concorrenza massima (anteprima).

   maxAllowedFailures

   Il campo maxAllowedFailures è facoltativo e determina quanti errori di aggiornamento dei cluster membri sono tollerati prima che il gruppo o la fase vengano contrassegnati come non riusciti. Per impostazione predefinita (quando non è impostato o "0"), un singolo errore arresta l'intera esecuzione dell'aggiornamento.

   Questa impostazione valuta solo il numero di errori. Non applica un tasso minimo di successo. Un gruppo o una fase può quindi terminare Completed anche se alcuni o tutti i membri hanno avuto esito negativo, purché la soglia di errore non sia stata superata quando Fleet ha preso le decisioni di pianificazione.

   In questo esempio, stage-1 imposta maxAllowedFailures su "2", tollerando fino a due guasti dei membri nell'intera fase. All'interno di stage-1, group-1 tollera il guasto di "1" e group-2 tollera il guasto di "25%" dei suoi membri (ad esempio, se il gruppo contiene 4 cluster, viene tollerato un massimo di 1 guasto). stage-2 imposta maxAllowedFailures su "0", il che significa che qualsiasi errore arresta immediatamente l'esecuzione ed è spesso utile per le fasi di produzione.

   Per la maggior parte delle implementazioni, preferisce valori basati su percentuale perché sono più scalabili tra diverse dimensioni di gruppo. Evitare di impostare il valore sul numero totale di membri, a meno che non si desideri intenzionalmente un comportamento di fatto di "mai fallire" per quel segmento.

   I valori possono essere un numero intero fisso (ad esempio, "3") o una percentuale (ad esempio, "25%"). Per informazioni dettagliate sulla risoluzione di questi valori, vedere Numero massimo di errori consentiti (anteprima).

2. Creare una nuova strategia di aggiornamento usando il az fleet updatestrategy create comando con il --stages flag impostato sul nome del file JSON.

   az fleet updatestrategy create \
    --resource-group $GROUP \
    --fleet-name $FLEET \
    --name $STRATEGY \
    --stages example-stages.json