Aktualisierungen für MIGs einführen

Eine verwaltete Instanzgruppe (Managed Instance Group, MIG) enthält eine oder mehrere VM-Instanzen, die mithilfe einer Instanzvorlage erstellt werden. Zum Aktualisieren der Instanzen in einer MIG können Sie über die MIG Updater-Funktion eine Aktualisierungsanfrage an die gesamte Gruppe stellen.

Mit dem Managed Instance Group Updater lassen sich neue Softwareversionen auf Instanzen in Ihren verwalteten Instanzgruppen bereitstellen. Dabei bestimmen Sie selbst, wie schnell dies geschieht, ob und in welchem Umfang der Dienst unterbrochen wird und wie umfangreich die Aktualisierung ausfällt. Der Updater bietet zwei Hauptvorteile:

  • Der Rollout eines Updates erfolgt automatisch nach Ihren Vorgaben, ohne dass nach der anfänglichen Anfrage zusätzliche Nutzereingaben erforderlich sind.
  • Sie können partielle Rollouts ausführen, die Canary-Tests ermöglichen.

Da die Software in einer vorhandenen verwalteten Instanzgruppe bereitgestellt wird, ist es nicht erforderlich, bei jeder Einführung einer neuen Softwareversion die Instanzgruppe neu zu konfigurieren oder wieder eine Verbindung zum Load-Balancing, zum Autoscaling oder zur automatischen Reparatur herzustellen. Ohne den Updater müssen aktualisierte Softwareversionen durch die Erstellung einer neuen verwalteten Instanzgruppe mit einer neuen Softwareversion bereitgestellt werden, wofür jedes Mal zusätzliche Einstellungen erforderlich sind. Alternativ ist eine manuelle, vom Nutzer gestartete Neuerstellung jeder einzelnen Instanz erforderlich. Diese beiden Ansätze erfordern jedoch zahlreiche manuelle Schritte während des gesamten Prozesses.

Hinweise

Ein grundlegendes Rolling Update starten

Ein Rolling Update ist ein Update, das nach und nach auf alle Instanzen in einer Instanzgruppe angewendet wird, bis alle Instanzen aktualisiert sind. 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 alle Instanzen oder nur ein Teil aktualisiert werden sollen usw.

Folgendes sollten Sie bei einem Rolling Update bedenken:

  • Die Updates sind zuerst nur geplant. Wenn Sie die erste Updateanfrage stellen, bestätigt die API in einer Antwort, dass die Anfrage gültig ist. Dies bedeutet jedoch nicht, dass das Update erfolgreich war. Sie müssen den Status der verwalteten Instanzgruppe 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.

  • Der Updater unterstützt in Ihrer verwalteten Instanzgruppe bis zu zwei Instanzvorlagenversionen. Sie können also zwei unterschiedliche Instanzvorlagenversionen für Ihre verwaltete Instanzgruppe angeben, was für Canary-Updates hilfreich ist.

Gehen Sie wie unten beschrieben vor, um ein grundlegendes Rolling Update zu starten, das auf alle Instanzen der Gruppe angewendet wird.

Console

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

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Klicken Sie unter Vorlage auf die Drop-down-Liste und wählen Sie die neue Vorlage aus, auf die Sie aktualisieren möchten.
  5. Geben Sie als Zielgröße 100 % ein, um alle Instanzen zu aktualisieren.
  6. Sie können zwischen Konfigurationsoptionen wechseln, beispielsweise ob das Update umgehend (die Gruppe ersetzt Instanzen aktiv) oder bei Gelegenheit erfolgen soll (die Gruppe ersetzt Instanzen nicht aktiv, sondern wendet das Update an, wenn Instanzen aus anderen Gründen ersetzt werden). Sie können auch Werte für Maximal zu viel, Maximal nicht verfügbar und Mindestwartezeit festlegen.
  7. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Wenn Sie das gcloud-Befehlszeilentool verwenden, 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]

Ersetzen Sie Folgendes:

  • instance-group-name: Der Name der Instanzgruppe, die aktualisiert werden soll.
  • instance-template-name: Die neue Instanzvorlage, auf die die Instanzgruppe aktualisiert werden soll.
  • zone: Die Zone für diese Instanzgruppe, wenn die Instanzgruppe eine zonale Instanzgruppe ist.
  • region: Die Region für diese Instanzgruppe, wenn die Instanzgruppe eine regionale Instanzgruppe ist.

API

Senden Sie in der API eine PATCH-Anfrage an die Instanzgruppenmanager-Ressource:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

Wenn es sich um eine regionale verwaltete Instanzgruppe handelt, ersetzen Sie zones/zone durch regions/region.

Die Nutzlast der Anfrage enthält Folgendes:

  • Die Instanzvorlage, auf die die Gruppe aktualisiert werden soll
  • Eine Updaterichtlinie für die Anfrage sowie weitere Updateoptionen

Die folgende Konfiguration ist mindestens nötig, um eine Aktualisierung in der API zu starten.

Wenn Sie nichts anderes angeben, werden die Attribute maxSurge und maxUnavailable standardmäßig auf 1, multipliziert mit der Anzahl der betroffenen Zonen, gesetzt. Dies bedeutet, dass während der Aktualisierung immer nur eine Instanz in jeder betroffenen Zone nicht verfügbar ist und nur eine zusätzliche Instanz pro Zone erstellt wird.

Durch diese Beispielanfrage werden 100 % der Instanzen auf die neue Instanzvorlage aktualisiert:

{
  "instanceTemplate": "global/instanceTemplates/example-template",
  "updatePolicy": {
    "type": "proactive"
   }
 }

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

Optionen für das Update konfigurieren

Bei komplexeren Updates können Sie zusätzliche Optionen für eine bestimmte Aktualisierungsanfrage konfigurieren. Diese werden unten näher beschrieben.

Maximal zu viel

