Applicare automaticamente gli aggiornamenti della configurazione delle VM in un gruppo di istanze gestite

Questo documento descrive come applicare automaticamente gli aggiornamenti di configurazione alle istanze di macchine virtuali (VM) in un gruppo di istanze gestite (MIG).

Compute Engine gestisce le VM in un gruppo di istanze gestite in base ai componenti di configurazione che utilizzi: modello di istanza, configurazione facoltativa per tutte le istanze e configurazione stateful facoltativa.

Ogni volta che aggiorni la configurazione della VM di un gruppo di istanze gestite modificando questi componenti, Compute Engine applica automaticamente la configurazione aggiornata alle nuove VM aggiunte al gruppo.

Per applicare una configurazione aggiornata alle VM esistenti, puoi configurare un aggiornamento automatico, noto anche come tipo di aggiornamento proattivo. Il gruppo di istanze gestite implementa automaticamente gli aggiornamenti di configurazione in tutte le VM del gruppo o in un sottoinsieme. Puoi controllare la velocità del deployment, il livello di interruzione del servizio e, utilizzando un aggiornamento canary, il numero di istanze aggiornate dal gruppo di istanze gestite con la nuova configurazione. Dopo aver specificato la nuova configurazione, non è necessario fornire input aggiuntivi e l'aggiornamento viene completato autonomamente.

In alternativa, se vuoi applicare una nuova configurazione in modo selettivo solo alle nuove o a istanze specifiche in un gruppo di istanze gestite, consulta Applicare in modo selettivo gli aggiornamenti della configurazione delle VM in un gruppo di istanze gestite. Per aiutarti a decidere, consulta la pagina Metodi per applicare una nuova configurazione alle VM esistenti.

Prima di iniziare

• Se stai aggiornando un gruppo di istanze gestite stateful, consulta la sezione Applicazione, visualizzazione e rimozione della configurazione stateful nei gruppi di istanze gestite.
• Se non l'hai ancora fatto, configura l'autenticazione. L'autenticazione è la procedura mediante la quale la tua identità viene verificata per l'accesso alle API e ai servizi Google Cloud. Per eseguire codice o esempi da un ambiente di sviluppo locale, puoi autenticarti su Compute Engine selezionando una delle seguenti opzioni:
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

  2. Set a default region and zone.

  REST

  Per utilizzare gli esempi dell'API REST in questa pagina in un ambiente di sviluppo locale, utilizza le credenziali fornite a gcloud CLI.

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  Per ulteriori informazioni, consulta Eseguire l'autenticazione per l'utilizzo di REST nella documentazione sull'autenticazione di Google Cloud.

Limitazioni

• Se hai un gruppo di istanze gestite stateful e vuoi utilizzare gli aggiornamenti incrementali automatici, devi mantenere i nomi delle istanze quando sostituisci le istanze o, in alternativa, impostare il metodo di sostituzione su RECREATE.

Avvio di un aggiornamento in sequenza di base

Un aggiornamento in sequenza di base viene applicato gradualmente a tutte le istanze in un gruppo di istanze gestite finché non sono state aggiornate tutte all'ultima configurazione prevista. L'aggiornamento incrementale salta automaticamente le istanze che sono già nella configurazione più recente.

Puoi controllare vari aspetti di un aggiornamento in sequenza, ad esempio quante istanze possono essere messe offline per l'aggiornamento, il tempo di attesa tra un aggiornamento e l'altro, se il nuovo modello interessa tutte le istanze o solo una parte e così via.

Ecco alcuni aspetti da tenere in considerazione quando esegui un aggiornamento progressivo:

• Gli aggiornamenti si basano sull'intenzione. Quando effettui la richiesta di aggiornamento iniziale, l'API Compute Engine restituisce una risposta positiva per confermare che la richiesta è valida, ma questo non indica che l'aggiornamento sia riuscito. Devi controllare lo stato del gruppo per determinare se l'aggiornamento è stato implementato correttamente.

• L'API Instance Group Updater è un'API dichiarativa. L'API si aspetta una richiesta per specificare la configurazione post-aggiornamento del gruppo di istanze gestite desiderata, anziché una chiamata esplicita alla funzione.

• Gli aggiornamenti automatici supportano fino a due versioni del modello di istanza nel gruppo di istanze gestite. Ciò significa che puoi specificare due diverse versioni del modello di istanza per il gruppo, il che è utile per eseguire aggiornamenti canary.

Per avviare un aggiornamento in sequenza di base in cui l'aggiornamento viene applicato a tutte le istanze del gruppo, segui le istruzioni riportate di seguito.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=INSTANCE_TEMPLATE_NAME
    [--zone=ZONE | --region=REGION]

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
  "updatePolicy": {
    "type": "PROACTIVE"
   }
}

