Aktualisierungen für verwaltete Instanzgruppen bereitstellen

Eine verwaltete Instanzgruppe enthält eine oder mehrere VM-Instanzen, die über eine Instanzvorlage gesteuert werden. Zum Aktualisieren der Instanzen in der Gruppe können Sie über das Managed Instance Group Updater-Feature eine Aktualisierungsanfrage an die gesamte Gruppe stellen.

Weitere Informationen zu Instanzgruppen finden Sie in der Übersicht über Instanzgruppen.

Mit dem Managed Instance Group Updater können Sie ganz einfach neue Softwareversionen auf Instanzen in Ihren verwalteten Instanzgruppen bereitstellen. Dabei bestimmen Sie selbst, wie schnell dies geschieht, inwiefern Ihr 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.

Vorbereitung

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 eine Updateanfrage stellen, bestätigt die API in ihrer 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, keinen Funktionsaufruf.

  • Die Updater-Funktion unterstützt maximal zwei Instanzvorlagenversionen in Ihrer verwalteten Instanzgruppe. 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. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Seite "Instanzgruppen" aufrufen

  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 das Drop-down-Menü und wählen Sie die neue Vorlage für das Update aus.
  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

Führen Sie im Tool gcloud den Befehl rolling-action start-update aus:

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

Dabei gilt:

  • [INSTANCE_GROUP] ist der Name der zu aktualisierenden Instanzgruppe.
  • [INSTANCE_TEMPLATE] ist die neue Instanzvorlage, auf die die Instanzgruppe aktualisiert werden soll.
  • Eine [ZONE] oder eine [REGION] für diese Instanzgruppe ist erforderlich. Wenn es sich um eine zonale Instanzgruppe handelt, geben Sie die Zone an. Ist es dagegen eine regionale Instanzgruppe, geben Sie die Region an.

API

Stellen Sie in der API eine PATCH-Anfrage an die folgende URL:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[MANAGED_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 überwachen, 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, erstellt die verwaltete Instanzgruppe bis zu fünf neue Instanzen mit der neuen Instanzvorlage über die Zielgröße hinaus. 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 für maxSurge nicht festlegen, wird der Standardwert verwendet. Bei zonal verwalteten Instanzgruppen ist 1 der Standardwert für maxSurge. Bei regional verwalteten Instanzgruppen lautet die Standardeinstellung [NUMBER_OF_ZONES], wobei [NUMBER_OF_ZONES] der Anzahl an Zonen entspricht, 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 einen Prozentsatz, falls die verwaltete Instanzgruppe mindestens 10 Instanzen umfasst. 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, gehen nur 5 Instanzen gleichzeitig offline, um aktualisiert zu werden. 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. Beispielsweise sind beim Anpassen der Größe der Instanzgruppe Instanzen, die gerade erstellt werden, möglicherweise nicht verfügbar. Sie werden dann bei maxUnavailable berücksichtigt. Sie können entweder eine feste Anzahl angeben oder einen Prozentsatz, falls die verwaltete Instanzgruppe mindestens 10 Instanzen umfasst. Wenn Sie einen Prozentsatz festlegen, rundet der Updater bei Bedarf die Anzahl der Instanzen ab.

Der Standardwert für maxUnavailable in einer zonal verwalteten Instanzgruppe ist 1. In einer regional verwalteten Instanzgruppe lautet die Standardeinstellung [NUMBER_OF_ZONES], also die Anzahl der ausgewählten Zonen für die regional verwaltete Instanzgruppe. Der Standardwert ist in diesem Fall 3.

Mindestwartezeit

Durch minReadySeconds legen Sie fest, wie lange gewartet wird, bis eine neu erstellte oder neu gestartete Instanz als aktualisiert gilt. 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. Bis der durch autohealingPolicies.initialDelaySec festgelegte Zeitraum für die Systemdiagnose den Wert HEALTHY zurückgibt
  2. Die durch minReadySeconds festgelegte Zeit

Falls die Systemdiagnose nicht innerhalb der durch initialDelaySec bestimmten Frist den Status HEALTHY zurückgibt, betrachtet der Updater die VM-Instanz als fehlerhaft und stoppt unter Umständen die Aktualisierung. Während die VM-Instanz in den Zeiträumen geprüft wird, die durch initialDelaySec und minReadySeconds festgelegt sind, 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 minReadySeconds kann ein Höchstwert von 3.600 Sekunden (1 Stunde) angegeben werden.

Mindestaktion

Mit einem Wert für das Attribut "Mindestaktion" legen Sie fest, was der Updater mindestens tun muss, um die Instanzen der Gruppe zu aktualisieren. Wenn Sie beispielsweise REPLACE als Mindestaktion einrichten, werden alle betroffenen Instanzen gelöscht und durch eine neue Instanz ersetzt, unabhängig davon, ob das erforderlich ist.

Durch die Mindestaktion ist sichergestellt, dass der Updater diesen Vorgang auf alle Fälle durchfü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. Ist dafür jedoch eine umfangreichere Maßnahme erforderlich, wird diese auch ausgeführt. 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 (über eine stop- und start-Anfrage) neu. Wenn für die Aktualisierung ein Austausch der Instanz erforderlich ist (für eine Änderung des Images müsste beispielsweise die Instanz gelöscht und neu erstellt werden), wird zwangsweise die Aktion REPLACE ausgeführt.

  • REPLACE: Löscht die bestehende Instanz und erstellt eine neue anhand der Zielvorlage. Der Updater erstellt eine ganz neue 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.

Diagramm zu den Auswirkungen unterschiedlicher Aktualisierungsoptionen auf Ihre Anfrage

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

Ein Canary Update starten

Mit der Instance Group Updater-Funktion 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 Funktionen an einigen 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.

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. So können Sie beispielsweise festlegen, dass 20 % der Instanzen basierend auf new-instance-template erstellt werden, während der Rest weiterhin mit old-instance-template ausgeführt wird. 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. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Seite "Instanzgruppen" aufrufen

  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 umgehend (die Gruppe löscht und 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 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 Befehlszeilentool gcloud 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]]

