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 Rollout einer Anwendung, das den Traffic zwischen einer bereits bereitgestellten und einer neuen Version aufteilt und vor der vollständigen Einführung für eine Untergruppe von Nutzern bereitstellt.

Unterstützte Zieltypen

Die Canary-Bereitstellung in Cloud Deploy unterstützt alle Zieltypen, darunter:

Canary funktioniert auch mit mehreren Zielen.

Vorteile einer Canary-Bereitstellungsstrategie

Bei einem Canary-Deployment haben Sie die Möglichkeit, Ihre Anwendung teilweise freizugeben. Auf diese Weise können Sie dafür sorgen, dass die neue Version Ihrer Anwendung zuverlässig ist, bevor Sie sie allen Nutzern zur Verfügung stellen.

Wenn Sie beispielsweise eine Bereitstellung in GKE oder GKE Enterprise vornehmen, stellen Sie die neue Version Ihrer Anwendung für eine begrenzte Anzahl von Pods bereit. Die alte Version würde weiterhin ausgeführt werden, allerdings wird ein größerer Anteil des Traffics an die neuen Pods gesendet.

Bei der Bereitstellung in Cloud Run teilt Cloud Run selbst den Traffic zwischen der alten und der neuen Version auf und zwar anhand der von Ihnen konfigurierten Prozentsätze.

Canary-Typen

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

  • Automatisiert

    Bei einer automatisierten Canary-Bereitstellung konfigurieren Sie Cloud Deploy mit einer Reihe von Prozentsätzen, die eine progressive Bereitstellung zum Ausdruck bringen. Cloud Deploy führt in Ihrem Namen zusätzliche Vorgänge aus, um die Trafficprozentsätze zwischen der alten und der neuen Version aufzuteilen.

  • Benutzerdefiniert – automatisiert

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

    • Der Phasenname
    • Das prozentuale Ziel
    • Das für die Phase zu verwendende Skaffold-Profil
    • Ob ein Prüfjob eingefügt werden soll oder nicht

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

  • Benutzerdefiniert

    Bei einem benutzerdefinierten Canary konfigurieren Sie jede Canary-Phase separat. Dazu gehören:

    • Der Phasenname
    • Das prozentuale Ziel
    • Das für die Phase zu verwendende Skaffold-Profil
    • Ob ein Prüfjob eingefügt werden soll oder nicht

    Für eine vollständig benutzerdefinierte Canary-Version müssen Sie außerdem die gesamte Traffic-Balancing-Konfiguration bereitstellen, wie hier beschrieben.

Phasen einer Canary-Bereitstellung

Wenn Sie einen Release für ein Canary-Deployment erstellen, wird das Roll-out mit einer Phase für jedes Canary-Inkrement sowie der letzten stable-Phase für 100 % erstellt.

Wenn Sie beispielsweise ein Canary in 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 während eines automatisierten oder benutzerdefinierten automatisierten Canary-Tests?

Zur Unterstützung Ihrer Canary-Bereitstellung umfasst Cloud Deploy spezielle Verarbeitungsschritte beim Rendern des Kubernetes-Manifests oder der Cloud Run-Dienstkonfiguration:

GKE/Enterprise

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

  1. Sie geben den Namen der Bereitstellungsressource und der Dienstressource an.

  2. Cloud Deploy erstellt eine zusätzliche Deployment-Ressource mit dem Namen Ihres aktuellen Deployments plus -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 Pods, die für die Canary-Version zu verwenden sind, auf der Grundlage der hier beschriebenen Berechnung. Diese Berechnung unterscheidet sich je nachdem, ob Sie die Pod-Überbereitstellung aktivieren oder deaktivieren.

    Wenn wir die stable-Phase überspringen, fügt Cloud Deploy die Labels hinzu, die zum Abgleichen 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 von Pods enthält, und aktualisiert es für jede Phase. Dazu wird die Anzahl der Pods als Prozentsatz der ursprünglichen Anzahl von Pods berechnet. Dies kann zu einer ungenauen Aufteilung der Zugriffe führen. Wenn Sie eine exakte Aufteilung des Traffics 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 Deployment 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. Diese 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 die netzwerkbasierte GKE-Canary-Version können Sie die Pod-Überbereitstellung 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.