Dopo aver inviato una richiesta, puoi monitorare l'aggiornamento per sapere quando è terminato.

Per le configurazioni avanzate, includi altre opzioni di aggiornamento. Se non specifichi diversamente, per impostazione predefinita le opzioni maxSurge e maxUnavailable sono equali a 1 moltiplicato per il numero di zone interessate. Ciò significa che solo un'istanza viene messa offline in ogni zona interessata e il gruppo di istanze gestite crea solo un'istanza aggiuntiva per zona durante l'aggiornamento.

Configurare le opzioni per l'aggiornamento

Per aggiornamenti più complessi, puoi configurare opzioni aggiuntive, come descritto nelle sezioni seguenti.

Tipo aggiornamento

I gruppi di istanze gestite supportano due tipi di aggiornamento:

• Aggiornamenti automatici o proattivi
• Aggiornamenti selettivi o opportunistici

Se vuoi applicare gli aggiornamenti automaticamente, imposta il tipo su proattivo.

In alternativa, se un aggiornamento automatico è potenzialmente troppo invasivo, puoi scegliere di eseguire un aggiornamento opportunistico. Il gruppo di istanze gestite applica un aggiornamento opportunistico solo quando avvii manualmente l'aggiornamento su istanze selezionate o quando vengono create nuove istanze. È possibile creare nuove istanze quando tu o un altro servizio, ad esempio un gestore della scalabilità automatica, modificate le dimensioni del gruppo di istanze gestite. Compute Engine non avvia attivamente richieste per applicare aggiornamenti opportunistici alle istanze esistenti.

Per ulteriori informazioni sugli aggiornamenti automatici rispetto a quelli selettivi, consulta la sezione Metodi per applicare una nuova configurazione alle VM esistenti.

Picco massimo

Utilizza l'opzione maxSurge per configurare il numero di nuove istanze che il gruppo di istanze gestite può creare sopra il suo targetSize durante un aggiornamento automatico. Ad esempio, se imposti maxSurge su 5, il gruppo di istanze gestite utilizza il nuovo modello di istanza per creare fino a 5 nuove istanze superiori alla dimensione target. L'impostazione di un valore maxSurge più elevato accelera l'aggiornamento, a costo di istanze aggiuntive, che vengono fatturate in base al listino prezzi di Compute Engine.

Puoi specificare un numero fisso o, se il gruppo ha almeno 10 istanze, una percentuale. Se imposti una percentuale, Updater arrotonda per eccesso il numero di istanze, se necessario.

Se non imposti il valore maxSurge, viene utilizzato il valore predefinito. Per i gruppi di istanze gestite a livello di zona, il valore predefinito per maxSurge è 1. Per i gruppi di istanze gestite regionali, il valore predefinito è il numero di zone associate al gruppo, ovvero 3.

maxSurge funziona solo se disponi di una quota o risorse sufficienti per supportare le risorse aggiuntive.

Se l'aggiornamento non richiede la sostituzione delle VM, questa opzione viene ignorata. Puoi forzare la sostituzione delle VM durante un aggiornamento impostando l'opzione Azione minima.

Numero massimo non disponibili

Utilizza l'opzione maxUnavailable per configurare il numero di istanze non disponibili in qualsiasi momento durante un aggiornamento automatico. Ad esempio, se imposti maxUnavailable su 5, solo 5 istanze vengono disattivate per l'aggiornamento alla volta. Utilizza questa opzione per controllare l'entità dell'interruzione del servizio causata dall'aggiornamento e per controllare la velocità di implementazione dell'aggiornamento.

Questo numero include anche le istanze non disponibili per altri motivi. Ad esempio, se il gruppo è in fase di ridimensionamento, le istanze in fase di creazione potrebbero non essere disponibili. Queste istanze vengono conteggiate nel numero maxUnavailable.

Puoi specificare un numero fisso o, se il gruppo ha almeno 10 istanze, una percentuale. Se imposti una percentuale, Updater arrotonda per difetto il numero di istanze, se necessario.

Se non vuoi che nessuna macchina non sia disponibile durante un aggiornamento, imposta il valore maxUnavailable su 0 e il valore maxSurge su un valore maggiore di 0. Con queste impostazioni, Compute Engine rimuove ogni vecchia macchina solo dopo che la nuova macchina sostitutiva è stata creata ed è in esecuzione.

Se non imposti il valore maxUnavailable, viene utilizzato il valore predefinito. Per i gruppi di istanze gestite zonali, il valore predefinito è 1. Per i gruppi di istanze gestite regionali, il valore predefinito è il numero di zone associate al gruppo, ovvero 3.

Tempo di attesa minimo