Legen Sie einen Wert für das Attribut maxSurge fest, damit der Updater während der Aktualisierung vorübergehend neue Instanzen erstellen kann, deren Zahl den Wert für targetSize überschreitet. Wenn Sie beispielsweise für maxSurge 5 festlegen, verwendet die verwaltete Instanzgruppe die neue Instanzvorlage, um bis zu fünf neue Instanzen über die Zielgröße hinaus 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.

Wenn Sie den Wert maxSurge nicht festlegen, wird der Standardwert verwendet. Bei zonal verwalteten Instanzgruppen ist maxSurge der Standardwert für 1. Bei regional verwalteten Instanzgruppen ist der Standardwert die Anzahl der Zonen, die der regional verwalteten Instanzgruppe zugeordnet sind.

Diese Option wird nur berücksichtigt, wenn sie zusammen mit der Mindestaktion REPLACE konfiguriert wird. Mit der Aktionseinstellung RESTART wird sie nicht unterstützt. 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 der Instanzen auf.

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

Maximal nicht verfügbar

Mit der Konfiguration von maxUnavailable können Sie dafür sorgen, dass während eines Updates immer nur eine bestimmte Anzahl an Instanzen nicht verfügbar ist. 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 die Instanzgruppe gerade vergrößert wird, sind Instanzen, die sich in Erstellung befinden, unter Umständen nicht verfügbar. Diese Instanzen werden zur Zahl maxUnavailable hinzugezählt. 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 der Instanzen ab.

Der Standardwert für maxUnavailable hängt vom Gruppentyp ab.

  • Für zonale MIGs ist die Standardeinstellung 1.
  • Bei regionalen MIGs ist die Standardeinstellung die Anzahl der Zonen, auf die Ihre MIG verteilt ist. Dies ist normalerweise 3, aber Sie können eine andere Anzahl von Zonen auswählen.

Mindestwartezeit

Geben Sie durch Festlegen von minReadySec an, wie lange gewartet werden soll, bis eine neue oder neu gestartete Instanz als aktualisiert betrachtet wird. Mit dieser Funktion kontrollieren Sie die Aktualisierungsgeschwindigkeit. 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.

Bei aktivierter Systemdiagnose gelten für den Updater folgende Wartezeiten:

  1. Verstreichen der mit autohealingPolicies.initialDelaySec festgelegten Zeit, bevor als Status HEALTHY angegeben 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 Instanzgruppe durchgeführt werden, startet der Timer, sobald die Instanz den Status RUNNING hat. Für das Attribut minReadySec kann ein Höchstwert von 3.600 Sekunden (1 Stunde) angegeben werden.

Mindestaktion

Mit dem Attribut "Mindestaktion" legen Sie fest, was der Updater mindestens tun muss, um die Instanzen der Gruppe zu aktualisieren. Wenn Sie beispielsweise REPLACE als Mindestaktion festlegen, werden alle betroffenen Instanzen gelöscht und durch neue Instanzen ersetzt, unabhängig davon, ob dies erforderlich ist oder nicht.

Durch das Festlegen der Mindestaktion wird gewährleistet, dass der Updater diese Aktion mindestens ausführt. Falls dies für die Aktualisierung jedoch nicht ausreicht, kann eine umfangreichere Maßnahme ergriffen werden. Wenn Sie beispielsweise RESTART als Mindestaktion festlegen, versucht der Updater, Instanzen neu zu starten, um das Update anzuwenden. Wenn ein Update aber eine umfassendere Aktion erfordert, führt der Updater eine umfangreichere Aktion aus. Das Betriebssystem einer Instanz lässt sich zum Beispiel nicht durch einen Neustart ändern. Daher ersetzt der Updater in diesem Fall die VM-Instanzen der Gruppe durch neue.

Zur Auswahl stehen die Aktionen REPLACE und RESTART:

  • RESTART. Startet die Instanz neu (über eine stop- und start-Anfrage). Wenn in der Aktualisierungsanfrage festgelegt ist, dass die Instanz ersetzt werden soll, um die Änderungen zu übernehmen (z. B. erfordert das Ändern des Images, dass die Instanz gelöscht und ersetzt wird), führt der Updater ein REPLACE durch.

  • REPLACE. Löscht die bestehende Instanz und erstellt eine Instanz anhand der Zielvorlage. Der Updater erstellt eine Instanz mit allen neuen Instanzattributen, z. B. neuen internen und externen IP-Adressen.

Das folgende Diagramm zeigt, wie sich diese Optionen auf Ihre Instanzen auswirken.

Auswirkungen der Optionen von Updater auf Ihre Anfrage.

Ersetzungsmethode

Wenn Sie eine MIG 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, können Sie die Einstellung replacementMethod verwenden.

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, setzen Sie die Ersetzungsmethode auf recreate anstatt auf substitute.

Ersetzungsmethode für verwaltete Instanzen

Gültige Updater-Werte der 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 mit dem Herunterfahren der alten VM frei. 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.

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

Wenn Sie beispielsweise 1.000 Instanzen haben und diesen Befehl ausführen, erstellt der Updater bis zu 100 Instanzen, bevor er Instanzen mit der alten Instanzvorlage entfernt.

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

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

Mit dem Updater können Sie Canary Updates durchführen, um die Aktualisierung an einer beliebigen Teilmenge von Instanzen zu testen, bevor Sie sie endgültig anwenden.

Bei einem Canary Update wird nur ein Teil der Instanzen einer Instanzgruppe aktualisiert. So können Sie neue Features oder Upgrades an einer beliebigen Teilmenge von Instanzen testen und müssen nicht ein Update, das möglicherweise zu Unterbrechungen führt, auf alle Instanzen anwenden. Falls der Test nicht erfolgreich ist, müssen Sie nur für eine geringe Zahl an Instanzen ein Rollback durchführen und können Ausfälle minimieren. Aus Sicht des Servers ist ein Canary Update das gleiche wie ein standardmäßiges Rolling Update, außer dass dabei nicht alle Instanzen der Gruppe aktualisiert werden. Genau wie ein standardmäßiges Rolling Update bedeutet auch ein Canary Update für die betroffenen Instanzen eine Unterbrechung, d. h., sie werden während der Aktualisierung gelöscht und durch neue VM-Instanzen ersetzt.

Canary Update starten

So starten Sie ein Canary Update:

  • Sie können maximal zwei Instanzvorlagenversionen angeben. 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.

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

Console

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

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Klicken Sie auf Vorlage hinzufügen und wählen Sie die neue Instanzvorlage für den Canary-Test 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. Sie können zwischen Konfigurationsoptionen wechseln, beispielsweise ob das Update proaktiv (die Gruppe löscht und ersetzt Instanzen aktiv) oder opportunistisch erfolgen soll (die Gruppe ersetzt Instanzen nicht aktiv, sondern wendet das Update an, wenn Instanzen aus anderen Gründen erstellt werden). Sie können auch Werte für Maximal zu viel, Maximal nicht verfügbar und Mindestwartezeit festlegen.
  7. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Geben Sie im gcloud-Befehlszeilentool sowohl die aktuelle 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-template \
    --canary-version template=new-template,target-size=size \
    [--zone zone | --region region]

Ersetzen Sie Folgendes:

  • instance-group-name: Der Gruppenname für die Instanz.
  • current-template: Die Instanzvorlage, mit der die Instanzgruppe ausgeführt wird.
  • new-template: Die neue Vorlage, die Sie testen möchten.
  • size: 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: Eine Zone für diese Instanzgruppe. Wenn es sich um eine zonale Instanzgruppe handelt, geben Sie die Zone an.
  • region: Eine Region für diese Instanzgruppe. Wenn es sich um eine regionale Instanzgruppe handelt, geben Sie die Region an.

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

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

API

Senden Sie in der API eine PATCH-Anfrage an die Instanzgruppenmanager-Ressource:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

Fügen Sie in die Anfragenutzlast sowohl die aktuelle als auch die neue Instanzvorlage ein, die Sie testen möchten. Beispiel:

{
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/new-template",
   "targetSize": {
    "[percent|fixed]": number|percentage # Use `fixed` for a specific number of instances
   }
  },
  {
   "instanceTemplate": "global/instanceTemplates/current-template"
  }
 ]
}

Ersetzen Sie Folgendes:

  • new-template: Der Name der neuen Vorlage, die Sie testen möchten.
  • number|percentage: 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. Wenn dies nicht der Fall ist, legen Sie eine feste Anzahl fest.
  • current-template: Der Name der aktuellen Instanzvorlage, mit der die Instanzgruppe ausgeführt wird.

Rollforward für ein Canary Update durchführen

Nach einem Canary Update können Sie entscheiden, ob Sie die Aktualisierung auf die gesamte Instanzgruppe anwenden oder ein Rollback durchführen möchten.

Console

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

    Zur Seite "Instanzgruppen"

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

gcloud

Wenn Sie mit dem Canary Update zufrieden sind, führen Sie ein Rollforward der Aktualisierung durch, indem Sie dieselbe Anfrage stellen. Dabei legen Sie einen Wert für version fest und lassen --canary-version weg. Mit dem gcloud-Befehlszeilentool:

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=new-template \
    [--zone zone | --region region]

API

Senden Sie in der API eine PATCH-Anfrage an die Instanzgruppenmanager-Ressource:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

Legen Sie im Anfragetext die neue Instanzvorlage als version fest und lassen Sie die vorherige Instanzvorlage weg. Die Zielgröße lassen Sie ebenfalls weg, um das Update auf alle Instanzen anzuwenden. Der Text Ihrer Anfrage könnte beispielsweise so aussehen: Ersetzen Sie new-template durch den Namen der neuen Instanzvorlage, die verwendet werden soll.

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

Opportunistische oder proaktive Aktualisierung starten

Standardmäßig sind Aktualisierungen über das Befehlszeilentool gcloud proaktiv und solche in der API opportunistisch.

Bei proaktiven Aktualisierungen plant Compute Engine aktiv Maßnahmen, um die angeforderten Updates bei Bedarf auf die Instanzen anzuwenden. Dies bedeutet häufig, dass Instanzen proaktiv gelöscht und neu erstellt werden.

Sie können sich auch für eine opportunistische Aktualisierung entscheiden, wenn eine proaktive zu störend wäre. Eine opportunistische Aktualisierung wird nur angewendet, wenn Sie die Aktualisierung für ausgewählte Instanzen manuell starten oder wenn von der verwalteten Instanzgruppe neue Instanzen erstellt werden. Die verwaltete Instanzgruppe erstellt dann neue Instanzen, wenn ihre Größe durch einen anderen Dienst, z. B. Autoscaling, oder manuell durch einen Nutzer geändert wird. Compute Engine startet hierbei nicht selbst Anfragen, um opportunistische Aktualisierungen anzuwenden.

In bestimmten Fällen ist eine opportunistische Aktualisierung sinnvoll, um die Stabilität des Systems nicht unnötig zu gefährden. Wenn es sich beispielsweise um ein nicht kritisches Update handelt, das bei Bedarf angewendet werden kann, aber nicht dringend ist, und für die verwaltete Instanzgruppe Autoscaling eingerichtet ist, können Sie eine opportunistische Aktualisierung durchführen, damit Compute Engine Ihre bestehenden Instanzen nicht aktiv löscht, um das Update anzuwenden. Beim Verringern der Größe beendet der Autoscaler bevorzugt Instanzen mit der alten Vorlage sowie Instanzen, die noch nicht den Status RUNNING haben.

Legen Sie für das Typattribut im Befehlszeilentool gcloud oder der API den Wert OPPORTUNISTIC oder PROACTIVE fest, um eine Aktualisierung als opportunistisch oder proaktiv einzurichten.

Console

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

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Rolling Update.
  4. Wählen Sie unter Vorlage eine Vorlage für die Aktualisierung der Instanzgruppe aus und legen Sie eine Zielgröße für die Vorlage fest.
  5. Wählen Sie als Updatemodus zwischen "proaktiv" (umgehend) und "opportunistisch" (bei Gelegenheit).
  6. Klicken Sie auf Aktualisieren, um das Update zu starten.

gcloud

Mit dem gcloud-Befehlszeilentool:

gcloud compute instance-groups managed rolling-action start-update instance-group-name \
    --version template=instance-template \
    --type opportunistic|proactive \
    [--zone zone | --region region]

API

Fügen Sie in der Nutzlast der Aktualisierungsanfrage das Attribut type unter updatePolicy ein: Ersetzen Sie new-template durch den Namen der neuen Vorlage, die Sie testen möchten. Wenn Sie eine opportunistische Aktualisierung vornehmen möchten, ersetzen Sie PROACTIVE durch OPPORTUNISTIC.

{
  "updatePolicy": {
    "type": "PROACTIVE" # Performs a proactive update
  },
  "versions": [{
    "instanceTemplate": "global/instanceTemplates/new-template",
    }]
}

Ausgewählte Instanzen aktualisieren

Wenn Sie ein opportunistisches Update starten, müssen Sie warten, bis Compute Engine das Update bei Gelegenheit implementiert. Wenn Sie jedoch mehr Kontrolle über dessen Einführung haben möchten, können Sie das Update auch für bestimmte Instanzen in der verwalteten Instanzgruppe manuell starten.

Das manuelle Starten von Updates bietet folgende Vorteile:

  • Sie können auswählen, welche Instanzen Sie aktualisieren möchten.
  • Sie können ein Update so anwenden, dass die Unterbrechung nur so lange dauert, bis es abgeschlossen ist. Wenn Sie beispielsweise nur Metadaten aktualisieren, muss die Instanz möglicherweise nicht neu gestartet werden, um die Aktualisierung abzuschließen. Beim manuellen Starten des Updates wird automatisch die minimal erforderliche Aktion ausgeführt.
  • Sie können den Neustart oder die Neuerstellung von Instanzen erzwingen, auch wenn diese Aktionen zum Anwenden des Updates nicht erforderlich sind. Sie können beispielsweise eine VM auch dann neu starten, wenn Sie nur ihre Metadaten aktualisieren, da Ihre Gastsoftware beim Booten der VM die neuen Metadaten abrufen muss.
  • Sie können ein Update verhindern, wenn es zu einer längeren Unterbrechung führen würde, als gerade tragbar ist.
  • Sie können sofort eine Aktualisierung aller ausgewählten Instanzen durchführen, ohne dass für den Rollout die Einschränkungen maxSurge und maxUnavailable gelten.

Mindestaktion und umfangreichste erlaubte Aktion

Je nach Art der Aktualisierung kann diese sich negativ auf den Status der Instanz auswirken. Beispielsweise müssen Sie zum Ändern des Bootlaufwerks einer Instanz die Instanz löschen und ersetzen.

Sie können das Maß der Unterbrechung mithilfe der Flags minimal-action und most-disruptive-allowed-action steuern:

  • Mit minimal-action können Sie eine umfangreichere Aktion erzwingen, als erforderlich ist.
  • Mit most-disruptive-allowed-action können Sie ein Update verhindern, wenn es zu einer längeren Unterbrechung führen würde, als gerade tragbar ist.

Beim Aktualisieren ausgewählter Instanzen können diese Flags zusammen mit folgenden Aktionen verwendet werden:

AktionBeschreibungWelche Instanzattribute können aktualisiert werden?
NONEDie Instanz wird auf keinerlei Art gestört.
REFRESHDie Instanz wird nicht gestoppt.Zusätzliche Laufwerke, Instanzmetadaten, Labels
RESTARTDie Instanz wird gestoppt und noch einmal gestartet.Zusätzliche Laufwerke, Instanzmetadaten, Labels, Maschinentyp
REPLACEDie Instanz wird gelöscht und noch einmal erstellt.Alle Instanzattribute, die in der Instanzvorlage oder der instanzspezifischen Konfiguration gespeichert sind

minimal-action ist standardmäßig auf NONE gesetzt. 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.

most-disruptive-allowed-action ist standardmäßig auf REPLACE gesetzt. Wenn ein Update eine umfassendere Aktion erfordert, als die mit diesem Flag festgelegte, schlägt die Aktualisierungsanfrage fehl. Wenn Sie zum Beispiel RESTART als umfangreichste erlaubte Aktion festlegen, schlägt der Versuch, das Bootlaufwerk-Image zu aktualisieren, fehl. Denn dieses Update erfordert eine Neuerstellung der Instanz, eine umfangreichere Aktion als einen Neustart.

Sie können ausgewählte Instanzen mit dem gcloud-Tool oder der API aktualisieren.

gcloud

Nachdem Sie ein opportunistisches Update gestartet haben, wenden Sie das Update mit dem Unterbefehl update-instances auf bestimmte Instanzen an.

gcloud compute instance-groups managed update-instances instance-group-name \
    --instances instance-names \
    --most-disruptive-allowed-action disruption-level \
    --minimal-action disruption-level

Dabei gilt:

  • instance-group-name ist der Name der Instanzgruppe, für die Aktualisierungen ausstehen.
  • instance-names ist eine Liste von Instanzen, die sofort aktualisiert werden sollen.
  • disruption-level ist die minimale oder maximale Unterbrechungsstufe. Dies kann none, refresh, restart oder replace sein.
    • Der Standardwert von minimal-action ist none.
    • Der Standardwert von most-disruptive-allowed-action ist replace.

Wenn Sie warten müssen, bis alle angegebenen Instanzen aktualisiert wurden, prüfen Sie den Status der Gruppe und warten Sie, bis die Gruppe stabil ist.

