Aktualisierungen von VM-Konfigurationen in einer MIG automatisch anwenden

---

In diesem Dokument wird beschrieben, wie Sie Konfigurationsaktualisierungen automatisch auf die VM-Instanzen in einer verwalteten Instanzgruppe (Managed Instance Group, MIG) anwenden.

Compute Engine verwaltet die VMs in einer MIG anhand der von Ihnen verwendeten Konfigurationskomponenten: Instanzvorlage, optionale Instanzkonfiguration und optionale zustandsorientierte Konfiguration.

Wenn Sie die VM-Konfiguration einer MIG durch Ändern dieser Komponenten aktualisieren, wendet Compute Engine die aktualisierte Konfiguration automatisch auf neue VMs an, die der Gruppe hinzugefügt werden.

Sie können eine automatische Aktualisierung (auch als proaktiver Aktualisierungstyp bezeichnet) einrichten, um eine aktualisierte Konfiguration auf vorhandene VMs anzuwenden. Die MIG führt Konfigurationsaktualisierungen automatisch für alle oder einen Teil der VMs der Gruppe aus. Sie können die Geschwindigkeit der Bereitstellung, die Unterbrechungsmaß Ihres Dienstes und, mithilfe eines Canary-Updates, die Anzahl der Instanzen, die die MIG mit der neuen Konfiguration aktualisiert, steuern. Nachdem Sie die neue Konfiguration angegeben haben, müssen Sie keine zusätzliche Eingabe machen und die Aktualisierung wird von selbst abgeschlossen.

Wenn Sie eine neue Konfiguration nur selektiv auf neue oder bestimmte Instanzen in einer MIG anwenden möchten, finden Sie weitere Informationen unter Aktualisierungen der VM-Konfiguration in einer MIG selektiv anwenden. Weitere Informationen finden Sie unter Methoden zum Anwenden einer neuen Konfiguration auf vorhandene VMs.

Hinweise

• Wenn Sie eine zustandsorientierte MIG aktualisieren, lesen Sie den Abschnitt Zustandsorientierte Konfiguration in MIGs anwenden, aufrufen und entfernen.
• Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud-Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich wie folgt bei Compute Engine authentifizieren.
  

  Wählen Sie den Tab für die Verwendung der Beispiele auf dieser Seite aus:

  Console

  Wenn Sie über die Google Cloud Console auf Google Cloud-Dienste und -APIs zugreifen, müssen Sie die Authentifizierung nicht einrichten.

  gcloud

  1. Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl:

     gcloud init

     Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die neueste Version haben, indem Sie gcloud components update ausführen.
  2. Legen Sie eine Standardregion und -zone fest.

  REST

  Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.

  Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl:

  gcloud init

Beschränkungen

• Wenn Sie eine zustandsorientierte MIG haben und automatisierte Rolling Updates verwenden möchten, müssen Sie die Instanznamen beibehalten, wenn Sie Instanzen ersetzen, oder entsprechend die Ersatzmethode auf RECREATE setzen.

Grundlegendes Rolling Update starten

Ein Basic-Rolling Update ist ein Update, das nach und nach auf alle Instanzen in einer MIG angewendet wird, bis alle Instanzen auf die neueste beabsichtigte Konfiguration aktualisiert wurden. Beim Rolling Update werden automatisch Instanzen übersprungen, die bereits die aktuellste Konfiguration haben.

Sie können verschiedene Aspekte eines Rolling Updates steuern, beispielsweise wie viele Instanzen für die Aktualisierung offline gehen, wie lange zwischen dem Aktualisieren der einzelnen Instanzen gewartet wird, ob die neue Vorlage alle oder nur einen Teil der Instanzen betrifft usw.

Das sollten Sie bei einem Rolling Update bedenken:

• Die Updates sind zuerst nur geplant. Wenn Sie eine Updateanfrage stellen, gibt die Compute Engine API eine erfolgreiche Antwort zurück, um die Gültigkeit der Anfrage zu bestätigen. Das bedeutet jedoch nicht, dass das Update erfolgreich war. Sie müssen den Status der Gruppe prüfen, um herauszufinden, ob das Update erfolgreich bereitgestellt wurde.

• Die Instance Group Updater API ist eine deklarative API. Die API erwartet eine Anfrage, die angibt, wie die gewünschte Konfiguration der verwalteten Instanzgruppe nach dem Update aussehen soll; sie erwartet keinen Funktionsaufruf.

• Automatisierte Updates unterstützen bis zu zwei Instanzvorlagenversionen in Ihrer MIG. Sie können also zwei unterschiedliche Instanzvorlagenversionen für Ihre Gruppe angeben, was für Canary Updates hilfreich ist.

Folgen Sie der nachstehenden Anleitung, um ein Basic-Rolling Update zu starten, das auf alle Instanzen in der Gruppe angewendet wird.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• Für zonale MIGs benötigen Sie alle Berechtigungen, um die Methode instanceGroupManagers.patch aufzurufen.
• Bei regionalen MIGs benötigen Sie alle Berechtigungen, die zum Aufrufen der Methode regionInstanceGroupManagers.patch erforderlich sind.

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Wählen Sie die MIG aus, die Sie aktualisieren möchten.

3. Klicken Sie auf VMs aktualisieren.

4. Klicken Sie unter Neue Vorlage auf die Drop-down-Liste und wählen Sie die neue Vorlage aus, auf die Sie aktualisieren möchten. Die Zielgröße wird automatisch auf 100 % festgelegt. Dies bedeutet, dass alle Instanzen aktualisiert werden.

5. Maximieren Sie unter Konfiguration aktualisieren das Auswahlmenü und wählen Sie als Aktualisierungstyp die Option Automatisch aus. Behalten Sie für die anderen Optionen die Standardwerte bei.

6. Klicken Sie auf VMs aktualisieren, um das Update zu starten.

gcloud

Führen Sie den Befehl rolling-action start-update aus.

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

Dabei gilt:

• INSTANCE_GROUP_NAME: Name der MIG.
• INSTANCE_TEMPLATE_NAME ist die neue Instanzvorlage
• ZONE: Geben Sie bei zonalen MIGs die Zone an.
• REGION: Geben Sie bei regionalen MIGs die Region an.

REST

Rufen Sie die Methode patch für eine regionale oder zonale MIG-Ressource auf.

Die folgende Anfrage zeigt beispielsweise bei einer regionalen MIG die Mindestkonfiguration an, die erforderlich ist, um alle Instanzen automatisch auf die neue Instanzvorlage zu aktualisieren.

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

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

Nachdem Sie die Anfrage gestellt haben, können Sie das Update überwachen, damit Sie wissen, wann die Aktualisierung beendet ist.