Utilizza l'opzione minReadySec per specificare il tempo di attesa prima di considerare un'istanza nuova o riavviata come aggiornata. Utilizza questa opzione per controllare la frequenza di implementazione dell'aggiornamento automatico. Il timer si avvia quando sono soddisfatte entrambe le seguenti condizioni:

• Lo stato dell'istanza è RUNNING.
• Se il controllo di integrità è abilitato, quando il controllo di integrità restituisce HEALTHY.

Tieni presente che, affinché il controllo di integrità restituisca un risultato positivo, Updater attende le seguenti condizioni:

1. Attende fino al periodo di tempo specificato dal valore autohealingPolicies.initialDelaySec del gruppo di istanze gestite affinché il controllo di integrità restituisca HEALTHY.
2. Quindi, attende il periodo di tempo specificato da minReadySec.

Se il controllo di integrità non restituisce HEALTHY entro initialDelaySec, l'Updater dichiara l'istanza VM non integra e potenzialmente interrompe l'aggiornamento. Mentre l'istanza VM è in attesa di verifica durante il periodo di tempo initialDelaySec e minReadySec, il valore currentAction dell'istanza è VERIFYING. Tuttavia, lo stato dell'istanza VM sottostante rimane RUNNING.

Se non sono presenti controlli di integrità per il gruppo, il timer si avvia quando lo stato dell'istanza è RUNNING.

Il valore massimo per il campo minReadySec è 3600 secondi (1 ora).

Il seguente diagramma mostra in che modo le opzioni relative alle dimensioni target, al numero massimo di istanze non disponibili, al picco massimo e al tempo di attesa minimo influiscono sulle istanze. Per ulteriori informazioni sulle dimensioni target, consulta Aggiornamenti Canary.

Azione minima

Utilizza l'opzione di azione minima per ridurre al minimo le interruzioni o per applicare un'azione più invasiva del necessario. Ad esempio, Compute Engine non deve riavviare una VM per modificarne i metadati. Tuttavia, se la tua applicazione legge i metadati dell'istanza solo quando una VM viene riavviata, puoi impostare l'azione minima su Riavvia per rilevare le modifiche ai metadati.

Se l'aggiornamento richiede un'azione più invasiva di quella impostata con questo flag, Compute Engine esegue l'azione necessaria per eseguire l'aggiornamento. Ad esempio, se specifichi un riavvio come azione minima, Updater tenta di riavviare le istanze per applicare l'aggiornamento. Tuttavia, se stai modificando il sistema operativo, cosa che non puoi fare riavviando l'istanza, il programma di aggiornamento sostituirà le istanze del gruppo con nuove istanze VM.

Per ulteriori informazioni, incluse le opzioni valide, consulta Controllare il livello di interruzione durante un aggiornamento progressivo.

Azione consentita più dannosa

Utilizza l'opzione di azione consentita più invasiva per impedire un aggiornamento se richiede più interruzioni di quante tu possa permetterti. Se non è possibile completare un aggiornamento a causa di questa impostazione, l'aggiornamento non va a buon fine e le VM mantengono la configurazione precedente.

Per ulteriori informazioni, consulta Controllare il livello di interruzione durante un aggiornamento progressivo.

Metodo di sostituzione

Per impostazione predefinita, quando aggiorni in modo proattivo un gruppo di istanze gestite, il gruppo elimina le istanze VM e le sostituisce con nuove istanze con nuovi nomi. Se devi mantenere i nomi delle istanze VM, utilizza l'opzione replacementMethod.

Conservare i nomi delle istanze esistenti potrebbe essere utile se hai applicazioni o sistemi che si basano sull'utilizzo di nomi di istanze specifici. Ad esempio, alcune applicazioni, come Memcached, si basano sui nomi delle istanze perché non dispongono di un servizio di rilevamento. Di conseguenza, ogni volta che un nome dell'istanza cambia, l'applicazione perde la connessione a quella VM specifica.

Per conservare i nomi delle istanze, imposta il metodo di sostituzione su RECREATE anziché su SUBSTITUTE se aggiorni il gruppo di istanze gestite con gcloud CLI o l'API Compute Engine. In alternativa, se aggiorni il gruppo di istanze gestite dalla console Google Cloud, seleziona la casella di controllo Mantieni i nomi delle istanze quando sostituisci le istanze.

I valori validi di replacementMethod sono:

• SUBSTITUTE (valore predefinito). Sostituisce le istanze VM più rapidamente durante gli aggiornamenti perché le nuove VM vengono create prima dell'arresto delle vecchie. Tuttavia, i nomi delle istanze non vengono conservati perché sono ancora in uso dalle vecchie istanze.