Dabei gilt:

  • [CURRENT_TEMPLATE] ist die aktuelle Vorlage, mit der die Instanzgruppe ausgeführt wird.
  • [NEW_TEMPLATE] ist die neue Vorlage, die Sie testen möchten.
  • [SIZE] ist die Anzahl oder der Prozentsatz der Instanzen, auf die/den die Aktualisierung 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.
  • Eine [ZONE] oder eine [REGION] für diese Instanzgruppe ist erforderlich. Wenn es sich um eine zonale Instanzgruppe handelt, geben Sie die Zone an. Ist es dagegen eine regionale Instanzgruppe, 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

Stellen Sie in der API eine PATCH-Anfrage an den folgenden URI:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Die Nutzlast der Anfrage sollte sowohl die aktuelle Instanzvorlage als auch die neue Vorlage enthalten, 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]"
  }
 ]
}

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. Wenn dies nicht der Fall ist, legen Sie eine feste Anzahl fest.
  • [CURRENT_TEMPLATE] ist der Name der aktuellen Vorlage, 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. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Seite "Instanzgruppen" aufrufen

  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

Stellen Sie in der API eine PATCH-Anfrage an den folgenden URI:

https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP_NAME]

Geben Sie im Text der Anfrage die neue Instanzvorlage als Wert für version an und nehmen Sie die alte Instanzvorlage heraus. Die Zielgröße lassen Sie ebenfalls weg, um das Update auf alle Instanzen anzuwenden. Der Text der Anfrage sieht dann so aus:

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

Ersetzen Sie [NEW_TEMPLATE] durch den Namen der neuen Instanzvorlage, die verwendet werden soll.

Eine 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 vorausschauend 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.

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. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Seite "Instanzgruppen" aufrufen

  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 Befehlszeilentool gcloud:

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:

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

Dabei ist [NEW_TEMPLATE] der Name der neuen Vorlage, die Sie testen möchten. Wenn Sie eine opportunistische Aktualisierung vornehmen möchten, ersetzen Sie PROACTIVE durch OPPORTUNISTIC.

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. Beispiel: Sie möchten eine VM neu starten, obwohl Sie nur deren Metadaten aktualisieren, da Ihre Gastsoftware die neuen Metadaten beim Start der VM 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 muss die VM zum Ändern des Maschinentyps neu gestartet werden, während sie zum Ändern des Boot-Images gelöscht und ersetzt werden muss.

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.Sekundäre Laufwerke, Instanzmetadaten, Labels
RESTARTDie Instanz wird gestoppt und noch einmal gestartet.Maschinentyp
REPLACEDie Instanz wird gelöscht und noch einmal erstellt.Alle in der Instanzvorlage gespeicherten Instanzattribute