Fügen Sie für erweiterte Konfigurationen weitere Aktualisierungsoptionen hinzu. Wenn Sie nichts anderes angeben, werden die Optionen maxSurge und maxUnavailable standardmäßig auf 1 gesetzt, multipliziert mit der Anzahl der betroffenen Zonen. Das bedeutet, dass während der Aktualisierung immer nur eine Instanz in jeder betroffenen Zone offline geht und die MIG nur eine zusätzliche Instanz pro Zone erstellt.

Optionen für das Update konfigurieren

Für komplexere Updates können Sie wie in den folgenden Abschnitten beschrieben weitere Optionen konfigurieren.

Art der Aktualisierung

Verwaltete Instanzgruppen unterstützen zwei Arten von Aktualisierungsmodus:

• Automatische (proaktive) Aktualisierungen
• Selektive (opportunistische) Aktualisierungen

Wenn Sie Aktualisierungen automatisch anwenden möchten, wählen Sie den Modus proaktiv aus.

Wenn eine automatische Aktualisierung potenziell zu störend ist, können Sie auch eine opportunistische Aktualisierung vornehmen. Die MIG wendet eine opportunistische Aktualisierung nur an, wenn Sie die Aktualisierung für ausgewählte Instanzen manuell starten oder wenn neue Instanzen erstellt werden. Neue Instanzen können erstellt werden, wenn Sie oder ein anderer Dienst, z. B. Autoscaling, die Größe der MIG anpassen. Compute Engine startet keine aktiven Anfragen, um opportunistische Updates für vorhandene Instanzen anzuwenden.

Weitere Informationen zu automatischen und selektiven Updates finden Sie unter Methoden zum Anwenden einer neuen Konfiguration auf vorhandene VMs.

Maximaler Spitzenwert

Mit der Option maxSurge konfigurieren Sie, wie viele neue Instanzen die MIG bei einer automatischen Aktualisierung oberhalb ihrer targetSize erstellen kann. Wenn Sie beispielsweise maxSurge auf 5 festlegen, verwendet die MIG die neue Instanzvorlage, um bis zu fünf neue Instanzen über der Zielgröße zu erstellen. Durch einen höheren Wert für maxSurge können Sie die Aktualisierung beschleunigen. Dabei werden Ihnen die zusätzlichen Instanzen gemäß der Preisliste für Compute Engine in Rechnung gestellt.

Sie können entweder eine feste Anzahl angeben oder, falls die verwaltete Instanzgruppe mindestens 10 Instanzen umfasst, einen Prozentsatz. Wenn Sie einen Prozentsatz festlegen, rundet der Updater bei Bedarf die Anzahl von Instanzen auf.

Wenn Sie den Wert maxSurge nicht festlegen, wird der Standardwert verwendet. Für zonale MIGs ist die Standardeinstellung für maxSurge 1. Bei regionalen MIGs ist die Standardeinstellung die Anzahl der Zonen, die der Gruppe zugeordnet sind, also 3.

maxSurge funktioniert nur, wenn Sie genügend Kontingente oder Ressourcen zur Unterstützung der zusätzlichen Ressourcen haben.

Wenn für Ihr Update kein Ersetzen der VMs erforderlich ist, wird diese Option ignoriert. Sie können erzwingen, dass VMs während eines Updates ersetzt werden, indem Sie die Option Mindestaktion festlegen.

Maximal nicht verfügbar

Mit der Option maxUnavailable konfigurieren Sie, wie viele Instanzen während einer automatischen Aktualisierung nicht verfügbar sind. Wenn Sie beispielsweise für maxUnavailable 5 festlegen, werden jeweils nur fünf Instanzen zur Aktualisierung offline genommen. Mit diesem Parameter können Sie steuern, wie stark Ihr Dienst durch das Update gestört wird und wie schnell die Aktualisierung bereitgestellt wird.

Die Zahl beinhaltet auch Instanzen, die aus anderen Gründen nicht verfügbar sind. Wenn beispielsweise eine Gruppe gerade neu skaliert wird, sind Instanzen, die gerade erstellt werden, möglicherweise nicht verfügbar. Diese Instanzen werden auf die maxUnavailable-Nummer angerechnet.

Sie können eine feste Anzahl angeben oder, falls die verwaltete Instanzgruppe mindestens 10 Instanzen umfasst, einen Prozentsatz. Wenn Sie einen Prozentsatz festlegen, rundet der Updater bei Bedarf die Anzahl von Instanzen ab.

Wenn Sie während einer Aktualisierung keine nicht verfügbaren Maschinen angeben möchten, setzen Sie den Wert maxUnavailable auf 0 und den Wert maxSurge auf größer als 0. Mit diesen Einstellungen entfernt Compute Engine jede alte Maschine erst, wenn die neue Maschine erstellt ist und ausgeführt wird.

Wenn Sie den Wert maxUnavailable nicht festlegen, wird der Standardwert verwendet. Für zonale MIGs ist die Standardeinstellung 1. Bei regionalen MIGs ist die Standardeinstellung die Anzahl der Zonen, die der Gruppe zugeordnet sind, also 3.

Hinweis: Wenn Sie für beide Attribute maxSurge und maxUnavailable den Wert 0 festlegen, korrigiert der Updater dies automatisch auf maxUnavailable=1, damit die automatisierte Aktualisierung durchgeführt werden kann.

Mindestwartezeit

Hinweis: minReadySec ist nur in der Beta-Version der Compute Engine API nutzbar und steht daher in zukünftigen Releases möglicherweise nicht mehr zur Verfügung.

Mit der Option minReadySec legen Sie fest, wie lange gewartet wird, bis eine neue oder neu gestartete Instanz als aktualisiert gilt. Mit dieser Option können Sie die Geschwindigkeit steuern, mit der das automatische Update bereitgestellt wird. Der Timer startet, wenn die beiden folgenden Bedingungen erfüllt sind:

• Der Status der Instanz ist RUNNING.
• Wenn die Systemdiagnose aktiviert ist, wird der Wert HEALTHY zurückgegeben.

Damit die Systemdiagnose fehlerfrei ausgeführt wird, wartet der Updater auf die folgenden Bedingungen:

1. Wartet auf den Zeitraum, der vom autohealingPolicies.initialDelaySec-Wert der MIG angegeben wurde, damit die Systemdiagnose als HEALTHY zurückgegeben wird.
2. Die durch minReadySec festgelegte Zeit.