• RECREATE. Mantiene i nomi delle istanze durante un aggiornamento. Compute Engine rilascia il nome dell'istanza quando la vecchia VM viene arrestata. Quindi, Compute Engine crea una nuova istanza utilizzando lo stesso nome. Per utilizzare questa modalità, devi impostare maxSurge su 0.

Per ulteriori informazioni, consulta Preservare i nomi delle istanze.

Altri esempi di aggiornamento

Di seguito sono riportati alcuni esempi di riga di comando con opzioni di configurazione comuni.

Esegui un aggiornamento graduale di tutte le istanze VM, ma crea fino a 5 nuove istanze contemporaneamente al di sopra della dimensione target

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=5 \
    [--zone=ZONE | --region=REGION]

Esegui un aggiornamento in sequenza con al massimo 3 macchine non disponibili e un tempo di attesa minimo di 3 minuti prima di contrassegnare una nuova istanza come disponibile

gcloud beta compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --min-ready=3m \
    --max-unavailable=3 \
    [--zone=ZONE | --region=REGION]

Esegui un aggiornamento progressivo di tutte le istanze VM, ma crea fino al 10% di nuove istanze in più rispetto alle dimensioni target alla volta

Ad esempio, se hai 1000 istanze ed esegui il seguente comando, Updater crea fino a 100 istanze prima di iniziare a rimuovere le istanze che eseguono il modello di istanza precedente.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    --max-surge=10% \
    [--zone=ZONE | --region=REGION]

Aggiornamenti canary

Un aggiornamento canary è un aggiornamento applicato a un sottoinsieme di istanze nel gruppo. Con un aggiornamento canary, puoi testare nuove funzionalità o upgrade su un sottoinsieme random di istanze, anziché implementare un aggiornamento potenzialmente dannoso su tutte le istanze. Se un aggiornamento non sta procedendo correttamente, devi solo eseguire il rollback del sottoinsieme di istanze, riducendo al minimo l'interruzione per gli utenti.

Un aggiornamento canary è uguale a un aggiornamento in sequenza standard, tranne per il fatto che il numero di istanze da aggiornare è inferiore alle dimensioni totali del gruppo di istanze. Come per un aggiornamento progressivo standard, puoi configurare opzioni aggiuntive per controllare il livello di interruzione del servizio.

Avvio di un aggiornamento canary

Per avviare un aggiornamento canary, specifica fino a due versioni del modello di istanza, tipicamente un nuovo modello di istanza da utilizzare come canary e il modello di istanza corrente per le restanti istanze. Ad esempio, puoi specificare che il 20% delle tue istanze venga creato in base a NEW_INSTANCE_TEMPLATE mentre le altre istanze continuano a funzionare su OLD_INSTANCE_TEMPLATE. Non puoi specificare più di due modelli di istanze alla volta. NEW_INSTANCE_TEMPLATE può essere un modello di istanza regionale della stessa regione del tuo MIG o un modello di istanza globale.

Devi sempre specificare una dimensione target (targetSize) per la versione canary. Non puoi avviare un aggiornamento canary se ometti le dimensioni target per la versione canary. Ad esempio, se hai specificato che il 10% delle istanze deve essere utilizzato per il canarying, il 90% rimanente non viene modificato e utilizza il modello di istanza corrente.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=CURRENT_INSTANCE_TEMPLATE_NAME \
    --canary-version=template=NEW_TEMPLATE,target-size=SIZE \
    [--zone=ZONE | --region=REGION]

gcloud compute instance-groups managed rolling-action start-update example-mig \
    --version=template=example-template-A \
    --canary-version=template=example-template-B,target-size=10%

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE",
   "targetSize": {
    "[percent|fixed]": NUMBER|PERCENTAGE # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME"
  }
 ]
}

Per altre opzioni, consulta Configurare le opzioni per l'aggiornamento.

Dopo aver inviato una richiesta, puoi monitorare l'aggiornamento per sapere quando è terminato.

Aggiornamento in sequenza di un aggiornamento canary

Dopo aver eseguito un aggiornamento canary, puoi decidere se eseguire il commit dell'aggiornamento per il 100% del MIG o eseguire il rollback.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=NEW_TEMPLATE \
    [--zone=ZONE | --region=REGION]

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
"versions": [
   {
   "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE" # New instance template
   }
 ]
}

Aggiornamenti sul monitoraggio

Dopo aver avviato un aggiornamento, può essere necessario del tempo prima che il rollout della nuova configurazione sia completato in tutte le istanze interessate. Puoi monitorare l'avanzamento di un aggiornamento controllando quanto segue:

• Per verificare se tutte le VM hanno raggiunto la versione del modello di destinazione, visualizza lo stato del gruppo.
• Per verificare che VM specifiche abbiano raggiunto la versione del modello di destinazione, visualizza le azioni correnti sulle istanze.
• Per i gruppi di istanze gestite stateful, consulta anche Verificare se sono state applicate configurazioni per istanza.

