Canary-Bereitstellungsstrategie verwenden

In diesem Dokument wird beschrieben, wie Sie eine Canary-Bereitstellungsstrategie konfigurieren und verwenden.

Was ist ein Canary-Deployment?

Ein Canary-Deployment ist ein schrittweises Roll-out einer Anwendung, bei dem der Traffic zwischen einer bereits bereitgestellten und einer neuen Version aufgeteilt wird. Anschließend wird er für eine Untergruppe von Nutzern eingeführt.

Unterstützte Zieltypen

Das Canary-Deployment in Cloud Deploy unterstützt alle Zieltypen, einschließlich der folgenden:

Canary funktioniert auch mit Multi-Zielen.

Vorteile einer Canary-Bereitstellungsstrategie

Mit einem Canary-Deployment können Sie Ihre Anwendung teilweise freigeben. Auf diese Weise können Sie dafür sorgen, dass die neue Version Ihrer Anwendung zuverlässig ist, bevor Sie sie an alle Nutzer senden.

Bei einer Bereitstellung in GKE oder GKE Enterprise würden Sie die neue Version Ihrer Anwendung beispielsweise für eine begrenzte Anzahl von Pods bereitstellen. Die alte Version wird weiterhin ausgeführt, allerdings wird ein größerer Teil des Traffics an die neuen Pods gesendet.

Wenn Sie die Bereitstellung in Cloud Run vornehmen, teilt Cloud Run selbst den Traffic gemäß den von Ihnen konfigurierten Prozentsatzen auf die alte und die neue Version auf.

Canary-Typen

Mit Cloud Deploy können Sie die folgenden Arten von Canary-Deployments konfigurieren:

  • Automatisiert

    Bei einem automatisierten Canary-Deployment konfigurieren Sie Cloud Deploy mit einer Reihe von Prozentsätzen, die eine progressive Bereitstellung ausdrücken. Cloud Deploy führt in Ihrem Namen zusätzliche Vorgänge aus, um den prozentualen Traffic zwischen der alten und der neuen Version aufzuteilen.

  • Benutzerdefiniert und automatisiert

    Für eine benutzerdefinierte automatisierte Canary-Version können Sie Folgendes bereitstellen:

    • Phasenname
    • Das Prozentsatzziel
    • Das Skaffold-Profil für die Phase
    • Ob ein Überprüfungsjob eingeschlossen werden soll oder nicht

    Sie müssen jedoch keine Informationen zum Traffic-Balancing angeben. Cloud Deploy erstellt die erforderlichen Ressourcen, wie hier beschrieben.

  • Benutzerdefiniert

    Mit einer benutzerdefinierten Canary-Version konfigurieren Sie jede Canary-Phase separat. Dazu gehören:

    • Phasenname
    • Das Prozentsatzziel
    • Das Skaffold-Profil für die Phase
    • Ob ein Überprüfungsjob eingeschlossen werden soll oder nicht

    Bei einer vollständig benutzerdefinierten Canary-Version müssen Sie außerdem die gesamte Traffic-Balancing-Konfiguration wie hier beschrieben bereitstellen.

Phasen eines Canary-Deployments

Wenn Sie einen Release für ein Canary-Deployment erstellen, wird das Roll-out mit einer Phase für jedes Canary-Inkrement erstellt, plus einer abschließenden stable-Phase für 100%.

Wenn Sie beispielsweise eine Canary-Version in den Schritten von 25%, 50 % und 75% konfigurieren, umfasst das Rollout die folgenden Phasen:

  • canary-25
  • canary-50
  • canary-75
  • stable

Weitere Informationen zu Roll-out-Phasen, Jobs und Jobausführungen finden Sie unter Roll-outs verwalten.

Was passiert bei einem automatisierten oder benutzerdefiniert automatisierten Canary-Test?

Cloud Deploy umfasst zur Unterstützung Ihres Canary-Deployments beim Rendern des Kubernetes-Manifests oder der Cloud Run-Dienstkonfiguration spezielle Verarbeitungsschritte:

GKE/GKE Enterprise (Netzwerk)

So führt Cloud Deploy ein Canary-Deployment in der netzwerkbasierten GKE und GKE Enterprise aus:

  1. Sie geben den Namen der Deployment-Ressource und der Dienstressource an.

  2. Cloud Deploy erstellt eine zusätzliche Bereitstellungsressource mit dem Namen Ihres aktuellen Deployments und -canary.

  3. Cloud Deploy ändert den Dienst so, dass die Auswahl so angepasst wird, dass die Pods im aktuellen Deployment und in den Canary-Pods ausgewählt werden.

    Cloud Deploy berechnet die Anzahl der für die Canary-Version zu verwendenden Pods anhand der hier beschriebenen Berechnung. Diese Berechnung unterscheidet sich je nachdem, ob Sie die Pod-Überdimensionierung aktivieren oder deaktivieren.

    Wenn wir zur stable-Phase übergehen, fügt Cloud Deploy die Labels hinzu, die zum Abgleich von Pods verwendet werden sollen, damit sie für nachfolgende Canary-Ausführungen verfügbar sind.

    Cloud Deploy erstellt ein Deployment, das den phasenspezifischen Prozentsatz der Pods enthält und aktualisiert ihn für jede Phase. Dazu wird die Anzahl der Pods als Prozentsatz der ursprünglichen Anzahl von Pods berechnet. Das kann zu einer ungenauen Aufteilung der Zugriffe führen. Wenn Sie eine genaue Traffic-Aufteilung benötigen, können Sie dies mithilfe der Gateway API erreichen.

    Außerdem werden Secrets und ConfigMaps ebenfalls kopiert und mit -canary umbenannt.

  4. Während der stable-Phase wird das -canary-Deployment auf null herunterskaliert und das ursprüngliche Deployment durch das neue ersetzt.

    Cloud Deploy ändert das ursprüngliche Deployment erst in der stable-Phase.

Cloud Deploy stellt Pods bereit, um den angeforderten Canary-Prozentsatz so genau wie möglich zu erreichen. Dies basiert auf der Anzahl der Pods, nicht auf dem Traffic zu den Pods. Wenn die Canary-Version auf Traffic basieren soll, müssen Sie die Gateway API verwenden.

Für das netzwerkbasierte GKE-Canary-Canary können Sie die Pod-Überdimensionierung aktivieren oder deaktivieren. In den folgenden Abschnitten wird beschrieben, wie Cloud Deploy die Anzahl der Pods berechnet, die für das Canary-Deployment in jeder Canary-Phase bereitgestellt werden sollen.

Pod-Bereitstellung mit aktivierter Überdimensionierung

Wenn Sie die Überbereitstellung (disablePodOverprovisioning: false) aktivieren, kann Cloud Deploy genügend zusätzliche Pods erstellen, um den gewünschten Canary-Prozentsatz auszuführen. Diese Anzahl basiert auf der Anzahl der Pods, die Ihre vorhandene Bereitstellung ausführen. Die folgende Formel zeigt, wie Cloud Deploy die Anzahl der Pods berechnet, die für das Canary-Deployment für jede Canary-Phase bereitgestellt werden sollen, wenn die Pod-Überbereitstellung aktiviert ist:

math.Ceil( percentage * ReplicaCountOfDeploymentOnCluster / (100-percentage))

Mit dieser Formel wird die aktuelle Anzahl der Replikate (die Anzahl der Pods, die Sie bereits vor dieser Canary-Version haben) mit dem Canary-Prozentsatz für die Phase multipliziert. Das Ergebnis wird durch (100 minus der Prozentsatz) dividiert.

Wenn Sie beispielsweise 4 Pods haben und die Canary-Phase 50 % beträgt, beträgt die Anzahl der Canary-Pods 4. (Das Ergebnis von 100-percentage wird als Prozentsatz verwendet: 100-50=50 und wird als .50 behandelt.)

Pod-Überbereitstellung ist das Standardverhalten.

Pod-Bereitstellung mit deaktivierter Überbereitstellung

Sie können die Überbereitstellung deaktivieren (disablePodOverprovisioning: true), damit Cloud Deploy die Anzahl der Replikate nicht erhöht.

Die folgende Formel zeigt, wie Cloud Deploy die Pod-Bereitstellung für das Canary-Deployment für jede Canary-Phase berechnet, wenn die Pod-Überbereitstellung deaktiviert ist:

math.Ceil( (ReplicaCountOfDeploymentOnCluster + ReplicaCountOfCanaryDeploymentOnCluster) * percentage)

In dieser Formel ist ReplicaCountOfCanaryDeploymentOnCluster nur vorhanden, wenn es bereits eine Canary-Phase gab. Wenn dies die erste Canary-Phase ist, gibt es kein ReplicaCountOfCanaryDeploymentOnCluster.

Wenn Sie mit vier Pods beginnen, wird diese Zahl mit dem Canary-Prozentsatz (z. B. 50 % oder .5) multipliziert, um 2 zu erhalten. Damit wird das ursprüngliche Deployment auf 2 herunterskaliert und es werden zwei neue Pods für das Canary-Deployment erstellt. Wenn dann eine Canary-Phase von 75% vorliegt, haben Sie 2 (ursprüngliches Deployment) +2 (erste Canary-Phase), *.75, um 3 Canary-Pods und 1-Pod abzurufen, die das ursprüngliche Deployment ausführen.

GKE/GKE Enterprise (Gateway)

So führt Cloud Deploy ein Canary-Deployment in GKE und GKE Enterprise mithilfe der Gateway API aus:

  1. Zusätzlich zu den Bereitstellungs- und Dienstreferenzen geben Sie eine HTTPRoute-Ressource mit einer backendRefs-Regel an, die auf den Dienst verweist.

  2. Cloud Deploy erstellt ein neues Deployment mit dem Namen des ursprünglichen Deployments plus -canary und einen neuen Dienst mit dem ursprünglichen Dienstnamen und -canary.

    Außerdem werden Secrets, ConfigMaps und horizontale Pod-Autoscalings kopiert und mit -canary umbenannt.

  3. Bei jeder Canary-Phase ändert Cloud Deploy die HTTP-Route so, dass die Gewichtung zwischen den Pods des ursprünglichen Deployments und den Pods des Canary-Deployments basierend auf dem Prozentsatz für diese Phase aktualisiert wird.

    Da es zu einer Verzögerung bei der Weitergabe von Änderungen an HTTPRoute-Ressourcen kommen kann, können Sie das Attribut routeUpdateWaitTime in Ihre Konfiguration aufnehmen. Das System wartet dann eine bestimmte Zeit auf diese Weiterleitung.

  4. Während der stable-Phase wird das -canary-Deployment auf null herunterskaliert und das ursprüngliche Deployment wird aktualisiert, um das Deployment des neuen Release zu verwenden.

    Außerdem wird HTTPRoute jetzt auf das von Ihnen angegebene Original zurückgesetzt.

    Cloud Deploy ändert das ursprüngliche Deployment oder den ursprünglichen Dienst erst in der stable-Phase.

Cloud Run

So führt Cloud Deploy ein Canary-Deployment für Cloud Run aus:

  • Geben Sie für ein Canary-Deployment in Cloud Run in der Dienst-YAML-Datei keine traffic-Stanza an.

  • Beim Erstellen eines neuen Roll-outs für Canary teilt Cloud Deploy den Traffic zwischen der vorherigen erfolgreich von Cloud Deploy bereitgestellten Version und einer neuen Version auf.

Wenn Sie sich die Unterschiede zwischen den Phasen eines Canary-Deployments ansehen möchten, können Sie sich die Änderungen am phasenbezogenen gerenderten Manifest ansehen, das im Release-Inspector verfügbar ist. Das ist auch schon vor dem Roll-out möglich. Bei einer parallelen Bereitstellung können Sie auch das gerenderte Manifest der einzelnen untergeordneten Elemente prüfen.

Canary-Deployment konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie die Bereitstellungspipeline und Ziele für ein Canary-Deployment konfigurieren.

Die folgende Anleitung bezieht sich nur auf die Canary-Konfiguration. Das Dokument Anwendung bereitstellen enthält die allgemeinen Anleitungen zum Konfigurieren und Ausführen der Bereitstellungspipeline.

Prüfen Sie, ob Sie die erforderlichen Berechtigungen haben

Zusätzlich zu anderen Identity and Access Management-Berechtigungen, die Sie für die Verwendung von Cloud Deploy benötigen, benötigen Sie die folgenden Berechtigungen, um zusätzliche Aktionen auszuführen, die für eine Canary-Bereitstellung möglicherweise erforderlich sind:

  • clouddeploy.rollouts.advance
  • clouddeploy.rollouts.ignoreJob
  • clouddeploy.rollouts.cancel
  • clouddeploy.rollouts.retryJob
  • clouddeploy.jobRuns.get
  • clouddeploy.jobRuns.list
  • clouddeploy.jobRuns.terminate

Weitere Informationen zu den verfügbaren Rollen, die diese Berechtigungen enthalten, finden Sie unter IAM-Rollen und -Berechtigungen.

skaffold.yaml vorbereiten

Wie bei einer Standardbereitstellung benötigt Ihre Canary-Version eine skaffold.yaml-Datei, in der definiert ist, wie Manifeste und Dienstdefinitionen gerendert und bereitgestellt werden.

Der skaffold.yaml, den Sie für ein Canary-Deployment erstellen, hat keine besonderen Anforderungen, die über die Voraussetzungen für die Standardbereitstellung hinausgehen.

Manifest oder Dienstdefinition vorbereiten

Wie bei einer Standardbereitstellung benötigt die Canary-Version ein Kubernetes-Manifest oder eine Cloud Run-Dienstdefinition.

GKE und GKE Enterprise

Für das Canary-Deployment muss Ihr Manifest Folgendes enthalten:

  • Ein Deployment und einen Dienst.

  • Der Dienst muss einen app-Selektor definieren und die Pods des angegebenen Deployments auswählen.

  • Wenn Sie eine Gateway API-basierte Canary-Version verwenden, muss das Manifest auch eine HTTPRoute haben.

Cloud Run

Für Canary in Cloud Run reicht die normale Cloud Run-Dienstdefinitionsdatei aus, jedoch ohne eine traffic-Stanza. Cloud Deploy verwaltet die Aufteilung des Traffics zwischen der letzten erfolgreichen Überarbeitung und der neuen Überarbeitung.

Automatisierte Canary-Variante konfigurieren

Die folgende Anleitung gilt für dienstbasierte Netzwerkziele von Cloud Run, GKE und GKE Enterprise. Wenn Sie die Kubernetes Gateway API mit GKE oder GKE Enterprise verwenden, lesen Sie diese Dokumentation.

Sie konfigurieren die automatisierte Canary-Version in der Definition der Bereitstellungspipeline:

GKE und GKE Enterprise

Fügen Sie in der Pipelinephase das Attribut strategy so ein:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

In dieser Konfiguration...

  • SERVICE_NAME ist der Name des Kubernetes-Dienstes, der im Manifest definiert ist.

  • DEPLOYMENT_NAME ist der Name Ihres Kubernetes-Deployments, der im Manifest definiert ist.

  • PERCENTAGES ist eine durch Kommas getrennte Liste von Prozentwerten für die Canary-Inkremente, z. B. [5, 25, 50].

    Außerdem ist 100 hier nicht enthalten, da die Bereitstellung zu 100% in der Canary-Version angenommen wird und in der stable-Phase durchgeführt wird.

  • Sie können die Bereitstellungsprüfung (verify: true) aktivieren. In diesem Fall wird für jede Phase ein verify-Job aktiviert.

Cloud Run

Fügen Sie in der Pipelinephase das Attribut strategy so ein:

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false

In dieser Konfiguration...

  • PERCENTAGES ist eine durch Kommas getrennte Liste von Prozentwerten für die Canary-Inkremente, z. B. [25, 50, 75]. 100 ist dabei nicht enthalten, da die Bereitstellung zu 100% in der Canary-Version angenommen und in der stable-Phase ausgeführt wird.
  • Sie können die Bereitstellungsprüfung (verify: true) aktivieren. In diesem Fall wird jeder Canary-Phase ein verify-Job hinzugefügt.

Benutzerdefinierte Canary-Version konfigurieren

Sie können die Canary-Version manuell konfigurieren, anstatt sich vollständig auf die Automatisierung von Cloud Deploy zu verlassen. Bei der benutzerdefinierten Canary-Konfiguration geben Sie in der Definition der Bereitstellungspipeline Folgendes an:

  • Namen der Einführungsphasen

    Bei einer vollständig automatisierten Canary-Version benennt Cloud Deploy die Phasen automatisch (z. B. canary-25, canary-75, stable). Bei einer benutzerdefinierten Canary-Phase können Sie jeder Phase jedoch einen beliebigen Namen geben, solange dieser unter allen Phasen dieser Canary-Phase eindeutig ist und die Einschränkungen für Ressourcennamen berücksichtigt werden. Der Name der letzten Phase (100%) muss jedoch stable lauten.

  • Prozentziele für jede Phase

    Geben Sie die Prozentsätze pro Phase separat an.

  • Skaffold-Profile für die Phase

    Sie können für jede Phase ein separates Skaffold-Profil, dasselbe Profil oder eine beliebige Kombination verwenden. Jedes Profil kann ein anderes Kubernetes-Manifest oder eine andere Cloud Run-Dienstdefinition verwenden. Sie können auch mehr als ein Profil für eine bestimmte Phase verwenden. Cloud Deploy kombiniert sie.

  • Ob für die Phase ein Verifizierungsjob vorhanden ist

    Wenn Sie die Bestätigung aktivieren, müssen Sie auch Ihre skaffold.yaml für die Bestätigung configure.

Für benutzerdefinierte Canary-Tests werden alle Zieltypen unterstützt.

Benutzerdefinierte Canary-Konfigurationselemente

Die folgende YAML-Datei zeigt die Konfiguration für die Phasen des vollständigen benutzerdefinierten Canary-Deployments:

strategy:
  canary:
    # Custom configuration for each canary phase
    ​customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false

In dieser YAML-Datei

  • PHASE1_NAME

    Ist der Name der Phase. Jeder Phasenname muss eindeutig sein.

  • [ "PROFILE_NAME" ]

    Der Name des Profils, das für die Phase verwendet werden soll. Sie können für jede Phase das gleiche Profil, für jede Phase ein anderes Profil oder eine beliebige Kombination verwenden. Außerdem können Sie mehrere Profile angeben. Cloud Deploy verwendet alle von Ihnen angegebenen Profile sowie das Profil oder Manifest, das von der Gesamtphase verwendet wird.

  • PERCENTAGE1

    Gibt den Prozentsatz an, der für die erste Phase bereitgestellt werden soll. Jede Phase muss einen eindeutigen Prozentsatzwert haben und dieser muss ein ganzer Prozentsatz sein (nicht beispielsweise 10.5). Die Phasen müssen in aufsteigender Reihenfolge angegeben werden.

  • verify: true|false

    Gibt an, ob Cloud Deploy einen Prüfjob für die Phase einschließen soll. Beachten Sie, dass Skaffold für jede Phase, in der die Überprüfung verwendet werden soll, dasselbe Profil für die Verifizierung verwendet, das für das Rendering und die Bereitstellung in dieser Phase angegeben ist.

  • stable

    Die letzte Phase muss stable heißen.

Der Prozentsatz für die letzte Phase muss 100 sein. Die Phasen werden in der Reihenfolge ausgeführt, in der Sie sie in dieser ​customCanaryDeployment-Stanza konfigurieren. Wenn die Prozentwerte jedoch nicht aufsteigend sind, schlägt der Befehl zum Registrieren der Bereitstellungspipeline mit einem Fehler fehl.

Die Konfiguration für eine benutzerdefinierte Canary-Version enthält keine runtimeConfig-Stanza. Das Hinzufügen von runtimeConfig gilt als benutzerdefinierte automatisierte Canary-Version.

Benutzerdefinierte automatisierte Canary-Version konfigurieren

Eine benutzerdefinierte automatisierte Canary-Version ähnelt einer benutzerdefinierten Canary-Version, da Sie die separaten Canary-Phasen mit benutzerdefinierten Phasennamen, Prozentwerten und Skaffold-Profilen angeben und Jobs überprüfen. Bei einer benutzerdefinierten Canary-Version stellen Sie jedoch nicht die Konfigurationen bereit, die die Trafficaufteilung definieren. Cloud Deploy erledigt das für Sie. Sie stellen aber weiterhin die Skaffold-Profile bereit, die für jede Phase verwendet werden sollen.

Zum Konfigurieren einer benutzerdefinierten automatisierten Canary-Version müssen Sie eine runtimeConfig-Stanza, wie hier gezeigt, und die customCanaryDeployment-Stanza, wie hier gezeigt, einschließen.

Canary-Deployment mit Service Mesh der Kubernetes Gateway API konfigurieren

Obwohl Sie mit einem Canary-Deployment von Cloud Deploy Ihre Anwendung in einem dienstbasierten Kubernetes-Netzwerk bereitstellen können, können Sie alternativ das Service Mesh der Gateway API von Kubernetes verwenden. In diesem Abschnitt wird die Vorgehensweise beschrieben.

Sie können die Gateway API mit Looker oder einer beliebigen unterstützten Implementierung verwenden.

  1. Richten Sie Ihre Gateway API-Ressourcen ein:

    Dies sind nur Beispiele.

  2. Fügen Sie in Ihrem Kubernetes-Manifest, das beim Erstellen des Release für Cloud Deploy bereitgestellt wurde, Folgendes ein:

    • Ein HTTPRoute, das auf Ihre Gateway-Ressource verweist

    • Eine Bereitstellung

    • Ein Dienst

  3. Konfigurieren Sie die Bereitstellungspipeline und das Ziel für das Canary-Deployment:

    • Die Konfiguration für das Ziel ist dieselbe wie für alle anderen Ziele.

    • Die Konfiguration der Bereitstellungspipeline in der Sequenz für das jeweilige Ziel enthält die Stanza gatewayServiceMesh, um auf die HTTPRoute-Konfiguration der Kubernetes Gateway API sowie auf Ihr Deployment und Ihren Dienst zu verweisen.

      strategy:
 canary:
   runtimeConfig:
     kubernetes:
       gatewayServiceMesh:
         httpRoute: "ROUTE"
         service: "SERVICE"
         deployment: "DEPLOYMENT"
         routeUpdateWaitTime: "WAIT_TIME"
   canaryDeployment:
     percentages:
     - 50

      Wobei:

      • ROUTE ist die httpRoute-Konfiguration, die das gewünschte Routingverhalten definiert.

      • SERVICE ist Ihre Dienstkonfiguration, die Cloud Deploy für Canary-Deployments in GKE und GKE Enterprise benötigt.

      • DEPLOYMENT ist Ihre Deployment-Konfiguration, die Cloud Deploy für Canary-Deployments in GKE und GKE Enterprise benötigt.

      • WAIT_TIME ist die Zeit, die Cloud Deploy wartet, bis Änderungen an der Ressource HTTPRoute übernommen wurden, um abgebrochene Anfragen zu vermeiden. Beispiel: routeUpdateWaitTime: 60s.

        Wenn Sie eine Canary-Version mit der Gateway API ohne Istio ausführen und die Gateway API mit einem Google Cloud-Load-Balancer verbunden ist, geht beim Herunterskalieren der Canary-Instanz möglicherweise ein kleiner Teil des Traffics verloren. Sie können diese Einstellung konfigurieren, wenn Sie dieses Verhalten beobachten.

Parallele Bereitstellung mit einer Canary-Bereitstellungsstrategie verwenden

Sie können ein Canary-Deployment mit einem parallelen Deployment ausführen. Das bedeutet, dass das Ziel, für das Sie die Bereitstellung schrittweise vornehmen, zwei oder mehr untergeordnete Ziele umfassen kann. Beispielsweise können Sie Bereitstellungen gleichzeitig schrittweise in Clustern in separaten Regionen vornehmen.

Worin unterscheidet sich eine parallele Canary-Version von einer Canary-Version mit einem einzelnen Ziel?

  • Wie beim Canary-Deployment mit einem einzelnen Ziel benötigen Sie beim Bereitstellen in GKE-Zielen eine Kubernetes-Deployment-Konfiguration und eine Kubernetes-Dienstkonfiguration in Ihrem Manifest.

  • Wie beim Canary-Deployment mit einem einzelnen Ziel muss die Konfiguration der Bereitstellungspipeline in der Phasendefinition für die entsprechende Phase die Stanza strategy.canary enthalten.

  • Außerdem müssen Sie ein Multi-Ziel konfigurieren und die untergeordneten Ziele konfigurieren, auf die dieses Multi-Ziel verweist.

  • Wenn Sie einen Release erstellen, werden ein Controller-Roll-out und die untergeordneten Roll-outs erstellt.

    Beide Roll-out-Typen – Controller und untergeordnete Roll-outs – haben separate Phasen für alle konfigurierten Canary-Prozentsätze und eine stable-Phase für die Canary-100%.

  • Sie können ein untergeordnetes Roll-out nicht fortfahren.

    Sie können nur Controller-Roll-outs fortsetzen. Wenn Sie das Controller-Roll-out in der nächsten Phase fortsetzen, werden auch die untergeordneten Roll-outs von Cloud Deploy vorangetrieben.

  • Fehlgeschlagene Jobs können im Controller-Roll-out nicht wiederholt werden.

    Sie können einen Job nur in untergeordneten Roll-outs wiederholen.

  • Sie können fehlgeschlagene Jobs im Controller-Roll-out nicht ignore.

    Fehlgeschlagene Jobs können nur in untergeordneten Roll-outs ignoriert werden.

  • Sie können ein Controller-Roll-out abbrechen, aber keine untergeordneten Roll-outs abbrechen.

  • Sie können Jobausführungen nur unter einem untergeordneten Roll-out beenden, nicht unter einem Controller-Roll-out.

Vorgehensweise, wenn ein paralleles Roll-out in Canary fehlschlägt

Wenn ein untergeordnetes Roll-out fehlschlägt, kann das Controller-Roll-out in verschiedene Status wechseln, je nachdem, was mit den untergeordneten Roll-outs geschieht:

  • Wenn ein oder mehrere untergeordnete Roll-outs fehlschlagen, aber mindestens ein untergeordnetes Roll-out immer noch den Status IN_PROGRESS hat, bleibt das Controller-Roll-out IN_PROGRESS.

  • Wenn ein oder mehrere untergeordnete Roll-outs fehlschlagen, aber mindestens ein untergeordnetes Roll-out erfolgreich ist, lautet das Controller-Roll-out HALTED, wenn es nach der aktuellen Phase weitere Phasen gibt.

    Wenn es sich um die Phase „stable“ handelt, ist das Controller-Roll-out FAILED.

    Mit HALTED können Sie fehlgeschlagene Jobs innerhalb des fehlgeschlagenen untergeordneten Roll-outs entweder ignore, wiederholen oder das Controller-Roll-out abbrechen und weitere Aktionen für die untergeordneten Roll-outs verhindern.

  • Wenn sich das Controller-Rollout aufgrund eines fehlgeschlagenen untergeordneten Roll-outs im Status HALTED befindet und Sie den fehlgeschlagenen Job im untergeordneten Rollout ignorieren, wird das Controller-Rollout auf den Status IN_PROGRESS zurückgesetzt.

Konfigurierte Canary-Version ausführen

So führen Sie das Canary-Deployment aus:

  1. Registrieren der konfigurierten Bereitstellungspipeline und ‐ziele

    gcloud deploy apply --file=PIPELINE

    Die Bereitstellungspipeline enthält die automatisierte oder benutzerdefinierte Canary-Konfiguration für die ausgewählte Laufzeit.

    Bei diesem Befehl wird davon ausgegangen, dass Ihre Ziele in derselben Datei definiert oder anderweitig bereits registriert sind. Falls nicht, müssen Sie auch Ihre Ziele registrieren.

  2. Release erstellen:

    gcloud deploy releases create RELEASE_NAME \
                              --delivery-pipeline=PIPELINE_NAME \
                              --region=REGION

    Die durch PIPELINE_NAME angegebene Bereitstellungspipeline enthält die in diesem Dokument beschriebene automatisierte oder benutzerdefinierte Canary-Konfiguration.

  3. Bringen Sie die Canary-Version voran:

    gcloud-CLI 

    gcloud deploy rollouts advance ROLLOUT_NAME \
                            --release=RELEASE_NAME \
                            --delivery-pipeline=PIPELINE_NAME \
                            --region=REGION

    Wobei:

    ROLLOUT_NAME ist der Name des aktuellen Roll-outs, mit dem Sie in der nächsten Phase fortfahren.

    RELEASE_NAME ist der Name des Release, zu dem dieses Roll-out gehört.

    PIPELINE_NAME ist der Name der Bereitstellungspipeline, die Sie zum Verwalten der Bereitstellung dieses Release verwenden.

    REGION ist der Name der Region, in der der Release erstellt wurde, z. B. us-central1. Das ist ein Pflichtfeld.

    Weitere Informationen zum Befehl gcloud deploy rollouts advance finden Sie in der Google Cloud SDK-Referenz.

    Google Cloud Console

    1. Öffnen Sie die Seite der Lieferpipelines.

    2. Klicken Sie auf Ihre Pipeline, die in der Liste der Lieferpipelines angezeigt wird.

      Die Detailseite der Bereitstellungspipeline zeigt eine grafische Darstellung des Fortschritts der Bereitstellungspipeline.

    3. Klicken Sie auf dem Tab Roll-outs unter Details zur Bereitstellungspipeline auf den Namen Ihres Roll-outs.

      Die Seite mit den Roll-out-Details für dieses Roll-out wird angezeigt.

      Roll-out-Details in der Google Cloud Console

      Beachten Sie, dass das Roll-out in diesem Beispiel eine canary-50-Phase und eine stable-Phase hat. Ihr Rollout kann mehrere oder verschiedene Phasen umfassen.

    4. Klicken Sie auf Roll-out fortsetzen.

      Das Roll-out wird in der nächsten Phase fortgesetzt.

Übersprungene Phasen

Wenn Sie eine Canary-Phase bereitstellen und Ihre Anwendung noch nicht in dieser Laufzeit bereitgestellt wurde, überspringt Cloud Deploy die Canary-Phase und führt die stabile Phase aus. Informationen zu den Gründen finden Sie unter Phasen zum ersten Mal überspringen.

Nächste Schritte