Pod-Bereitstellung mit aktivierter Überbereitstellung

Wenn Sie die Überbereitstellung aktivieren (disablePodOverprovisioning: false), kann Cloud Deploy genügend zusätzliche Pods erstellen, um den gewünschten Canary-Prozentsatz auszuführen. Dieser basiert auf der Anzahl der Pods, die Ihr vorhandenes Deployment 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-Überdimensionierung aktiviert ist:

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

Mit dieser Formel wird die aktuelle Anzahl der Replikate (die Anzahl der Pods, die Sie vor diesem Canary-Test vorhanden haben) mit dem Canary-Prozentsatz für die Phase multipliziert. Das Ergebnis wird dann durch (100 minus den Prozentsatz) geteilt.

Wenn Sie beispielsweise vier Pods aleady 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, behandelt als .50.

Die Pod-Überdimensionierung ist das Standardverhalten.

Pod-Bereitstellung mit deaktivierter Überbereitstellung

Sie können die Überbereitstellung deaktivieren (disablePodOverprovisioning: true), damit Cloud Deploy die Anzahl Ihrer 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-Überdimensionierung deaktiviert ist:

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

In dieser Formel ist ReplicaCountOfCanaryDeploymentOnCluster nur vorhanden, wenn es bereits eine Canary-Phase gibt. In der ersten Canary-Phase ist ReplicaCountOfCanaryDeploymentOnCluster nicht vorhanden.

Wenn Sie mit vier Pods beginnen, wird diese Zahl mit dem Canary-Prozentsatz (z. B. 50 % oder .5) multipliziert, um 2 zu erhalten. Das ursprüngliche Deployment wird also jetzt auf 2 skaliert und zwei neue Pods für das Canary-Deployment erstellt. Wenn Sie dann eine Canary-Phase von 75% haben, haben Sie 2 (ursprüngliche Bereitstellung) +2 (erste Canary-Phase), *.75, um 3 Canary-Pods und den 1-Pod zu erhalten, auf dem das ursprüngliche Deployment ausgeführt wird.

Gateway GKE/Enterprise

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

  1. Zusätzlich zu den Referenzen zum Deployment und zum Dienst 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 einem neuen Dienst mit dem ursprünglichen Dienstnamen plus -canary.

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

  3. Cloud Deploy ändert für jede Canary-Phase die HTTP-Route, um die Gewichtung zwischen den ursprünglichen Deployment-Pods und den Canary-Deployment-Pods basierend auf dem Prozentsatz für diese Phase zu aktualisieren.

    Da sich die Übertragung von Änderungen an HTTPRoute-Ressourcen verzögern kann, können Sie das Attribut routeUpdateWaitTime in Ihre Konfiguration aufnehmen, damit das System eine bestimmte Zeit auf diese Weitergabe wartet.

  4. Während der Phase stable 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 die HTTPRoute nun 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 keine traffic-Stanza in der YAML-Datei Ihres Dienstes 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 die Unterschiede zwischen den Phasen einer Canary-Bereitstellung sehen möchten, können Sie sich die Änderungen im gerenderten Manifest pro Phase ansehen, das im Release Inspector verfügbar ist. Das ist bereits vor Beginn des Roll-outs möglich. Wenn Sie die parallele Bereitstellung verwenden, können Sie auch das gerenderte Manifest jedes untergeordneten Elements prüfen.

Canary-Deployment konfigurieren

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

Die hier aufgeführten Anleitungen beziehen sich nur auf die Canary-Konfiguration. Das Dokument Anwendung bereitstellen enthält die allgemeinen Anweisungen zum Konfigurieren und Ausführen der Bereitstellungspipeline.

Prüfen Sie, ob Sie die erforderlichen Berechtigungen haben

Zusätzlich zu den anderen Berechtigungen für Identity and Access Management, die Sie für die Verwendung von Cloud Deploy benötigen, benötigen Sie die folgenden Berechtigungen, um weitere Aktionen auszuführen, die möglicherweise für eine Canary-Bereitstellung 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 dazu, welche verfügbaren Rollen diese Berechtigungen enthalten, finden Sie unter IAM-Rollen und -Berechtigungen.

skaffold.yaml vorbereiten

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