Stato del gruppo

A livello di gruppo, Compute Engine compila un campo di sola lettura chiamato status che contiene un flag versionTarget.isReached e un flag isStable. Puoi utilizzare gcloud CLI o REST per accedere a questi flag. Puoi anche utilizzare la console Google Cloud per visualizzare il numero corrente e pianificato di istanze in fase di aggiornamento.

gcloud compute instance-groups managed describe INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

gcloud compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --version-target-reached \
    [--zone=ZONE | --region=REGION]

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME/get

Verificare se l'implementazione di un aggiornamento è completa

Verifica se l'implementazione di un aggiornamento è completa controllando il valore del campo status.versionTarget.isReached del MIG:

• status.versionTarget.isReached impostato su true indica che tutte le istanze VM sono state o stanno per essere create utilizzando la versione di destinazione.

• status.versionTarget.isReached impostato su false indica che almeno una VM non utilizza ancora la versione di destinazione. In alternativa, nel caso di un aggiornamento canary, false indica che il numero di VM che utilizzano una versione target non corrisponde alle sue dimensioni target.

Verificare se un gruppo di istanze gestite è stabile

status.isStable impostato su false indica che le modifiche sono attive, in attesa o che il MIG stesso è in fase di modifica.

status.isStable impostato su true indica quanto segue:

• Nessuna delle istanze nel gruppo di istanze gestite (MIG) è soggetta a alcun tipo di modifica e il valore currentAction per tutte le istanze è NONE.
• Non sono presenti modifiche in attesa per le istanze nel gruppo di istanze gestite.
• Il MIG stesso non viene modificato.

Ricorda che la stabilità di un gruppo di istanze gestite dipende da numerosi fattori, in quanto un gruppo di istanze gestite può essere modificato in diversi modi. Ad esempio:

• Invii una richiesta di implementazione di un nuovo modello di istanza.
• Invii una richiesta per creare, eliminare, ridimensionare o aggiornare le istanze nel MIG.
• Un gestore della scalabilità automatica richiede di ridimensionare il MIG.
• Una risorsa di riparazione automatica sta sostituendo una o più istanze non attive nel gruppo di istanze gestite.
• In un gruppo di istanze gestite a livello di regione, alcune istanze vengono ridistribuite.

Una volta completate tutte le azioni, status.isStable viene impostato di nuovo su true per quel MIG.

Azioni correnti sulle istanze

Utilizza Google Cloud CLI o REST per visualizzare i dettagli delle istanze in un gruppo di istanze gestite. I dettagli includono lo stato delle istanze e le azioni correnti svolte dal gruppo sulle sue istanze.

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING                 NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING                 NONE      my-old-template

gcloud compute instance-groups managed describe-instance INSTANCE_GROUP_NAME \
    --instance INSTANCE_NAME \
    [--zone=ZONE | --region=REGION]

currentAction: NONE
id: '6789072894767812345'
instance: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/instances/example-mig-hz41
instanceStatus: RUNNING
name: example-mig-hz41
preservedStateFromConfig:
  metadata:
    example-key: example-value
preservedStateFromPolicy:
  disks:
    persistent-disk-0:
      autoDelete: NEVER
      mode: READ_WRITE
      source: https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-a/disks/example-mig-hz41
version:
  instanceTemplate: https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME/listManagedInstances

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/example-project/zones/us-central1-f/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/example-project/global/instanceTemplates/example-template",
   "currentAction": "REFRESHING"
  }
 ]
}

Per visualizzare un elenco dei valori validi del campo instanceStatus, consulta Ciclo di vita delle istanze VM.

Se un'istanza è in fase di modifica, il gruppo di istanze gestite imposta il campo currentAction dell'istanza su una delle seguenti azioni per aiutarti a monitorare l'avanzamento della modifica. In caso contrario, il campo currentAction viene impostato su NONE.

I valori possibili di currentAction sono:

• ABANDONING. L'istanza viene rimossa dal gruppo di istanze gestite.
• CREATING. L'istanza è in fase di creazione.
• CREATING_WITHOUT_RETRIES. L'istanza viene creata senza tentativi di ripetizione. Se l'istanza non viene creata al primo tentativo, il gruppo di istanze gestite non tenta di sostituirla di nuovo.
• DELETING. L'istanza è in fase di eliminazione.
• RECREATING. L'istanza verrà sostituita.
• REFRESHING. L'istanza viene rimossa dai pool di destinazione attuali e aggiunta nuovamente all'elenco dei pool di destinazione attuali (questo elenco potrebbe essere uguale o diverso dai pool di destinazione esistenti).
• RESTARTING. L'istanza è in fase di riavvio utilizzando i metodi stop e start.
• RESUMING. L'istanza è in fase di ripristino dopo essere stata sospesa.
• STARTING. L'istanza è in fase di avvio dopo essere stata bloccata.
• STOPPING. L'istanza è in fase di arresto.
• SUSPENDING. L'istanza è in fase di sospensione.
• VERIFYING. L'istanza è stata creata ed è in corso la verifica.
• NONE. Non vengono eseguite azioni sull'istanza.