API

Nachdem Sie ein opportunistisches Update gestartet haben, senden Sie eine POST-Anfrage an die Methode regionInstanceGroupManagers.applyUpdatesToInstances. Verwenden Sie für eine zonal verwaltete Instanzgruppe die zonale Methode instanceGroupManagers.applyUpdatesToInstances.

POST https://compute.googleapis.com/compute/v1/projects/project/regions/region/instanceGroupManagers/instance-group-name/applyUpdatesToInstances
{
  "instances": "zones/zone/instances/instance-name","zones/zone/instances/instance-name"
  "minimalAction": disruption-level,
  "mostDisruptiveAllowedAction": disruption-level
}

Dabei gilt:

  • instance-group-name ist der Name der Instanzgruppe, für die Aktualisierungen ausstehen.
  • zone ist die Zone einer Instanz, die sofort aktualisiert werden soll.
  • instance-name ist der Name einer Instanz, die sofort aktualisiert werden soll.
  • disruption-level ist die minimale oder maximale Unterbrechungsstufe. Dies kann NONE, REFRESH, RESTART oder REPLACE sein.
    • Der Standardwert von minimalAction ist NONE.
    • Der Standardwert von mostDisruptiveAllowedAction ist REPLACE.

Ähnlich wie bei anderen Methoden für verwaltete Instanzgruppen sind bei applyUpdatesToInstances die Updates erst einmal nur geplant. Dies bedeutet, dass eine Vorgangsantwort zurückgegeben wird. Wenn der Vorgang abgeschlossen ist (DONE), enthält listManagedInstances die Liste der Instanzen und deren currentAction-Felder. Die Werte dieser Felder wurden in REFRESHING, RESTARTING oder RECREATING geändert. Wenn der Vorgang fehlschlägt, beispielsweise aufgrund gleichzeitiger Änderungen an der Gruppe, wird dieser Fehler im Feld lastAttempt.errors vermerkt.

Wenn Sie warten müssen, bis alle angegebenen Instanzen aktualisiert wurden, prüfen Sie den Status der Gruppe und warten Sie, bis die Gruppe stabil ist.

Rollierende Ersetzung oder rollierenden Neustart durchführen

Mit den Befehlen restart und replace können Sie auch einen rollierenden Neustart bzw. eine rollierende Ersetzung der VM-Instanzen in einer verwalteten Instanzgruppe durchführen. Ähnlich wie beim Befehl start-update können Sie jede der Konfigurationsoptionen für einen Neustart oder einen Ersetzungsvorgang festlegen. Bei einem rollierenden Neustart oder einer rollierenden Ersetzung ändert sich an der Instanzgruppe nichts. Dies gilt auch für die Instanzvorlage. Dabei werden nur die Instanzen in der Gruppe mit der von Ihnen gewählten Methode aktualisiert.

Für eine rollierende Ersetzung oder einen rollierenden Neustart gibt es viele Gründe. Eine regelmäßige Aktualisierung der VM-Instanzen ist unter anderem in folgenden Fällen hilfreich:

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

Sie können die Google Cloud Console, das gcloud-Befehlszeilentool oder die API verwenden, um eine Ersetzung durchzuführen, bei der alle Instanzen gelöscht und durch neue Instanzen ersetzt werden:

Console

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

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie aktualisieren möchten.
  3. Klicken Sie oben auf der Seite auf Schrittweises Neustarten/Ersetzen.
  4. Wählen Sie aus, ob die Instanzen neu gestartet oder ersetzt werden sollen. Bei einem Neustart werden die Methoden stop und start auf den Instanzen ausgeführt. Beim Ersetzen werden die Instanzen dagegen aktiv gelöscht und neu erstellt.
  5. Optional können Sie die Werte für Konfigurationsoptionen wie Maximal zu viel, Maximal nicht verfügbar und Mindestwartezeit festlegen.
  6. Klicken Sie auf die Schaltfläche Neu starten oder Ersetzen, um das Update zu starten.

gcloud

gcloud compute instance-groups managed rolling-action replace instance-group-name

Mit diesem Befehl werden alle Instanzen in der verwalteten Instanzgruppe nacheinander ersetzt. Falls ein vollständiges Ersetzen eine zu starke Unterbrechung bedeutet, können Sie stattdessen auf einen rollierenden Neustart zurückgreifen. Dabei werden die Instanzen nicht gelöscht, sondern nur 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, maxUnavailable, min-ready) zusätzlich anpassen.

API

Stellen Sie in der API eine PATCH-Anfrage für die Gruppe und legen Sie eine proaktive updatePolicy fest, wobei für minimalAction entweder RESTART oder REPLACE gewählt wird. Dies hängt davon ab, ob Sie eine rollierende Ersetzung durchführen möchten, bei der jede Instanz gelöscht und durch eine neue ersetzt wird, oder einen rollierenden Neustart, bei dem jede Instanz gestoppt und neu gestartet wird. Sowohl für RESTART als auch für REPLACE müssen Sie die Attribute versions.instanceTemplate und versions.name angeben (z. B. v2), um die Aktion zu starten.

Eine rollierende Ersetzung kann z. B. so aussehen:

PATCH https://compute.googleapis.com/compute/v1/projects/my-project/zones/zone/instanceGroupManagers/instance-group-name

{
 "updatePolicy": {
  "minimalAction": "REPLACE",
  "type": "PROACTIVE"
 },
 "versions": [
  {
   "instanceTemplate": "global/instanceTemplates/example-template",
   "name": "v2"
  }
 ]
}

Ein rollierender Neustart kann folgendermaßen durchgeführt werden:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

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

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 maxSurge auf 0 setzen, dauert die Aktualisierung länger, aber mit replacementMethod:recreate behalten die aktualisierten Instanzen ihre Namen bei.

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.

Geben Sie die Ersetzungsmethode mithilfe des gcloud-Befehlszeilentools oder der API an.

gcloud

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

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]

Wenn Sie warten müssen, bis alle angegebenen Instanzen aktualisiert wurden, prüfen Sie den Status der Gruppe und warten Sie, bis die Gruppe stabil ist.

API

Erstellen Sie eine Anfrage an die patch-Methode der verwalteten Instanzgruppe und fügen Sie das Feld updatePolicy.replacementMethod ein. Verwenden Sie für regionale MIGs die regionale Methode patch.

PATCH /compute/v1/projects/project/zones/zone/instanceGroupManagers/instance-group-name
{
    "updatePolicy": {
        "type": "PROACTIVE",
        "maxUnavailable": { "fixed": 5 },
        "replacementMethod": "RECREATE"
    },
    "versions": [ {
        "instanceTemplate": "global/instanceTemplates/new-template"
    } ]
}

Regionale verwaltete Instanzgruppe aktualisieren

Eine regionale verwaltete Instanzgruppe enthält VM-Instanzen, die innerhalb einer Region auf mehrere Zonen verteilt sind, im Gegensatz zu einer zonalen verwalteten Instanzgruppe, die nur Instanzen in einer Zone enthält. Mit einer regionalen verwalteten Instanzgruppe haben Sie die Möglichkeit, Ihre Instanzen über mehrere Zonen zu verteilen, um die Verfügbarkeit Ihrer Anwendung zu erhöhen. 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 verwalteten Instanzgruppe mit dem Updater läuft im Prinzip genauso ab wie bei einer zonalen verwalteten Instanzgruppe. Die wenigen Unterschiede werden unten beschrieben. Wenn Sie die Aktualisierung einer regionalen Instanzgruppe starten, aktualisiert der Updater die Instanzen immer proportional und gleichmäßig über alle 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 einer regional und einer zonal verwalteten Instanzgruppe

Bevor Sie mit der Aktualisierung einer regionalen verwalteten Instanzgruppe beginnen, sollten Sie sich mit den Unterschieden zum Verhalten einer zonalen verwalteten Instanzgruppe vertraut machen:

  • Die standardmäßigen Aktualisierungsparameter für regionale verwaltete Instanzgruppen sind maxUnavailable=number-of-zones und maxSurge=number-of-zones, wobei number-of-zones die Anzahl von ausgewählten Zonen für die regionale verwaltete Instanzgruppe ist, standardmäßig also 3.

  • Wenn Sie bei der Definition eines Updates feste Zahlen verwenden, müssen sie entweder 0 oder gleich bzw. größer als die Anzahl von Zonen sein, die der regional verwalteten Instanzgruppe zugeordnet sind. Wenn die Instanzgruppe beispielsweise auf drei Zonen verteilt ist, können Sie maxSurge nicht auf 1 oder 2 setzen, da 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 verwalteten Instanzgruppe dividiert und gleichmäßig darauf 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 Instanzen zu 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 verwaltete Instanzgruppe 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 verwalteten Instanzgruppe 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. Hier gelten dieselben Regeln wie für die Aktualisierung zonal verwalteter Instanzgruppen.

Updates beobachten

Ein Rolling Update kann einige Zeit dauern. Sie können den Fortschritt einer Aktualisierung beobachten. Dazu prüfen Sie den status der verwalteten Instanzgruppe oder den currentAction-Wert jeder Instanz in der verwalteten Instanzgruppe.

Gruppenstatus

Auf Gruppenebene fügt Compute Engine Werte in das schreibgeschützte Feld status ein, das die Flags versionTarget.isReached und isStable enthält. Sie können das gcloud-Tool oder die API verwenden, um auf diese Flags zuzugreifen. Sie können auch die Console verwenden, um die Anzahl der bereits aktualisierten Instanzen und die Zielanzahl der zu aktualisierenden Instanzen aufzurufen.

Console

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

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

    Zur Seite "Instanzgruppen"

  2. Wählen Sie die Instanzgruppe aus, die Sie beobachten möchten. Auf der Übersichtsseite der Instanzgruppe sehen Sie die Vorlagen, die die einzelnen Instanzen verwenden.
  3. Klicken Sie auf den Tab Details, um Einzelheiten anzuzeigen.

Auf der Seite Details sehen Sie die aktuelle und die angestrebte Anzahl der aktualisierten Instanzen für jede Instanzvorlage sowie die Aktualisierungsparameter.

gcloud

Wenn Sie wissen möchten, ob die Aktualisierung der Instanzgruppe vollständig durchgeführt wurde, verwenden Sie den describe-Befehl, um status.versionTarget.isReached==true zu prüfen. Wenn alle Instanzen in der Gruppe ausgeführt werden und fehlerfrei sind, d. h. currentAction der einzelnen verwalteten Instanzen NONE ist, gilt status.isStable==true.

Die Stabilität einer verwalteten Instanzgruppe hängt von Gruppenkonfigurationen ab, die über den Updater hinausgehen. Wenn Ihre Gruppe beispielsweise automatisch skaliert wird und wenn sie derzeit horizontal skaliert wird, dann gilt isStable==false aufgrund des Autoscaling-Vorgangs.

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region zone]

Das gcloud-Tool liefert detaillierte Informationen zur Instanzgruppe, einschließlich der Felder status.versionTarget.isReached und status.isStable.

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]

API

Wenn Sie wissen möchten, ob die Aktualisierung der Instanzgruppe vollständig durchgeführt wurde, verwenden Sie die Methode get des Instanzgruppenmanagers, um status.versionTarget.isReached==true zu prüfen. Wenn alle Instanzen in der Gruppe ausgeführt werden und fehlerfrei sind, d. h. currentAction der einzelnen verwalteten Instanzen NONE ist, gilt status.isStable==true.

Die Stabilität einer verwalteten Instanzgruppe hängt von Gruppenkonfigurationen ab, die über den Updater hinausgehen. Wenn Ihre Gruppe beispielsweise automatisch skaliert wird und wenn sie derzeit horizontal skaliert wird, dann gilt isStable==false aufgrund des Autoscaling-Vorgangs.

GET https://compute.googleapis.com/compute/v1/projects/project-d/zones/zone/instanceGroupManagers/instance-group-name/get

Wenn es sich um eine regionale verwaltete Instanzgruppe handelt, ersetzen Sie zones/zone durch regions/region.

Die API gibt detaillierte Informationen über die Instanzgruppe zurück, einschließlich der Felder status.versionTarget.isReached und status.isStable.

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

Die Einführung eines Updates gilt als abgeschlossen, wenn alle VM-Instanzen in der Gruppe in ihrer Zielversion erstellt wurden oder gerade erstellt werden. Im Falle einer vollständigen Einführung sind alle Instanzen so konfiguriert, dass sie die neue Instanzvorlage verwenden. Im Fall einer teilweisen Einführung werden die Instanzen gemäß der angegebenen Zielaufteilung zwischen den Instanzvorlagen konfiguriert.

Sie können prüfen, ob die Einführung einer Aktualisierung abgeschlossen ist. Prüfen Sie dazu den Wert im Feld status.versionTarget.isReached einer Ressource instanceGroupManagers oder regionInstanceGroupManagers.

  • status.versionTarget.isReached wird auf true gesetzt, wenn alle VM-Instanzen mit der Zielversion (versions[]) erstellt wurden.
  • status.versionTarget.isReached wird auf false gesetzt, wenn mindestens eine VM die Zielversion (versions[]) noch nicht verwendet. Oder, im Fall eines Canary Updates, ist status.versionTarget.isReached auf false gesetzt, wenn die Anzahl der VMs, die eine Zielversion (versions[].instanceTemplates) verwenden, nicht mit deren Zielgröße (versions[].targetSize) übereinstimmen.

Prüfen, ob die verwaltete Instanzgruppe stabil ist

Sie können prüfen, ob eine verwaltete Instanzgruppe ausgeführt wird und fehlerfrei ist, indem Sie den Wert des Feldes status.isStable prüfen.

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

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

  • Gerade wird keine der Instanzen in der verwalteten Instanzgruppe geändert und die currentAction hat für alle Instanzen den Wert NONE.
  • Für die Instanzen in der verwalteten Instanzgruppe stehen keine Änderungen aus.
  • Die verwaltete Instanzgruppe selbst wird gerade nicht geändert.

Verwaltete Instanzgruppen können auf verschiedene Arten geändert werden. 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 Gruppe zu ändern.
  • Eine Ressource für die automatische Reparatur ersetzt in der verwalteten Instanzgruppe eine oder mehrere fehlerhafte Instanzen.
  • In einer regional verwalteten Instanzgruppe werden einige der Instanzen neu verteilt.

Sobald alle Aktionen abgeschlossen wurden, wird für die verwaltete Instanzgruppe status.isStable wieder auf true gesetzt.

Aktuelle Aktionen auf Instanzen

Zum Anzeigen, dass currentAction ausgeführt wird und zum Anzeigen des status jeder Instanz in einer verwalteten Instanzgruppe können Sie das gcloud-Befehlszeilentool oder die API verwenden.

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud gibt eine Liste der Instanzen in der Instanzgruppe sowie ihre jeweiligen Zustände und aktuellen Aktionen zurück. Beispiel:

NAME               ZONE           STATUS    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

API

Senden Sie in der API eine GET-Anfrage an die Methode regionInstanceGroupManagers.listManagedInstances. Verwenden Sie für eine zonal verwaltete Instanzgruppe die Methode instanceGroupManagers.listManagedInstances.

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/listManagedInstances

Die API gibt eine Liste der Instanzen in der Gruppe zurück. Dabei wird jeweils auch instanceStatus und currentAction ausgegeben.

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

Der Status der einzelnen Instanzen in einer verwalteten Instanzgruppe wird durch das zugehörige Feld instanceStatus beschrieben. Eine Liste der gültigen Werte für das Feld instanceStatus finden Sie unter Status einer Instanz prüfen.

Wenn an der Instanz eine Änderung vorgenommen wird, enthält das Feld currentAction eine der folgenden Aktionen als Wert, damit Sie den Fortschritt der Änderung verfolgen können. Andernfalls hat das Feld currentAction den Wert NONE.

Folgende currentAction-Werte sind möglich:

  • ABANDONING: Die Instanz wird gerade aus der verwalteten Instanzgruppe 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 verwaltete Instanzgruppe nicht noch einmal, die Instanz 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.
  • VERIFYING: Die Instanz wurde erstellt und wird gerade verifiziert.
  • NONE: Für die Instanz werden gerade keine Aktionen durchgeführt.

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.

Der folgende gcloud-Befehl 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]

Ersetzen Sie dabei old-instance-template-name durch den Namen der Instanzvorlage, auf die die Instanzgruppe zurückgesetzt werden soll.

Senden Sie in der API eine PATCH-Anfrage an die Instanzgruppenmanager-Ressource:

PATCH https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name

Wenn es sich um eine regionale verwaltete Instanzgruppe handelt, ersetzen Sie zones/zone durch regions/region.

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

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

Wenn es sich um eine regional verwaltete Instanzgruppe mit weniger als 10 Instanzen handelt, müssen Sie für maxUnavailable einen festen Wert verwenden. Sie müssen den Wert dann auf die Anzahl von Instanzen in der Gruppe festlegen:

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": number-of-instances-in-group
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/old-template" # Old instance template
    }
   ]
}

Der Updater behandelt dies als reguläre Aktualisierungsanfrage. Daher können Sie mit der Anfrage alle in diesem Dokument beschriebenen Aktualisierungsoptionen angeben.

Die Aktualisierungsgeschwindigkeit 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 Dienst wartet, bevor er eine Instanz als erfolgreich aktualisiert betrachtet und mit der nächsten Instanz fortfährt.
  3. Aktivieren Sie Systemdiagnosen, damit der Dienst 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. Starten Sie die Updates für bestimmte Instanzen manuell, um diese Instanzen sofort zu aktualisieren.

Sie können die Aktualisierungsgeschwindigkeit auch mithilfe einer Kombination dieser Parameter steuern.

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 verwalteten Instanzgruppe nicht durch andere Dienste wie Autoscaling angepasst wird, bedeutet diese Änderung, dass die Aktualisierung stoppt.

Führen Sie den folgenden Befehl aus, um aus einer proaktiven Aktualisierung eine opportunistische zu machen:

gcloud compute instance-groups managed rolling-action stop-proactive-update instance-group-name \
    [--zone zone | --region region]

Wenn Sie die Aktualisierung nach dem Wechsel vollständig anhalten möchten, gehen Sie so vor:

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

    gcloud compute instance-groups managed list-instances instance-group-name \
        [--zone zone | --region region]

    Das gcloud-Tool gibt eine Antwort mit einer Liste der Instanzen in der Instanzgruppe und ihren aktuellen Statuswerten zurück.

    >
    NAME               ZONE           STATUS   HEALTH_STATE  ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
    vm-instances-9pk4  us-central1-f  RUNNING  HEALTHY       NONE      my-new-template
    vm-instances-j1h8  us-central1-f  RUNNING  HEALTHY       NONE      my-old-template
    vm-instances-ngod  us-central1-f  STAGING  UNKNOWN       CREATING  my-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=my-old-template \
        --canary-version template=my-new-template,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.

Beziehung zwischen den Attributen "versions" und "instanceTemplate" einer verwalteten Instanzgruppe

Google empfiehlt, Instanzvorlagen für verwaltete Instanzgruppen mit dem Feld versions zu konfigurieren.

Die Funktionalität des Legacy-Feldes instanceTemplate und des Feldes versions überschneidet sich, da Sie mit beiden Feldern angeben können, welche Instanzvorlage die verwaltete Instanzgruppe zum Erstellen neuer Instanzen verwenden soll. Sie können jedoch nur mit dem Feld versionseine erweiterte (Canary-)Konfiguration mit zwei Vorlagen definieren.

Zugunsten der Abwärtskompatibilität unterstützen verwaltete Instanzgruppen weiterhin das Festlegen des übergeordneten Feldes instanceTemplate. Google empfiehlt jedoch, nur noch das Feld versions zu verwenden. Die gleichzeitige Verwendung des übergeordneten Feldes instanceTemplate und des Feldes versions kann zu Unklarheiten und Verwirrung führen.

Wenn Sie beim Aufrufen der Methoden update() und patch() sowohl das Feld instanceTemplate als auch das Feld versions angeben, gibt es drei mögliche Ergebnisse:

  • Sie legen für beide Felder den gleichen Wert fest.

    Dies ist eine gültige Anfrage. In diesem Fall entsteht keine Mehrdeutigkeit und die neue Instanzvorlage wird auf die verwaltete Instanzgruppe angewendet.

    In der folgenden Anfrage wird beispielsweise im übergeordneten Feld instanceTemplate und im Feld versions dieselbe Instanzvorlage angegeben, die sich von der vorhandenen aktuellen Vorlage unterscheidet, sodass die verwaltete Instanzgruppe auf die neue Instanzvorlage aktualisiert wird:

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Sie legen beide Felder auf Werte fest, die nicht übereinstimmen, aber nur ein Wert weicht von der aktuellen Instanzvorlage in der verwalteten Instanzgruppe ab.

    Das ist eine gültige Anfrage. Das Feld, das von der aktuellen Einstellung abweicht, wird als der gewünschte Wert angewendet. Beispiel: Sie rufen die Methode get() auf, ändern eines der Felder und rufen dann die Methode update() mit nur einem geänderten Feld auf:

    {
     "instanceTemplate": "global/instanceTemplates/current-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Sie haben für beide Felder Werte festgelegt, die nicht übereinstimmen, und beide Werte weichen von der aktuellen Instanzvorlage in der verwalteten Instanzgruppe ab.

    Diese Einstellung ist ungültig und gibt einen Fehler zurück, da kein eindeutiger Intent erkennbar ist.

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/a-different-new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    

Die Felder "versions" und "instanceTemplate" sowie die Methode "get()"

Wenn Sie nur eine Instanzvorlage angeben, entweder über das übergeordnete Feld instanceTemplate oder über das Feld versions oder über beide, gibt die Methode get() in ihrer Antwort beide Felder zurück. Dadurch wird das neue Feld versions abwärtskompatibel. Solange Sie nur eine Instanzvorlage in einem dieser Felder angeben, ändert sich an der Rückgabe der Methode get() im Feld instanceTemplate nichts.

Enthält das Feld versions dagegen zwei Instanzvorlagen, gibt die Methode get() ein leeres übergeordnetes Feld instanceTemplate zurück. Da es nicht möglich ist, im übergeordneten Feld instanceTemplate eine Canary-Konfiguration mit zwei Instanzvorlagen unmissverständlich anzugeben, wird es bei Canary Updates nicht verwendet.

Das Feld "versions" und die Methode "setInstanceTemplate()"

Aus Gründen der Abwärtskompatibilität verhält sich die Methode setInstanceTemplate() wie zuvor, sodass Sie die Vorlage ändern können, auf die sich die verwaltete Instanzgruppe zum Erstellen von Instanzen stützt. Wenn Sie diese Methode aufrufen, wird das Feld versions mit der Instanzvorlage überschrieben, die durch die Methode setInstanceTemplate() angegeben wird.

Die Methode setInstanceTemplate() legt auch die updatePolicy auf OPPORTUNISTIC fest. Dadurch wird verhindert, dass die verwaltete Instanzgruppe aktiv eine Instanzvorlage bereitstellt, die nicht explizit im Feld versions angegeben ist.

Weitere Informationen