Wenn die Systemdiagnose nicht innerhalb von initialDelaySec den Status HEALTHY zurückgibt, interpretiert der Updater die VM-Instanz als fehlerhaft und beendet die Aktualisierung möglicherweise. Während die VM-Instanz in den durch initialDelaySec und minReadySec festgelegten Zeiträumen geprüft wird, hat die currentAction der Instanz den Status VERIFYING. Der zugrunde liegende VM-Instanzstatus bleibt jedoch RUNNING.

Wenn keine Systemdiagnosen für die Gruppe durchgeführt werden, startet der Timer, sobald die Instanz den Status RUNNING hat.

Der Höchstwert für das Feld minReadySec sind 3.600 Sekunden (1 Stunde).

Das folgende Diagramm zeigt, wie sich die Optionen "Zielgröße", "Maximal nicht verfügbar", "Maximaler Spitzenwert" und "Mindestwartezeit" auf Ihre Instanzen auswirken. Weitere Informationen zur Zielgröße finden Sie unter Canary Updates.

Mindestaktion

Verwenden Sie die Option „Mindestaktion“, um Unterbrechungen so weit wie möglich zu minimieren oder um eine umfangreichere Aktion als erforderlich anzuwenden. So muss Compute Engine zum Beispiel keine VM neu starten, um die Metadaten zu ändern. Wenn Ihre Anwendung Instanzmetadaten nur beim Neustart einer VM liest, können Sie die Mindestaktion auf Neustart festlegen, um Metadatenänderungen zu übernehmen.

Wenn ein Update eine umfassendere Aktion erfordert, als Sie mit diesem Flag festgelegt haben, führt Compute Engine die Aktion aus, die notwendig ist, um das Update auszuführen. Wenn Sie beispielsweise einen Neustart als Mindestaktion angeben, versucht der Updater, Instanzen neu zu starten, um das Update anzuwenden. Wenn Sie jedoch das Betriebssystem ändern, was nicht durch einen Neustart der Instanz möglich ist, ersetzt der Updater die VM-Instanzen der Gruppe durch neue.

Weitere Informationen und gültige Optionen finden Sie unter Unterbrechungsmaß während eines Rolling Updates steuern.

Umfangreichste erlaubte Aktion

Verwenden Sie die Option mit der umfangreichsten erlaubten Aktion, um ein Update zu verhindern, wenn es zu einer größeren Unterbrechung führen würde, als tragbar ist. Wenn ein Update aufgrund dieser Einstellung nicht abgeschlossen werden kann, schlägt die Aktualisierung fehl und Ihre VMs behalten ihre vorherige Konfiguration bei.

Weitere Informationen finden Sie unter Unterbrechungsmaß während eines Rolling Updates steuern.

Ersetzungsmethode

Wenn Sie eine MIG proaktiv aktualisieren, löscht die Gruppe standardmäßig Ihre VM-Instanzen und tauscht sie gegen neue Instanzen mit neuen Namen aus. Wenn Sie die Namen Ihrer VM-Instanzen beibehalten möchten, verwenden Sie die Option replacementMethod.

Das Beibehalten vorhandener Instanznamen kann nützlich sein, wenn Sie Anwendungen oder Systeme haben, die von der Verwendung bestimmter Instanznamen abhängig sind. Einige Anwendungen, z. B. Memcached, benötigen Instanznamen, da sie keinen Discovery-Dienst haben. Daher verliert die Anwendung bei jeder Änderung eines Instanznamens die Verbindung zu dieser bestimmten VM.

Damit Instanznamen beibehalten werden, legen Sie für die Ersetzungsmethode RECREATE anstelle von SUBSTITUTE fest, wenn Sie die MIG mit der gcloud CLI oder der Compute Engine API aktualisieren. Wenn Sie die MIG über die Google Cloud Console aktualisieren, klicken Sie alternativ das Kästchen Instanznamen beim Ersetzen von Instanzen beibehalten an.

Gültige Werte für replacementMethod sind:

• SUBSTITUTE (Standard) Ersetzt VM-Instanzen während Aktualisierungen schneller, da neue VMs erstellt werden, bevor alte VMs heruntergefahren werden. Instanznamen werden jedoch nicht beibehalten, da die Namen noch von den alten Instanzen verwendet werden.

• RECREATE. Behält Instanznamen während einer Aktualisierung bei. Compute Engine gibt den Instanznamen frei, wenn die alte VM heruntergefahren wird. Anschließend erstellt Compute Engine eine neue Instanz mit diesem Namen. Für diesen Modus müssen Sie für maxSurge den Wert 0 festlegen.

Hinweis: Wenn Sie die Ersetzungsmethode auf RECREATE festlegen, wird der Instanzname beibehalten. Die Instanz-ID und der Erstellungszeitstempel können sich jedoch ändern. Um zu bestätigen, dass der RECREATE-Vorgang eine neue Instanz erstellt hat, wenn sich der Zeitstempel der Instanzerstellung nicht geändert hat, prüfen Sie den Zeitstempel der Erstellung des Bootlaufwerks, das dieser Instanz zugeordnet ist.

Weitere Informationen finden Sie unter Instanznamen beibehalten.

Weitere Aktualisierungsbeispiele

Hier sehen Sie einige Befehlszeilenbeispiele mit üblichen Konfigurationsoptionen:

Rolling Update aller VM-Instanzen mit bis zu fünf neuen Instanzen über der Zielgröße

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

Rolling Update mit maximal drei nicht verfügbaren Maschinen und einer Mindestwartezeit von 3 Minuten, ehe eine neue Instanz als verfügbar gekennzeichnet wird

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]

Rolling Update aller VM-Instanzen mit bis zu 10 % neuer Instanzen über der Zielgröße

Wenn Sie beispielsweise 1.000 Instanzen haben und den folgenden Befehl ausführen, erstellt der Updater bis zu 100 Instanzen, bevor er Instanzen entfernt, die die alte Instanzvorlage ausführen.

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

Canary Updates

Ein Canary Update ist eine Aktualisierung, die auf eine Teilmenge von Instanzen in der Gruppe angewendet wird. Mit einem Canary Update können Sie neue Features oder Upgrades für eine zufällige Teilmenge von Instanzen testen, anstatt ein möglicherweise störendes Update für alle Instanzen zu veröffentlichen. Falls der Test nicht erfolgreich ist, müssen Sie nur die Teilmenge der Instanzen zurücksetzen und können so die Unterbrechung für Ihre Nutzer minimieren.

Ein Canary Update erfolgt genauso wie ein standardmäßiges Rolling Update, mit der Ausnahme, dass die Anzahl der Instanzen, die aktualisiert werden sollen, unter der Gesamtgröße der Instanzgruppe liegt. Wie bei einem standardmäßigen Rolling Update können Sie zusätzliche Optionen konfigurieren, um das Maß an Unterbrechung für Ihren Dienst zu steuern.