Eseguire il rollback di un aggiornamento

Non esiste un comando esplicito per eseguire il rollback di un aggiornamento a una versione precedente, ma se decidi di eseguire il rollback di un aggiornamento (un aggiornamento completamente impegnato o un aggiornamento canary), puoi farlo inviando una nuova richiesta di aggiornamento e passando il modello di istanza a cui vuoi eseguire il rollback.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --version=template=OLD_INSTANCE_TEMPLATE_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME

{
  "updatePolicy":
  {
    "maxUnavailable":
    {
      "percent": 100
    }
  },
  "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/OLD_INSTANCE_TEMPLATE_NAME" # Old instance template
    }
  ]
}

Updater tratta una richiesta di rollback come una normale richiesta di aggiornamento, quindi puoi specificare opzioni di aggiornamento aggiuntive.

Interrompere un aggiornamento

Non esiste un metodo o un comando esplicito per interrompere un aggiornamento. Puoi modificare un aggiornamento da proattivo a opportunistico e, se il gruppo non viene ridimensionato da altri servizi come l'autoscalabilità, la modifica a opportunistico interrompe effettivamente l'aggiornamento.

Per modificare un aggiornamento da proattivo a opportunistico utilizzando gcloud CLI, esegui il seguente comando:

gcloud compute instance-groups managed rolling-action stop-proactive-update INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Per interrompere completamente l'aggiornamento dopo averlo convertito da proattivo a opportunistico:

1. Fai una richiesta per determinare quante istanze sono state aggiornate:

   gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
      [--zone=ZONE | --region=REGION]

   Gcloud CLI restituisce una risposta che include un elenco di istanze nel gruppo e i relativi stati correnti:

   NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
   vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      example-new-template
   vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      example-old-template
   vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  example-new-template
   

   In questo esempio, due istanze sono già state aggiornate.

2. A questo punto, effettua una richiesta per eseguire un nuovo aggiornamento, ma passa il numero di istanze già aggiornate come dimensione target:

   gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
      --version template=OLD_INSTANCE_TEMPLATE_NAME \
      --canary-version template=NEW_INSTANCE_TEMPLATE_NAME,target-size=2 \
      [--zone=ZONE | --region=REGION]

   Per Updater, questo aggiornamento sembra completo, quindi non vengono aggiornate altre istanze, interrompendo di fatto l'aggiornamento.

Controllare la velocità di un aggiornamento in sequenza

Per impostazione predefinita, quando effettui una richiesta di aggiornamento, Updater esegue l'aggiornamento il più rapidamente possibile. Se non hai la certezza di voler applicare completamente un aggiornamento o se stai testando in via sperimentale le modifiche, puoi controllare la velocità dell'aggiornamento utilizzando i seguenti metodi.

1. Avvia un aggiornamento canary anziché un aggiornamento completo.
2. Imposta un valore elevato per minReadySec. L'impostazione di questo valore fa in modo che Updater attenda questo numero di secondi prima di considerare l'istanza aggiornata correttamente e di passare all'istanza successiva.
3. Abilita il controllo di integrità per fare in modo che Updater attenda l'avvio dell'applicazione e registri un segnale di integrità prima di considerare l'istanza aggiornata correttamente e procedere con l'istanza successiva.
4. Imposta valori bassi per maxUnavailable e maxSurge. In questo modo, viene aggiornato solo un numero minimo di istanze alla volta.
5. Aggiornare in modo selettivo le istanze in un gruppo di istanze gestite instead of using an automated update.

Puoi anche utilizzare una combinazione di questi metodi per controllare la frequenza dell'aggiornamento.

Controllo del livello di interruzione durante un aggiornamento in sequenza

A seconda della natura di un aggiornamento, l'stato del ciclo di vita di un'istanza potrebbe essere interrotto. Ad esempio, la modifica del disco di avvio di un'istanza richiede la sostituzione dell'istanza. Puoi controllare il livello di interruzione durante un aggiornamento in sequenza impostando le seguenti opzioni:

• Azione minima: utilizza questa opzione per ridurre al minimo l'interruzione o per applicare un'azione più invasiva del necessario.

  • Per limitare il più possibile l'interruzione, imposta l'azione minima su REFRESH. Se l'aggiornamento richiede un'azione più invasiva, Compute Engine esegue l'azione necessaria per eseguire l'aggiornamento.
  • Per applicare un'azione più dannosa del necessario, imposta l'azione minima su RESTART o REPLACE. Ad esempio, Compute Engine non deve riavviare una VM per modificarne i metadati. Tuttavia, se la tua applicazione legge i metadati dell'istanza solo quando viene riavviata una VM, puoi impostare l'azione minima su RESTART per rilevare le modifiche ai metadati.

• Azione consentita più invasiva: utilizza questa opzione per impedire un aggiornamento se richiede più interruzioni di quante tu possa permetterti. Se l'aggiornamento richiede un'azione più invasiva di quella impostata con questo flag, la richiesta di aggiornamento non va a buon fine. Ad esempio, se imposti l'azione consentita più dannosa su RESTART, un tentativo di aggiornare l'immagine del disco di avvio non va a buon fine perché l'aggiornamento richiede la sostituzione dell'istanza, un'azione più dannosa di un riavvio.

Entrambe le opzioni accettano i seguenti valori:

L'azione più invasiva consentita non può essere meno invasiva dell'azione minima.

Quando implementi automaticamente gli aggiornamenti, si applicano le seguenti impostazioni predefinite:

• L'azione minima predefinita è REPLACE. Se vuoi evitare interruzioni non necessarie, imposta l'azione minima in modo che sia meno invasiva.
• L'azione predefinita più dannosa consentita è REPLACE. Se non puoi tollerare questo tipo di interruzione, imposta l'azione consentita più invasiva in modo che sia meno invasiva.

Puoi modificare il comportamento predefinito utilizzando l'API Compute Engine per impostare i campi updatePolicy.minimalAction e updatePolicy.mostDisruptiveAllowedAction nella risorsa MIG, ad esempio chiamando il metodo regionInstanceGroupManagers.patch. In alternativa, puoi selezionare le azioni consentite per aggiornare le VM specifiche quando aggiorni il tuo MIG dalla console Google Cloud. Per visualizzare le impostazioni correnti, consulta Ottenere le proprietà di un gruppo di istanze gestite.

Un aggiornamento non va a buon fine se richiede un'azione più invasiva di quella consentita. In questo caso, puoi riprovare a eseguire l'aggiornamento con un'azione consentita più invasiva oppure puoi aggiornare l'istanza in modo selettivo. Compute Engine esegue una convalida secondo il criterio del massimo impegno per verificare se le istanze possono essere aggiornate con il limite di interruzione specificato. Tuttavia, a causa di modifiche simultanee nel sistema, la situazione può cambiare dopo l'avvio dell'aggiornamento. Se un'operazione su una determinata istanza non riesce, elenca gli errori dell'istanza per visualizzare l'errore.

Eseguire una sostituzione o un riavvio graduale

Un riavvio graduale interrompe e riavvia tutte le istanze, mentre una sostituzione graduale sostituisce le istanze in base all'opzione Metodo di sostituzione. Un riavvio o una sostituzione graduale non modificano nessun altro aspetto del gruppo, incluso il modello di istanza.

Esistono molti motivi per cui potresti voler eseguire un riavvio o un remplacement graduale. Ad esempio, potresti voler riavviare o sostituire le istanze VM di volta in volta per uno dei seguenti motivi:

• Risolvere le perdite di memoria.
• Riavvia l'applicazione in modo che possa essere eseguita da una nuova macchina.
• Applica una sostituzione periodica come best practice per testare le VM.
• Aggiorna l'immagine del sistema operativo della VM o esegui di nuovo gli script di avvio per aggiornare il software.

Utilizza la console Google Cloud, Google Cloud CLI o REST per eseguire un riavvio o una sostituzione.

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

PATCH https://compute.googleapis.com/compute/v1/projects/example-project/zones/ZONE/instanceGroupManagers/INSTANCE_GROUP_NAME

{
 "updatePolicy": {
  "minimalAction": "RESTART",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/CURRENT_INSTANCE_TEMPLATE_NAME",
   "name": "v2-1705499403"
  }
 ]
}

Altri esempi di sostituzione/riavvio

Esegui un riavvio graduale di tutte le VM, due alla volta

Questo comando riavvia tutte le VM del gruppo, due alla volta. Tieni presente che non è specificato alcun nuovo modello di istanza.

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=2 \
    [--zone=ZONE | --region=REGION]

Esegui un riavvio graduale di tutte le VM il più rapidamente possibile

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Esegui una sostituzione in sequenza di tutte le VM il più rapidamente possibile

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME  \
    --max-unavailable=100% \
    [--zone=ZONE | --region=REGION]

Preservare i nomi delle istanze

Se devi conservare i nomi delle istanze VM durante un aggiornamento, imposta replacementMethod su RECREATE. Devi anche impostare maxUnavailable su un valore maggiore di 0 e maxSurge su 0. La ricreazione delle istanze anziché la loro sostituzione comporta un tempo di completamento dell'aggiornamento più lungo, ma le istanze aggiornate mantengono i nomi.

Se non specifichi un metodo di sostituzione, viene utilizzato il valore updatePolicy.replacementMethod corrente del gruppo di istanze gestite. Se non è impostato, viene utilizzato il valore predefinito substitute, che sostituisce le istanze VM con nuove istanze con nomi generati in modo casuale.

gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
    --replacement-method=recreate \
    --version=template=NEW_TEMPLATE \
    --max-unavailable=5 \
    [--zone=ZONE | --region=REGION]

PATCH /compute/v1/projects/PROJECT_ID/regions/REGION/instanceGroupManagers/INSTANCE_GROUP_NAME
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/NEW_TEMPLATE"
    } ]
}

Dopo aver inviato una richiesta, puoi monitorare l'aggiornamento per sapere quando è terminato.

Aggiornamento di un gruppo di istanze gestite regionale

Un gruppo di istanze gestite a livello di regione contiene istanze VM distribuite in più zone all'interno di una regione, diversamente da un gruppo di istanze gestite a livello di zona, che contiene solo istanze in una zona. I MIG regionali ti consentono di distribuire le istanze in più di una zona per migliorare la disponibilità dell'applicazione e per supportare casi estremi in cui una zona non funziona o un intero gruppo di istanze smette di rispondere.

Eseguire un aggiornamento su un gruppo di istanze gestite a livello di regione è come eseguire un aggiornamento su un gruppo di istanze gestite a livello di zona, con alcune eccezioni descritte di seguito. Quando avvii un aggiornamento di un MIG regionale, Updater aggiorna sempre le istanze in modo proporzionale e uniforme in ogni zona. Non puoi scegliere quali istanze in quali zone devono essere aggiornate per prime né puoi scegliere di aggiornare le istanze in una sola zona.

Differenze tra l'aggiornamento dei MIG a livello di regione e a livello di zona

I MIG a livello di area geografica hanno i seguenti valori di aggiornamento predefiniti:

• maxUnavailable=NUMBER_OF_ZONES
• maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES è il numero di zone associate al MIG regionale. Per impostazione predefinita, il numero di zone per un gruppo di istanze gestite a livello di regione è 3. Tuttavia, puoi selezionare un numero diverso.

Se utilizzi numeri fissi per specificare un aggiornamento, il numero fisso deve essere 0 o uguale o maggiore al numero di zone associate al gruppo di istanze gestite regionale. Ad esempio, se il gruppo è distribuito su tre zone, non puoi impostare maxSurge su 1 o 2 perché l'Updater deve creare un'istanza aggiuntiva in ciascuna delle tre zone.

Utilizzo di un numero fisso o di una percentuale nelle richieste di aggiornamento

Se specifichi un numero fisso nelle richieste di aggiornamento, questo viene diviso per il numero di zone nel gruppo di istanze gestite a livello di regione e distribuito in modo uniforme. Ad esempio, se specifichi maxSurge=10, l'aggiornamento divide 10 per il numero di zone nella regione e crea istanze in base a questo numero. Se il numero di istanze non si suddivide equamente tra le zone, l'aggiornamento aggiunge le istanze rimanenti a una zona casuale. Pertanto, per 10 istanze su tre zone, due delle zone ricevono 3 istanze e una zona ne riceve 4. La stessa logica viene applicata ai parametri maxUnavailable e targetSize per gli aggiornamenti canary.

Puoi specificare una percentuale solo se il MIG contiene almeno 10 istanze VM. Le percentuali vengono gestite in modo leggermente diverso a seconda della situazione:

• Se specifichi una percentuale di istanze VM per un aggiornamento canary, Updater tenta di distribuire le istanze in modo uniforme tra le zone. Il resto viene arrotondato per eccesso o per difetto in ogni zona, ma la differenza totale non è superiore a 1 istanza VM per gruppo. Ad esempio, per un gruppo di istanze gestite con 10 istanze e una percentuale di dimensioni target del 25%, l'aggiornamento viene implementato su 2-3 istanze VM.

• Se specifichi una percentuale per le opzioni di aggiornamento come maxSurge e maxUnavailable, le percentuali vengono arrotondate in modo indipendente per zona.

Passaggi successivi

• Scopri di più su come visualizzare le informazioni su MIG e istanze gestite.
• Scopri di più sulla creazione di modelli di istanze.
• Scopri come utilizzare le famiglie di immagini e una sostituzione graduale per aggiornare l'immagine del sistema operativo su tutte le VM di un gruppo di istanze gestite.