minimal-action ist standardmäßig auf NONE gesetzt. Wenn ein Update eine umfangreichere Maßnahme erfordert, als Sie mit diesem Flag festgelegt haben, führt Compute Engine die Maßnahme 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 beispielsweise "RESTART" als umfangreichste erlaubte Aktion festlegen, schlägt der Versuch, das Bootlaufwerk-Image zu aktualisieren, fehl, da für dieses Update eine Instanzwiederherstellung erforderlich ist, also eine umfassendere Aktion als nur ein 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 beta compute instance-groups managed update-instances [INSTANCE_GROUP] \
    --instances [INSTANCE_NAMES] \
    --most-disruptive-allowed-action [DISRUPTION_LEVEL] \
    --minimal-action [DISRUPTION_LEVEL]

Dabei gilt:

  • [INSTANCE_GROUP] 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: NONE, REFRESH, RESTART, REPLACE.
    • minimal-action ist standardmäßig auf NONE gesetzt.
    • most-disruptive-allowed-action ist standardmäßig auf REPLACE gesetzt.

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, erstellen Sie eine POST-Anfrage an die Betamethode regionInstanceGroupManagers.applyUpdatesToInstances. Verwenden Sie für eine zonal verwaltete Instanzgruppe die zonale Methode instanceGroupManagers.applyUpdatesToInstances.

POST https://www.googleapis.com/compute/beta/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: NONE, REFRESH, RESTART, REPLACE.
    • minimalAction ist standardmäßig auf NONE gesetzt.
    • mostDisruptiveAllowedAction ist standardmäßig auf REPLACE gesetzt.

Ä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 von 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 lastAttempt.errors-Feld 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 rollierender Neustart

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 einfach 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 einer Anwendung, damit sie auf einer neuen virtuellen Maschine ausgeführt werden kann
  • Erzwingen einer regelmäßigen Ersetzung als Best Practice zum Testen von VMs
  • Aktualisierung des Betriebssystem-Images Ihrer VMs oder erneute Ausführung von Startskripts zur Aktualisierung der Software

So führen Sie eine Ersetzung aus, bei der alle Instanzen gelöscht und durch neue ersetzt werden:

Console

  1. Gehen Sie in der GCP Console zur Seite "Instanzgruppen".

    Seite "Instanzgruppen" aufrufen

  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 Neu starten oder Ersetzen, um das Update zu starten.

gcloud

gcloud compute instance-groups managed rolling-action replace [INSTANCE_GROUP]

Mit diesem Befehl werden alle Instanzen in der verwalteten Instanzgruppe nacheinander ersetzt. Falls ein vollständiges Ersetzen zu abrupt ist, können Sie stattdessen einen rollierenden Neustart durchführen. Dabei werden die Instanzen nicht gelöscht, sondern nur neu gestartet.

gcloud compute instance-groups managed rolling-action restart [INSTANCE_GROUP]

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 (zum Beispiel v2), um die Aktion zu starten.

Eine rollierende Ersetzung kann wie folgt aussehen:

PATCH https://www.googleapis.com/compute/v1/projects/myproject/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://www.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

Rollierender Neustart aller virtuellen Maschinen, wobei immer zwei gleichzeitig neu gestartet werden

Durch diesen Befehl werden immer zwei virtuelle Maschinen 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]]

Rollierender Neustart aller VMs so schnell wie möglich

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

Rollierendes Ersetzen aller VMs so schnell wie möglich

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

Regionale verwaltete Instanzgruppe aktualisieren

Eine regionale verwaltete Instanzgruppe enthält VM-Instanzen, die über mehrere Zonen innerhalb einer Region verteilt sind. Eine zonale verwaltete Instanzgruppe umfasst dagegen nur Instanzen innerhalb einer Zone. Mit einer regionalen verwalteten Instanzgruppe haben Sie die Möglichkeit, Ihre Instanzen über mehre 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 regional verwalteten Instanzgruppe mit dem Instance Group Updater-Feature läuft im Prinzip genauso ab wie bei einer zonal 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. Es ist nicht möglich, auszuwählen, welche Instanzen in welchen Zonen zuerst aktualisiert werden, oder nur Instanzen in einer Zone zu 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 Update einer zonalen verwalteten Instanzgruppe vertraut machen:

  • Die Standardaktualisierungsparameter für regional verwaltete Instanzgruppen sind maxUnavailable=[NUMBER_OF_ZONES] und maxSurge=[NUMBER_OF_ZONES], wobei [NUMBER_OF_ZONES] die Anzahl der Zonen ist, die für die regional verwaltete Instanzgruppe ausgewählt wurden. Der Standardwert ist in diesem Fall 3.

  • Wenn Sie bei der Definition einer Aktualisierung feste Zahlen verwenden, müssen sie entweder 0 oder gleich bzw. größer als die Anzahl der Zonen sein, die der regionalen verwalteten Instanzgruppe zugeordnet sind. Wenn die Instanzgruppe zum Beispiel auf drei Zonen verteilt ist, können Sie maxSurge nicht auf 1 oder 2 setzen, weil der Updater 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 übrig gebliebenen Instanzen zu einer zufällig ausgewählten Zone hinzu. Bei 10 Instanzen in drei Zonen befinden sich also in zwei Zonen 3 Instanzen und in einer Zone 4. 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 überwachen

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