Für die skaffold.yaml, die Sie für ein Canary-Deployment erstellen, gelten außer den Voraussetzungen für die Standardbereitstellung keine besonderen Anforderungen.

Manifest- oder Dienstdefinition vorbereiten

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

GKE und GKE Enterprise

Für Canary muss das 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 enthalten.

Cloud Run

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

Automatisiertes Canary konfigurieren

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

Die automatisierte Canary-Version wird in der Definition der Bereitstellungspipeline konfiguriert:

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 in Ihrem Manifest definiert ist.

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

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

    Außerdem gilt dies nicht für 100, da in der Canary-Version eine Bereitstellung zu 100% angenommen wird und dies in der stable-Phase stattfindet.

  • Sie können die Bereitstellungsprüfung (verify: true) aktivieren. In diesem Fall wird in jeder 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, die die Canary-Inkremente darstellen, z. B. [25, 50, 75]. Beachten Sie, dass 100 hier nicht enthalten ist, da in der Canary-Version eine Bereitstellung zu 100% angenommen wird und dies in der stable-Phase stattfindet.
  • 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 in vollem Umfang auf die Automatisierung von Cloud Deploy zu verlassen. Bei der benutzerdefinierten Canary-Konfiguration geben Sie in der Definition der Bereitstellungspipeline Folgendes an:

  • Namen der Roll-out-Phasen

    In einer vollständig automatisierten Canary-Version benennt Cloud Deploy die Phasen für Sie (z. B. canary-25, canary-75, stable). Bei einem benutzerdefinierten Canary-Test können Sie jedoch jeder Phase einen beliebigen Namen geben, solange dieser in allen Phasen dieser Canary-Phase nur einmal vorkommt und die Einschränkungen für Ressourcennamen berücksichtigt. Der letzte Phasenname (100%) muss jedoch stable lauten.

  • Prozentziele für jede Phase

    Geben Sie die Prozentsätze separat pro Phase 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 es für die Phase einen Verifizierungsjob gibt

    Wenn Sie die Überprüfung aktivieren, müssen Sie auch skaffold.yaml für die Überprüfung configure.

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

Benutzerdefinierte Canary-Konfigurationselemente

Die folgende YAML-Datei zeigt die Konfiguration für die Phasen des vollständig 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

    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 dasselbe Profil oder für jede Phase ein anderes Profil oder eine beliebige Kombination verwenden. Sie können auch mehr als ein Profil angeben. Cloud Deploy verwendet alle von Ihnen angegebenen Profile plus das Profil oder Manifest, das von der gesamten Phase verwendet wird.

  • PERCENTAGE1

    Entspricht dem Prozentsatz, der in der ersten Phase bereitgestellt werden soll. Jede Phase muss einen eindeutigen Prozentwert haben und dieser Wert muss ein ganzer Prozentsatz sein (z. B. nicht 10.5) und die Phasen müssen in aufsteigender Reihenfolge vorliegen.

  • verify: true|false

    Gibt Cloud Deploy an, ob ein Prüfjob für die Phase eingefügt werden soll. Skaffold verwendet für jede Phase, in der die Überprüfung verwendet werden soll, das gleiche Profil, das für das Rendering und die Bereitstellung angegeben ist.

  • stable

    Die letzte Phase muss den Namen stable haben.

Der Prozentsatz für die letzte Phase muss 100 sein. Die Phasen werden in der Reihenfolge ausgeführt, in der sie in dieser ​customCanaryDeployment-Stanza konfiguriert werden. Wenn die Prozentwerte jedoch nicht in aufsteigender Reihenfolge 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 wird als benutzerdefiniertes automatisiertes Canary betrachtet.

Benutzerdefinierte automatisierte Canary-Version konfigurieren

Ein benutzerdefiniertes automatisiertes Canary ähnelt einem benutzerdefinierten Canary, da Sie die separaten Canary-Phasen mit benutzerdefinierten Phasennamen, Prozentwerten, Skaffold-Profilen und Überprüfungsjobs angeben. Bei einer benutzerdefinierten Canary-Version stellen Sie jedoch nicht die Konfigurationen bereit, die die Traffic-Aufteilung definieren. Cloud Deploy erledigt das für Sie, aber Sie stellen trotzdem die Skaffold-Profile für die einzelnen Phasen bereit.