Canary Update starten

Geben Sie zum Starten eines Canary Updates bis zu zwei Instanzvorlagenversionen an. Dies sind normalerweise eine neue Instanzvorlage für das Canary Update und die aktuelle Instanzvorlage für die restlichen Instanzen. Sie können beispielsweise festlegen, dass 20 % Ihrer Instanzen anhand der Vorlage NEW_INSTANCE_TEMPLATE erstellt werden, während die restlichen Instanzen weiterhin die Vorlage OLD_INSTANCE_TEMPLATE verwenden. Mehr als zwei Instanzvorlagen gleichzeitig sind nicht möglich. Die NEW_INSTANCE_TEMPLATE kann entweder eine regionale Instanzvorlage aus derselben Region wie die Ihres MIG oder eine globale Instanzvorlage sein.

Sie müssen immer eine Zielgröße (targetSize) für die Canary-Version angeben. Ohne die Zielgröße für die Canary-Version können Sie kein Canary Update starten. Wenn Sie beispielsweise festlegen, dass 10 % der Instanzen für den Canary-Test verwendet werden sollen, bleiben die restlichen 90 % unberührt und nutzen weiter die aktuelle Instanzvorlage.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• Für zonale MIGs benötigen Sie alle Berechtigungen, um die Methode instanceGroupManagers.patch aufzurufen.
• Bei regionalen MIGs benötigen Sie alle Berechtigungen, die zum Aufrufen der Methode regionInstanceGroupManagers.patch erforderlich sind.

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Wählen Sie die verwaltete Instanzgruppe aus, die Sie aktualisieren möchten.
3. Klicken Sie auf VMs aktualisieren.
4. Klicken Sie auf Zweite Vorlage hinzufügen und wählen Sie die neue Instanzvorlage für das Canary Update aus.
5. Geben Sie unter Zielgröße den Prozentsatz oder die feste Zahl an Instanzen ein, die Sie für den Canary-Test der neuen Instanzvorlage verwenden möchten.
6. Bei Bedarf können Sie auch andere Aktualisierungsoptionen konfigurieren.
7. Klicken Sie auf VMs aktualisieren, um das Update zu starten.

gcloud

Führen Sie den Befehl rolling-action start-update aus. Geben Sie sowohl die aktuelle Vorlage als auch die neue Vorlage an, um genau festzulegen, wie viele Instanzen die jeweilige Vorlage verwenden sollen:

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]

Dabei gilt:

• INSTANCE_GROUP_NAME ist der Name der Instanzgruppe.
• CURRENT_INSTANCE_TEMPLATE_NAME ist die Instanzvorlage, mit der die Instanzgruppe ausgeführt wird.
• NEW_TEMPLATE ist die neue Vorlage, bei der Sie einen Canary-Test vornehmen möchten.
• SIZE ist die Anzahl oder der Prozentsatz der Instanzen, auf die dieses Update angewendet werden soll. Sie müssen das Attribut target-size für die Vorlage --canary-version festlegen. Einen Prozentsatz können Sie nur einrichten, wenn die Instanzgruppe mindestens 10 Instanzen umfasst.
• ZONE: Geben Sie bei zonalen MIGs die Zone an.
• REGION: Geben Sie bei regionalen MIGs die Region an.

Mit dem folgenden Befehl wird ein Canary Update durchgeführt, bei dem example-template-B auf 10 % der Instanzen in der Gruppe angewendet wird:

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%

REST

Rufen Sie die Methode patch für eine regionale oder zonale MIG-Ressource auf. Geben Sie im Anfragetext sowohl die aktuelle Instanzvorlage als auch die neue Instanzvorlage an, die Sie testen möchten. Beispiel:

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"
  }
 ]
}

Dabei gilt:

• NEW_TEMPLATE ist der Name der neuen Vorlage, die Sie testen möchten.
• NUMBER|PERCENTAGE ist die Anzahl bzw. der Prozentsatz der Instanzen für das Canary Update. Einen Prozentsatz können Sie nur einrichten, wenn die Instanzgruppe mindestens 10 Instanzen umfasst. Geben Sie andernfalls eine feste Zahl an.
• CURRENT_INSTANCE_TEMPLATE_NAME ist der Name der aktuellen Instanzvorlage, die die Gruppe ausführt.

Weitere Optionen finden Sie unter Optionen für das Update konfigurieren.

Nachdem Sie die Anfrage gestellt haben, können Sie das Update überwachen, damit Sie wissen, wann die Aktualisierung beendet ist.

Rollforward für ein Canary Update durchführen

Nach einem Canary Update können Sie entscheiden, ob Sie die Aktualisierung für alle MIG vornehmen oder ein Rollback durchführen möchten.

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Wählen Sie die verwaltete Instanzgruppe aus, die Sie aktualisieren möchten.
3. Klicken Sie auf VMs aktualisieren.
4. Aktualisieren Sie unter Neue Vorlage die Zielgröße der Canary-Vorlage auf 100 %, um sie auf alle Instanzen anzuwenden. Alternativ können Sie die primäre Vorlage durch die Canary-Vorlage ersetzen und das zweite Vorlagenfeld entfernen.
5. Klicken Sie auf VMs aktualisieren, um das Update zu starten.

gcloud

Wenn Sie mit dem Canary Update zufrieden sind, führen Sie die Aktualisierung durch, indem Sie einen weiteren rolling-action start-update-Befehl senden, aber nur das Flag version festlegen und das Flag --canary-version weglassen.

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

REST

Rufen Sie die Methode patch für eine regionale oder zonale MIG-Ressource auf. Legen Sie im Anfragetext die neue Instanzvorlage als version fest und lassen Sie die vorherige Instanzvorlage weg. Lassen Sie die Zielgrößenspezifikation weg, um das Update auf 100 % der Instanzen anzuwenden. Beispiel:

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
   }
 ]
}

Updates beobachten

Nachdem Sie das Update initiiert haben, kann es einige Zeit dauern, bis die neue Konfiguration für alle betroffenen Instanzen eingeführt ist. Sie können den Fortschritt einer Aktualisierung überwachen, indem Sie Folgendes prüfen:

• Prüfen Sie anhand des Gruppenstatus, ob alle VMs die Zielvorlagenversion erreicht haben.
• Prüfen Sie unter Aktuelle Aktionen für Instanzen, ob bestimmte VMs ihre Zielvorlagenversion erreicht haben.
• Informationen zu zustandsorientierten MIGs finden Sie auch unter Prüfen, ob instanzspezifische Konfigurationen angewendet wurden.

Gruppenstatus

Auf Gruppenebene fügt Compute Engine Werte in das schreibgeschützte Feld status ein, das die Flags versionTarget.isReached und isStable enthält. Mit der gcloud CLI oder REST können Sie auf diese Flags zugreifen. Sie können auch die Google Cloud Console verwenden, um die aktuelle und geplante Anzahl von aktualisierten Instanzen einzusehen.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• compute.instanceGroupManagers.get in der MIG

Console

Ein Rolling Update für eine Gruppe können Sie auf der Detailseite der Gruppe beobachten.

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Wählen Sie die verwaltete Instanzgruppe aus, die Sie beobachten möchten. Auf der Übersichtsseite der Gruppe sehen Sie die Vorlagen, die die einzelnen Instanzen verwenden.
3. Klicken Sie auf den Tab Details, um Einzelheiten anzuzeigen.
4. Unter Instanzvorlage sehen Sie die aktuelle und die beabsichtigte Anzahl der Instanzen für die einzelnen Instanzvorlagen sowie die Aktualisierungsparameter.

gcloud

Führen Sie den Befehl describe aus.

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

Sie können auch den Befehl gcloud compute instance-groups managed wait-until mit dem Flag --version-target-reached verwenden, um zu warten, bis status.versionTarget.isReached für die Gruppe auf true gesetzt ist:

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

REST

Rufen Sie die Methode get für eine regionale oder zonale MIG-Ressource auf.

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

Prüfen, ob die Einführung eines Updates abgeschlossen ist

Prüfen Sie, ob die Einführung einer Aktualisierung abgeschlossen ist. Prüfen Sie dazu den Wert des Feldes status.versionTarget.isReached der MIG:

• Wird status.versionTarget.isReached auf true gesetzt, bedeutet das, dass alle VM-Instanzen mithilfe der Zielversion erstellt wurden oder gerade erstellt werden.

• Wird status.versionTarget.isReached auf false gesetzt, bedeutet das, dass mindestens eine VM noch nicht die Zielversion verwendet. Bei einem Canary Update weist false außerdem darauf hin, dass die Anzahl der VMs, die eine Zielversion verwenden, nicht mit der Zielgröße übereinstimmt.

Hinweis: Wenn Sie prüfen möchten, ob die Einführung des Updates abgeschlossen ist sowie alle VM-Instanzen in der Gruppe ausgeführt werden und fehlerfrei sind, prüfen Sie neben status.isStable auch das Flag status.versionTarget.isReached.

Prüfen, ob eine verwaltete Instanzgruppe stabil ist

Prüfen Sie, ob alle Instanzen in einer verwalteten Instanzgruppe ausgeführt werden und fehlerfrei sind, indem Sie den Wert des Feldes status.isStable der Gruppe prüfen.

Wenn status.isStable auf false gesetzt ist, bedeutet das, dass Änderungen aktiv sind, ausstehen oder dass die MIG selbst geändert wird.

Wenn status.isStable auf true gesetzt ist, bedeutet das Folgendes:

• Die Instanzen in der MIG werden nicht geändert und die currentAction für alle Instanzen ist NONE.
• Es gibt keine Änderungen bei Instanzen in der MIG.
• Die MIG selbst wird nicht geändert.

Beachten Sie, dass die Stabilität einer MIG von zahlreichen Faktoren abhängt, da eine MIG auf verschiedene Arten geändert werden kann. Beispiel:

• Sie stellen eine Anfrage, um eine neue Instanzvorlage bereitzustellen.
• Sie stellen eine Anfrage, um in der Gruppe Instanzen zu erstellen, zu löschen, deren Größe anzupassen oder sie zu aktualisieren.
• Durch das Autoscaling wird eine Anfrage gestellt, um die Größe der MIG zu ändern.
• Eine Ressource für die automatische Reparatur ersetzt in der MIG eine oder mehrere fehlerhafte Instanzen.
• In einer regionalen MIG werden einige der Instanzen neu verteilt.

Sobald alle Aktionen abgeschlossen sind, wird status.isStable für diese MIG wieder auf true gesetzt.

Aktuelle Aktionen auf Instanzen

Verwenden Sie die Google Cloud CLI oder REST, um Details zu den Instanzen in einer verwalteten Instanzgruppe aufzurufen. Die Details enthalten den Instanzstatus und die aktuellen Aktionen, die die Gruppe auf ihren Instanzen ausführt.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• compute.instanceGroupManagers.get für die Gruppe
• compute.instanceGroupManagers.list für die Gruppe

gcloud

Alle verwalteten Instanzen

Prüfen Sie den Status und die aktuellen Aktionen für alle Instanzen in der Gruppe mit dem Befehl list-instances.

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

Der Befehl gibt eine Liste der Instanzen in der Gruppe zurück, einschließlich ihres Status, aktueller Aktionen und weiterer Details:

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

Die Spalte HEALTH_STATE ist leer, sofern Sie keine Systemdiagnose eingerichtet haben.

Eine bestimmte verwaltete Instanz

Zum Prüfen des Status und der aktuellen Aktion für eine bestimmte Instanz in der Gruppe verwenden Sie den Befehl describe-instance.

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

Der Befehl liefert Details zur Instanz, einschließlich des Instanzstatus, der aktuellen Aktion und (für zustandsorientierte MIGs) des beibehaltenen Status:

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

REST

Rufen Sie die Methode listManagedInstances für eine regionale oder zonale MIG-Ressource auf. Wenn Sie beispielsweise Details zu den Instanzen in einer zonalen MIG-Ressource abrufen möchten, können Sie die folgende Anfrage stellen:

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

Der Aufruf gibt eine Liste der Instanzen für die MIG zurück, einschließlich instanceStatus und currentAction jeder Instanz.

{
 "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"
  }
 ]
}

Eine Liste der gültigen instanceStatus-Feldwerte finden Sie unter Lebenszyklus von VM-Instanzen.

Wenn an einer Instanz eine Änderung vorgenommen wird, setzt das verwaltete Feld der Instanz das Feld currentAction auf eine der folgenden Aktionen, damit Sie den Fortschritt der Änderung verfolgen können. Andernfalls wird das Feld currentAction auf NONE gesetzt.

Folgende currentAction-Werte sind möglich:

• ABANDONING. Die Instanz wird gerade aus der MIG entfernt.
• CREATING: Die Instanz wird gerade erstellt.
• CREATING_WITHOUT_RETRIES. Die Instanz wird ohne Neuversuche erstellt. Wenn die Instanz beim ersten Versuch nicht erstellt wird, versucht die MIG nicht, die Instanz noch einmal zu ersetzen.
• DELETING: Die Instanz wird gerade gelöscht.
• RECREATING. Die Instanz wird gerade ersetzt.
• REFRESHING: Die Instanz wird aus den aktuellen Zielpools entfernt und anschließend zu den in der Liste enthaltenen Zielpools wieder hinzugefügt. Diese Liste kann mit den bestehenden Zielpools identisch sein oder davon abweichen.
• RESTARTING: Die Instanz wird gerade mit den Methoden stop und start neu gestartet.
• RESUMING. Die Instanz wird gerade fortgesetzt, nach dem sie vorher gesperrt war.
• STARTING. Die Instanz wird gerade gestartet, nachdem sie vorher beendet wurde.
• STOPPING: Die Instanz wird beendet.
• SUSPENDING: Die Instanz wird angehalten.
• VERIFYING: Die Instanz wurde erstellt und wird gerade verifiziert.
• NONE: Für die Instanz werden gerade keine Aktionen durchgeführt.

Hinweis: Das Feld pendingActions wurde verworfen und wird demnächst entfernt. Senden Sie eine E-Mail an [e-mail], wenn dieses Feld für Ihre Arbeitslast unerlässlich ist.

Aktualisierung rückgängig machen

Es gibt keinen eigenen Befehl, um für eine Aktualisierung ein Rollback durchzuführen und das System auf eine vorherige Version zurückzusetzen. Wenn Sie jedoch für ein Update (sei es ein vollständiges oder ein Canary Update) ein Rollback durchführen möchten, können Sie eine neue Aktualisierungsanfrage mit der Instanzvorlage stellen, auf die die Instanzen zurückgesetzt werden sollen.

gcloud

Der folgende gcloud CLI sorgt beispielsweise dafür, dass eine Aktualisierung so schnell wie möglich rückgängig gemacht wird: Ersetzen Sie dabei OLD_INSTANCE_TEMPLATE durch den Namen der Instanzvorlage, auf die die Instanzgruppe zurückgesetzt werden soll.

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]

REST

Rufen Sie die Methode patch für eine regionale oder zonale MIG-Ressource auf.

Geben Sie im Anfragetext die frühere Instanzvorlage als version an:

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
    }
  ]
}

Bei einer regionalen MIG mit weniger als 10 Instanzen müssen Sie einen festen Wert für maxUnavailable verwenden und den Wert auf die Anzahl der Instanzen in der Gruppe festlegen.

Der Updater behandelt eine Rollback-Anfrage wie eine normale Aktualisierungsanfrage, sodass Sie zusätzliche Optionen für die Aktualisierung angeben können.

Achtung: Canary Updates sollten Sie unbedingt vollständig rückgängig machen, bevor Sie eine weitere Version testen. Da Sie nicht auswählen können, welche Instanzen auf der Basis welcher Instanzvorlage aktualisiert werden, könnte ein zusätzliches Canary Update unbeabsichtigte Folgen haben. Daher ist es empfehlenswert, zuerst das vorherige Canary Update vollständig rückgängig zu machen und dann den Prozess von Neuem zu beginnen.

Aktualisierung anhalten

Es gibt keine eigene Methode und keinen Befehl, um eine Aktualisierung anzuhalten. Sie können aber ein Update von proaktiv in opportunistisch ändern. Wenn die Größe der Gruppe nicht durch andere Dienste wie Autoscaling angepasst wird, bedeutet diese Änderung, dass die Aktualisierung stoppt.

Führen Sie den folgenden Befehl aus, um mit der gcloud CLI eine Aktualisierung von proaktiv in opportunistisch zu ändern:

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

So halten Sie die Aktualisierung vollständig an, nachdem Sie sie von proaktiv in opportunistisch umgewandelt haben:

1. Stellen Sie eine Anfrage, um festzustellen, wie viele Instanzen aktualisiert wurden.

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

   Die gcloud CLI gibt eine Antwort zurück, die eine Liste der Instanzen in der Gruppe und ihren aktuellen Status enthält:

   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 diesem Beispiel wurden zwei Instanzen bereits aktualisiert.

2. Senden Sie als Nächstes eine Anfrage für eine neue Aktualisierung, geben Sie jedoch darin die Anzahl der bereits aktualisierten Instanzen als Zielgröße an:

   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]

   Der Updater betrachtet dieses Update als abgeschlossen, sodass keine anderen Instanzen aktualisiert werden und das Update anhält.

Geschwindigkeit eines Rolling Updates steuern

Standardmäßig werden Aktualisierungen nach einer entsprechenden Anfrage so schnell wie möglich durchgeführt. Wenn Sie sich nicht sicher sind, ob Sie ein Update vollständig anwenden möchten, oder wenn Sie Änderungen vorsichtig testen möchten, können Sie die Geschwindigkeit des Updates mithilfe der folgenden Methoden steuern:

1. Starten Sie statt einer vollständigen Aktualisierung ein Canary Update.
2. Legen Sie einen hohen Wert für minReadySec fest. Hiermit bestimmen Sie, wie viele Sekunden der Updater wartet, bevor er eine Instanz als erfolgreich aktualisiert betrachtet und mit der nächsten Instanz fortfährt.
3. Aktivieren Sie Systemdiagnosen, damit der Updater darauf wartet, dass Ihre Anwendung startet und meldet, dass sie fehlerfrei ist, bevor er die Instanz als erfolgreich aktualisiert betrachtet und mit der nächsten Instanz fortfährt.
4. Legen Sie niedrige Werte für maxUnavailable und maxSurge fest. Damit sorgen Sie dafür, dass immer nur wenige Instanzen gleichzeitig aktualisiert werden.
5. Aktualisieren Sie Instanzen in einer MIG selektiv, anstatt sie automatisch zu aktualisieren.

Sie können die Aktualisierungsrate auch mit einer Kombination dieser Methoden steuern.

Unterbrechungsmaß während eines Rolling Updates steuern

Je nach Art der Aktualisierung kann diese sich negativ auf den Lebenszykluszustand einer Instanz auswirken. Beispiel: Wenn Sie das Bootlaufwerk einer Instanz ändern möchten, müssen Sie die Instanz ersetzen. Um das Maß der Unterbrechung während eines Rolling Updates zu steuern, legen Sie folgende Optionen fest:

• Mindestaktion: Verwenden Sie diese Option, um Unterbrechungen so weit wie möglich zu minimieren oder um eine umfangreichere Aktion als erforderlich anzuwenden.

  • Wenn Sie Unterbrechungen so weit wie möglich einschränken möchten, legen Sie die Mindestaktion auf REFRESH fest. Wenn ein Update eine umfassendere Aktion erfordert, führt Compute Engine die Aktion aus, die notwendig ist, um das Update auszuführen.
  • Wenn Sie eine umfassendere Aktion anwenden möchten als notwendig, legen Sie die Mindestaktion auf RESTART oder REPLACE fest. So muss Compute Engine zum Beispiel keine VM neu starten, um die Metadaten zu ändern. Wenn Ihre Anwendung Instanzmetadaten nur beim Neustart einer VM liest, können Sie die Mindestaktion auf RESTART festlegen, um Metadatenänderungen zu übernehmen.

• Umfassendste erlaubte Aktion: Verwenden Sie diese Option, um ein Update zu verhindern, wenn dies zu einer längeren Unterbrechung führen würde, als tragbar ist. Wenn ein Update eine umfassendere Aktion erfordert, als die mit diesem Flag festgelegte, schlägt die Aktualisierungsanfrage fehl. Beispiel: Wenn Sie als umfassendste zulässige Aktion RESTART festlegen, schlägt der Versuch, das Bootlaufwerk-Image zu aktualisieren, fehl. Dieses Update erfordert ein Ersetzen der Instanz, eine umfassendere Aktion als einen Neustart.

Beide Optionen akzeptieren die folgenden Werte:

Wert	Beschreibung	Welche Instanzattribute können aktualisiert werden?
REFRESH	Die Instanz wird nicht gestoppt.	Zusätzliche Laufwerke, Instanzmetadaten, Labels, Tags
RESTART	Die Instanz wird gestoppt und noch einmal gestartet.	Zusätzliche Laufwerke, Instanzmetadaten, Labels, Tags, Maschinentyp
REPLACE	(Standardeinstellung.) Ersetzen der die Instanz gemäß der Option Ersetzungsmethode.	Alle Instanzattribute, die in der Instanzvorlage oder der instanzspezifischen Konfiguration gespeichert sind

Die umfangreichste erlaubte Aktion kann nicht weniger umfangreich sein als die Mindestaktion.

Wenn Sie Updates automatisch einführen, gelten die folgenden Standardeinstellungen:

• Standardmäßig ist die Mindestaktion REPLACE. Wenn Sie unnötige Unterbrechungen vermeiden möchten, legen Sie für die Mindestaktion einen weniger hohen Wert fest.
• Standardmäßig ist die umfassendste erlaubte Aktion REPLACE. Wenn Sie eine solche Störung nicht tolerieren können, sollten Sie die umfassendste erlaubte Aktion auf einen weniger hohen Wert setzen.

Sie können das Standardverhalten ändern, indem Sie mit der Compute Engine API die Felder updatePolicy.minimalAction und updatePolicy.mostDisruptiveAllowedAction in der MIG-Ressource festlegen. Dazu rufen Sie beispielsweise die Methode regionInstanceGroupManagers.patch auf. Alternativ können Sie die spezifischen für VM-Updates zulässige Aktionen auswählen, wenn Sie die MIG über die Google Cloud Console aktualisieren. Informationen zum Aufrufen der aktuellen Einstellungen finden Sie unter Attribute einer MIG abrufen.

Ein Update schlägt fehl, wenn eine umfangreichere Aktion nötig ist, als Sie erlaubt haben. In diesem Fall können Sie die Aktualisierung mit einer umfangreicheren zulässigen Aktion wiederholen oder die Instanz selektiv aktualisieren. Compute Engine führt eine Best-Effort-Validierung durch, um zu prüfen, ob Instanzen mit dem angegebenen Unterbrechungslimit aktualisiert werden können. Aufgrund gleichzeitiger Änderungen im System kann sich die Situation jedoch nach dem Start der Aktualisierung ändern. Wenn ein Vorgang bei einer bestimmten Instanz fehlschlägt, listen Sie Instanzfehler auf, um den Fehler anzuzeigen.

Rollierende Ersetzung oder rollierender Neustart

Bei einem rollierenden Neustart werden alle Instanzen angehalten und neu gestartet. Bei einer rollierenden Ersetzung werden Instanzen gemäß der Option für die Ersetzungsmethode ersetzt. Durch einen rollierenden Neustart bzw. eine Ersetzung werden keine weiteren Änderungen an der Gruppe vorgenommen, auch nicht an der Instanzvorlage.

Es gibt viele Gründe, warum Sie einen rollierenden Neustart oder eine rollierende Ersetzung benötigen könnten. Sie können beispielsweise aus einem der folgenden Gründe von Zeit zu Zeit Ihre VM-Instanzen neu starten oder ersetzen wollen:

• Beheben von Speicherlecks
• Neustart einer Anwendung, damit sie auf einer neuen virtuellen Maschine ausgeführt werden kann
• Wenden Sie eine regelmäßige Ersetzung als Best Practice zum Testen von VMs an.
• Aktualisieren des Betriebssystem-Images Ihrer VMs oder erneute Ausführung von Startskripts zur Aktualisierung der Software

Verwenden Sie die Google Cloud Console, die Google Cloud CLI oder REST, um einen Neustart oder eine Ersetzung durchzuführen.

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Wählen Sie die verwaltete Instanzgruppe mit den VMs aus, die Sie neu starten oder ersetzen möchten.
3. Klicken Sie auf VMs neu starten/ersetzen.
4. Wählen Sie unter Vorgang die Option Neustart oder Ersetzen aus.
   • Wenn Sie Neustart auswählen, schalten Sie die folgenden Parameter um:
     • Maximale Anzahl nicht verfügbarer Instanzen
     • Mindestwartezeit
   • Wenn Sie Ersetzen auswählen, gehen Sie so vor:
     1. Wählen Sie aus, ob die Instanznamen beim Ersetzen von Instanzen beibehalten werden sollen.
     2. Wechseln Sie zwischen den folgenden Parametern:
        • Temporäre zusätzliche Instanzen
        • Maximale Anzahl nicht verfügbarer Instanzen
        • Mindestwartezeit
5. Klicken Sie zum Starten des Vorgangs auf VMs neu starten oder VMs ersetzen.

gcloud

Verwenden Sie den Befehl restart oder replace.

Mit dem folgenden Befehl werden alle Instanzen in der MIG nacheinander ersetzt:

gcloud compute instance-groups managed rolling-action replace INSTANCE_GROUP_NAME

Mit dem folgenden Befehl wird jede Instanz einzeln neu gestartet:

gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_NAME

Diese Befehle lassen sich mit den Optionen für Aktualisierungen (z. B. maxSurge und maxUnavailable) zusätzlich anpassen.

REST

Rufen Sie die Methode patch für eine regionale oder zonale MIG-Ressource auf.

Geben Sie im Feld updatePolicy.minimalAction entweder RESTART oder REPLACE an. Geben Sie im Feld versions.instanceTemplate die aktuelle Vorlage an.

Wenn Sie die Aktion auslösen möchten, müssen Sie auch das Feld versions.name aktualisieren, z. B. mit einem Zeitstempel. Später können Sie die VMs der MIG auflisten und im Feld versions.name jeder VM prüfen, welche VMs ersetzt oder neu gestartet wurden.

Die folgende Anfrage zeigt beispielsweise für eine zonale MIG die minimale Konfiguration, die zum automatischen Neustart aller Instanzen erforderlich ist.

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"
  }
 ]
}

Weitere Beispiele für Ersetzung/Neustart

Rollierenden Neustart aller VMs, wobei immer zwei gleichzeitig neu gestartet werden

Durch diesen Befehl werden immer zwei VMs der Instanzgruppe gleichzeitig neu gestartet. Hierbei wird keine neue Instanzvorlage angegeben.

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

Rollierenden Neustart aller VMs so schnell wie möglich ausführen

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

Rollierende Ersetzung aller VMs so schnell wie möglich ausführen

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

Instanznamen beibehalten

Wenn Sie die Namen Ihrer VM-Instanzen über ein Update hinweg beibehalten möchten, setzen Sie replacementMethod auf RECREATE. Sie müssen auch für maxUnavailable einen größeren Wert als 0 und für maxSurge genau den Wert 0 festlegen. Wenn Sie Instanzen neu erstellen, anstatt sie zu ersetzen, dauert die Aktualisierung länger. Allerdings bleiben die Namen der aktualisierten Instanzen unverändert.

Wenn Sie keine Ersetzungsmethode angeben, wird der aktuelle Wert der MIG für updatePolicy.replacementMethod verwendet. Wenn dafür keine Angabe existiert, wird der Standardwert (substitute) verwendet, bei dem VM-Instanzen durch neue Instanzen mit zufällig generierten Namen ersetzt werden.

gcloud

Fügen Sie beim Ausführen eines rolling-action-Befehls das Flag --replacement-method=recreate an.

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]

REST

Rufen Sie die Methode patch für eine regionale oder zonale MIG-Ressource auf. Geben Sie im Anfragetext das Attribut updatePolicy.replacementMethod an.

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"
    } ]
}

Nachdem Sie die Anfrage gestellt haben, können Sie das Update überwachen, damit Sie wissen, wann die Aktualisierung beendet ist.

Regionale verwaltete Instanzgruppe aktualisieren

Eine regionale MIG enthält VM-Instanzen, die innerhalb einer Region auf mehrere Zonen verteilt sind, im Gegensatz zu einer zonalen MIG, die nur Instanzen in einer Zone enthält. Mit regionalen MIGs können Sie Ihre Instanzen auf mehrere Zonen verteilen, um die Verfügbarkeit Ihrer Anwendung zu verbessern. Dies gilt insbesondere in extremen Fällen, in denen eine Zone ausfällt oder eine ganze Gruppe von Instanzen nicht mehr reagiert.

Die Aktualisierung einer regionalen MIG ist im Prinzip mit der Durchführung einer Aktualisierung für eine zonale MIG vergleichbar. Die wenigen Unterschiede werden unten beschrieben. Wenn Sie die Aktualisierung einer regionalen MIG starten, aktualisiert der Updater die Instanzen immer proportional und gleichmäßig über die einzelnen Zonen hinweg. Sie können nicht auswählen, welche Instanzen in welchen Zonen zuerst aktualisiert werden, oder Instanzen nur in einer Zone aktualisieren.

Unterschiede zwischen der Aktualisierung regionaler und zonaler MIGs

Regionale MIGs haben die folgenden Standardaktualisierungswerte:

• maxUnavailable=NUMBER_OF_ZONES
• maxSurge=NUMBER_OF_ZONES

NUMBER_OF_ZONES ist die Anzahl der Zonen, die der regionalen MIG zugeordnet sind. Die Anzahl der Zonen für eine regionale MIG ist standardmäßig 3. Sie können aber auch eine andere Zahl auswählen.

Wenn Sie bei der Definition eines Updates feste Zahlen verwenden, müssen sie entweder 0 oder größer bzw. gleich der Anzahl der Zonen sein, die der regionalen MIG zugeordnet sind. Wenn die Gruppe zum Beispiel auf drei Zonen verteilt ist, können Sie maxSurge nicht auf 1 oder 2 setzen, weil der Updater in jeder der drei Zonen eine zusätzliche Instanz erstellen muss.

Feste Zahlen oder Prozentsätze in Aktualisierungsanfragen verwenden

Wenn Sie in Ihrer Aktualisierungsanfrage eine feste Zahl angeben, wird diese durch die Anzahl der Zonen in der regionalen MIG geteilt und gleichmäßig verteilt. Wenn Sie beispielsweise maxSurge=10 angeben, teilt der Updater 10 durch die Anzahl der Zonen in der Region und erstellt anhand des Ergebnisses neue Instanzen. Wenn sich die Anzahl der Instanzen nicht gleichmäßig auf die Zonen verteilen lässt, fügt der Updater die verbleibenden Instanzen einer zufällig ausgewählten Zone hinzu. Bei 10 Instanzen in drei Zonen erhalten also zwei Zonen 3 Instanzen und eine Zone erhält 4 Instanzen. Für Canary Updates wird die gleiche Logik auf die Parameter maxUnavailable und targetSize angewendet.

Einen Prozentsatz können Sie nur angeben, wenn Ihre MIG mindestens 10 VM-Instanzen umfasst. Prozentsätze werden je nach Situation unterschiedlich behandelt:

• Wenn Sie bei einem Canary Update einen Prozentsatz an VM-Instanzen festlegen, versucht der Updater, die Instanzen gleichmäßig auf die Zonen zu verteilen. Der Rest wird in jeder Zone auf- oder abgerundet, aber die Gesamtdifferenz beträgt nicht mehr als eine VM-Instanz pro Gruppe. Bei einer MIG mit 10 Instanzen und einem Prozentsatz für die Zielgröße von 25 % wird die Aktualisierung zum Beispiel auf zwei bis drei VM-Instanzen angewendet.

• Wenn Sie für Aktualisierungsoptionen wie maxSurge und maxUnavailable einen Prozentsatz angeben, wird dieser unabhängig für jede Zone gerundet.

Nächste Schritte

• Informationen zu MIGs und verwalteten Instanzen ansehen
• Instanzvorlagen erstellen
• Mit Image-Familien und rollierenden Ersetzungen das Betriebssystem-Image auf allen VMs einer verwalteten Instanzgruppe aktualisieren.