Gruppenstatus

Auf Gruppenebene füllt Compute Engine das schreibgeschützte Feld status aus, das die Flags versionTarget.isReached und isStable enthält. Sie können das gcloud-Tool oder die API verwenden, um auf diese Flags zuzugreifen.

Wenn Sie wissen möchten, ob die Aktualisierung der Instanzgruppe vollständig durchgeführt wurde, prüfen Sie, ob status.versionTarget.isReached==true angezeigt wird. Wenn Sie prüfen möchten, ob alle Instanzen in der Gruppe ausgeführt werden und fehlerfrei sind (also die currentAction jeder verwalteten Instanz den Wert NONE hat), prüfen Sie, ob status.isStable==true angezeigt wird. Beachten Sie, dass die Stabilität einer verwalteten Instanzgruppe von Gruppenkonfigurationen abhängt, die nicht mit dem Updater zusammenhängen. Wenn Ihre Gruppe beispielsweise generell automatisch skaliert und gerade hochskaliert wird, wird aufgrund des Autoscaling-Vorgangs isStable==false angezeigt.

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 überwachen.

  1. Rufen Sie in der GCP Console die Seite "Instanzgruppen" auf.

    Seite "Instanzgruppen" aufrufen

  2. Wählen Sie die Instanzgruppe aus, die Sie überwachen 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

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

Das gcloud-Tool gibt detaillierte Informationen über die Instanzgruppe zurück, einschließlich der Felder status.versionTarget.isReached und status.isStable.

API

Stellen Sie in der API eine POST-Anfrage an den folgenden URI:

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/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.

status.versionTarget.isReached

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. Dazu prüfen Sie den Wert des Feldes status.versionTarget.isReached einer instanceGroupManagers- oder regionInstanceGroupManagers-Ressource.

status.versionTarget.isReached wird auf true gesetzt, wenn alle VM-Instanzen mit der Zielversion (versions[]) erstellt wurden oder gerade erstellt werden.

status.versionTarget.isReached wird auf false gesetzt, wenn mindestens eine VM noch nicht die Zielversion (versions[]) verwendet. Im Falle eines Canary Updates wird status.versionTarget.isReached dann auf false gesetzt, wenn die Anzahl der VMs, die eine Zielversion (versions[].instanceTemplates) verwenden, nicht seiner Zielgröße (versions[].targetSize) entspricht.

Wenn Sie den Befehl gcloud beta compute instance-groups managed wait-until mit dem Flag --version-target-reached verwenden, wird gewartet, bis status.versionTarget.isReached für die Gruppe auf true gesetzt wurde:

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

status.isStable

Sie können prüfen, ob eine verwaltete Instanzgruppe ausgeführt wird und fehlerfrei ist. Dazu prüfen Sie den Wert des Feldes status.isStable der zugeordneten Ressource instanceGroupManagers oder regionInstanceGroupManagers.

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.

Wenn Sie den Befehl gcloud beta compute instance-groups managed wait-until mit dem Flag --stable verwenden, wird gewartet, bis status.isStable für die Gruppe auf true gesetzt wurde:

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

Aktuelle Aktionen auf Instanzen

Mit dem gcloud-Befehlszeilentool oder der API können Sie die ausgeführte currentAction und den status jeder Instanz aufrufen.

gcloud

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud gibt als Antwort eine Liste der Instanzen in der Instanzgruppe sowie ihren jeweiligen Status und ihre jeweilige aktuelle Aktion 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           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

Führen Sie in der API eine POST-Anfrage für die Methode regionInstanceGroupManagers.listManagedInstances aus. Verwenden Sie für eine zonal verwaltete Instanzgruppe die Methode instanceGroupManagers.listManagedInstances.

POST https://www.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, einschließlich des instanceStatus und der currentAction jeder Instanz.