Zum Konfigurieren einer benutzerdefinierten automatisierten Canary-Version fügen Sie eine runtimeConfig-Stanza wie hier gezeigt und die customCanaryDeployment-Stanza ein, wie hier gezeigt.

Canary-Deployment mit dem Service Mesh der Kubernetes Gateway API konfigurieren

Obwohl Sie ein Canary-Deployment von Cloud Deploy zum Bereitstellen Ihrer Anwendung in einem dienstbasierten Kubernetes-Netzwerk verwenden können, können Sie das Service Mesh der Gateway API von Kubernetes verwenden. In diesem Abschnitt wird dies beschrieben.

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

  1. Richten Sie die Gateway API-Ressourcen ein:

    Hierbei handelt es sich lediglich um Beispiele.

  2. Das Kubernetes-Manifest, das Cloud Deploy beim Erstellen des Release zur Verfügung gestellt wurde, enthält Folgendes:

    • 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 Abfolge für das jeweilige Ziel enthält eine gatewayServiceMesh-Stanza, die auf die HTTPRoute-Konfiguration der Kubernetes Gateway API verweist, sowie Ihr Deployment und Ihren Dienst.

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

      Wobei:

      • ROUTE ist Ihre 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 benötigt, um auf die vollständige Weitergabe von Änderungen an der Ressource HTTPRoute zu warten, um abgebrochene Anfragen zu vermeiden. Beispiel: routeUpdateWaitTime: 60s.

        Wenn Sie Canary 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 einer parallelen Bereitstellung ausführen. Das bedeutet, dass das Ziel, für das Sie die Bereitstellung schrittweise vornehmen, zwei oder mehr untergeordnete Ziele umfassen kann. Sie können beispielsweise schrittweise in Clustern in separaten Regionen bereitstellen.

Wie unterscheidet sich ein paralleler Canary von einem Canary mit einem einzelnen Ziel?

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

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

  • Außerdem müssen Sie ein mehrere Ziele konfigurieren und die untergeordneten Ziele konfigurieren, auf die diese Ziele verweisen.

  • Wenn Sie einen Release erstellen, werden ein Controller-Rollout und die untergeordneten Rollouts erstellt.

    Beide Roll-out-Typen – Controller und untergeordnete Ebene – 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 mit dem Controller-Roll-out in die nächste Phase übergehen, werden auch die untergeordneten Rollouts von Cloud Deploy fortgeführt.

  • Sie können fehlgeschlagene Jobs im Controller-Rollout nicht wiederholen.

    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, untergeordnete Roll-outs jedoch nicht 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 der Canary-Version fehlschlägt

Wenn ein untergeordnetes Roll-out fehlschlägt, kann das Controller-Roll-out in einen anderen 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 IN_PROGRESS ist, 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-Rollout HALTED, wenn nach dem aktuellen Roll-out weitere Phasen folgen.

    Wenn dies die stable-Phase ist, ist das Controller-Roll-out FAILED.

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

  • Wenn das Controller-Rollout aufgrund eines fehlgeschlagenen untergeordneten Rollouts den Status HALTED hat und Sie den fehlgeschlagenen Job im untergeordneten Rollout ignorieren, wird das Controller-Rollout in den Status IN_PROGRESS zurückgesetzt.

Konfigurierte Canary-Version ausführen

So führen Sie das Canary-Deployment aus:

  1. Registrieren Sie die konfigurierte 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 sind oder anderweitig bereits registriert wurden. Wenn nicht, registrieren Sie auch Ihre Ziele.

  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. Canary-Version fortsetzen:

    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 die nächste Phase übergehen.

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

    PIPELINE_NAME ist der Name der Bereitstellungspipeline, mit der Sie die Bereitstellung dieses Release verwalten.

    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.

      Auf der Detailseite der Bereitstellungspipeline wird der Fortschritt der Bereitstellungspipeline grafisch dargestellt.

    3. Klicken Sie auf dem Tab Rollouts unter Details zur Bereitstellungspipeline auf den Namen des 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- und eine stable-Phase hat. Ihr Rollout kann mehr Phasen oder verschiedene Phasen umfassen.

    4. Klicken Sie auf Einführung fortsetzen.

      Die Einführung geht in die nächste Phase über.

Übersprungene Phasen

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

Nächste Schritte