{
 "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 jeder Instanz in einer verwalteten Instanzgruppe wird durch das zugehörige instanceStatus-Feld 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 enthält das Feld currentAction den Wert NONE.

Mögliche Werte für currentAction sind:

  • 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 wurde gelöscht und wird gerade ersetzt.
  • REFRESHING: Die Instanz wird gerade aus den aktuellen Zielpools entfernt und anschließend 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.

Sobald eine Instanz erfolgreich aktualisiert wurde, wird im Feld instanceStatus der aktuelle Status der Instanz angezeigt.

Aktualisierung rückgängig machen

Es gibt keinen eigenen Befehl, um eine Aktualisierung rückgängig zu machen 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 Befehl sorgt zum Beispiel dafür, dass eine Aktualisierung so schnell wie möglich rückgängig gemacht wird:

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

Ersetzen Sie [OLD_INSTANCE_TEMPLATE] durch den Namen der alten Instanzvorlage, auf die die Instanzgruppe zurückgesetzt werden soll.

Stellen Sie in der API eine PATCH-Anfrage an folgenden URI:

https://www.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 Text der Anfrage die alte Instanzvorlage als Wert für 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 der Instanzen in der Gruppe festlegen:

{ "updatePolicy":
  {
    "maxUnavailable":
    {
      "fixed": [NUMBER_OF_INSTANCES_IN_GROUP]
    }
  },
 "versions": [
    {
      "instanceTemplate": "global/instanceTemplates/[OLD_TEMPLATE]" # Old instance template
    }
   ]
}

Der Instance Group Updater-Dienst behandelt dies als reguläre Aktualisierungsanfrage. Daher können Sie 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 für minReadySeconds einen hohen Wert 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 für maxUnavailable und maxSurge einen niedrigen Wert 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 bzw. 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 gerade von einem anderen Dienst wie Autoscaling angepasst wird, bedeutet der Wechsel zur opportunistischen Aktualisierung, dass diese "angehalten" wird.

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

Die Aktualisierung anschließend vollständig anzuhalten, funktioniert folgendermaßen:

  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 Tool gcloud gibt eine Liste der Instanzen in der Gruppe und ihren aktuellen Status zurück.

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

    In diesem Beispiel wurden zwei Instanzen bereits aktualisiert.

  2. Stellen Sie nun eine Anfrage für ein weiteres "Update". Geben Sie dabei die Zahl der schon 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-Dienst betrachtet diese Aktualisierung als abgeschlossen. Daher werden keine weiteren Instanzen aktualisiert und das Update wird angehalten.

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 versions eine erweiterte (Canary-)Konfiguration mit zwei Vorlagen definieren.

Aufgrund 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. Beide Felder gleichzeitig zu nutzen, 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 verwenden, gibt es drei verschiedene Möglichkeiten:

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

    Beispiel: In der folgenden Anfrage verweisen das übergeordnete Feld instanceTemplate und das Feld versions auf dieselbe Instanzvorlage, die sich von der aktuellen Vorlage unterscheidet. Die verwaltete Instanzgruppe wird auf die neue Instanzvorlage aktualisiert:

    {
     "instanceTemplate": "global/instanceTemplates/new-template",
     "versions": [
      {
       "instanceTemplate": "global/instanceTemplates/new-template"
      }
     ],
     "updatePolicy": {
       "type": "PROACTIVE"
     }
    }
    
  • Sie legen für beide Felder abweichende Werte fest, aber nur einer unterscheidet sich von der aktuellen Instanzvorlage in der verwalteten Instanzgruppe.

    Dies 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 legen für beide Felder Werte fest, die sich voneinander und von der aktuellen Instanzvorlage in der verwalteten Instanzgruppe unterscheiden.

    Diese Einstellung ist ungültig und gibt einen Fehler zurück, da keine klare Absicht 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 ist 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 eindeutig anzugeben, wird dieses bei Canary Updates nicht verwendet.

Das Feld versions und die Methode setInstanceTemplate()

Aus Gründen der Abwärtskompatibilität wurde das Verhalten der Methode setInstanceTemplate() nicht geändert. Sie können weiterhin die Vorlage ändern, die die verwaltete Instanzgruppe verwendet, um neue Instanzen zu erstellen. Wenn Sie diese Methode aufrufen, wird das Feld versions mit der Instanzvorlage überschrieben, die durch die Methode setInstanceTemplate() angegeben wird.

Darüber hinaus setzt die Methode die updatePolicy auf OPPORTUNISTIC. Dadurch wird verhindert, dass die verwaltete Instanzgruppe aktiv eine Instanzvorlage bereitstellt, die nicht explizit im Feld versions angegeben wurde.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation