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, die Traffic zwischen einer bereits bereitgestellten Version und einer neuen Version, für eine Untergruppe von Nutzern verfügbar, bevor sie vollständig eingeführt werden.

Unterstützte Zieltypen

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

• Google Kubernetes Engine
• Cloud Run (nur Dienste, nicht jobs.)
• GKE Enterprise

Canary funktioniert auch mit mehrere Ziele.

Vorteile einer Canary-Bereitstellungsstrategie

Bei einem Canary-Deployment haben Sie die Möglichkeit, Ihre Anwendung teilweise freizugeben. In So können Sie sicher sein, dass die neue Version Ihrer Anwendung zuverlässig ist, allen Nutzenden bereitstellen.

Wenn Sie eine Bereitstellung in GKE oder GKE Enterprise vornehmen, Sie die neue Version Ihrer Anwendung beispielsweise auf einem eingeschränkten Anzahl der Pods. Die alte Version würde weiterhin funktionieren, aber mit mehr an die neuen Pods gesendet wird.

Wenn Sie die Bereitstellung in Cloud Run, Cloud Run teilt den Traffic zwischen der alten und der neuen Überarbeitung auf Prozentsätze, die Sie konfigurieren.

Canary-Typen

Mit Cloud Deploy können Sie die folgenden Canary-Typen konfigurieren Bereitstellung:

• Automatisiert

  Mit einem automatisiertes Canary konfigurieren Sie Cloud Deploy mit einer Reihe von die eine progressive Bereitstellung ausdrücken. Cloud Deploy weitere Vorgänge in Ihrem Namen ausführen, um Traffic aufzuteilen Prozentsätze zwischen der alten und der neuen Version.

• Benutzerdefiniert – automatisiert

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

  • 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 bereitstellen. Cloud Deploy erstellt die erforderlichen Ressourcen, wie beschrieben hier.

• Benutzerdefiniert

  Bei einem benutzerdefinierten Canary können Sie jede Canary-Phase separat konfigurieren. einschließlich der folgenden:

  • 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 Konfiguration des Traffic-Balancing, wie beschrieben hier.

Phasen einer Canary-Bereitstellung

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

Wenn Sie beispielsweise einen Canary-Test mit den Schritten 25%, 50 % und 75% konfigurieren, Die Einführung umfasst folgende Phasen:

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

Hinweis: Für eine GKE, Gateway API-Konfiguration 100% ist zulässig. Dies unterstützt eine vollständige Bereitstellung aus der Canary-Version vor dem Wechsel zu stable. Die 100 %-Konfiguration ist für GKE nicht zulässig dienstbasiertes Canary, GKE Enterprise oder Cloud Run).

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 beim Rendern Ihres Kubernetes-Manifests oder Konfiguration des Cloud Run-Dienstes:

GKE/Enterprise

So führt Cloud Deploy ein Canary-Deployment in netzwerkbasierte GKE und GKE Enterprise:

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

2. Cloud Deploy erstellt eine zusätzliche Deployment-Ressource mit den Namen Ihres aktuellen Deployments plus -canary.

3. Cloud Deploy ändert den Dienst so, dass die Auswahl auf die Pods im aktuellen Deployment und die Canary-Pods auswählen.

   Cloud Deploy berechnet die Anzahl der Pods, die für den Canary-Version basierend auf der beschriebenen Berechnung hier. Diese Berechnung unterscheidet sich je nach ob Sie die Pod-Überbereitstellung aktivieren oder deaktivieren.

   Wenn wir in die stable-Phase übergehen Cloud Deploy fügt die Labels hinzu, die zum Abgleichen von Pods verwendet werden sollen. sind sie für nachfolgende Canary-Läufe verfügbar.

   Cloud Deploy erstellt ein Deployment, das die phasenspezifischen Prozentsatz der Pods und aktualisiert ihn für jede Phase. Dies ist indem wir die Anzahl der Pods als Prozentsatz des Originals Anzahl der Pods. Dies kann zu einer ungenauen Aufteilung der Zugriffe führen. Bei Bedarf eine exakte Aufteilung der Zugriffe, können Sie diese mit 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 und das ursprüngliche Deployment wird durch das neue Deployment ersetzt.

   Cloud Deploy ändert das ursprüngliche Deployment erst, wenn stable.

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

Für die netzwerkbasierte GKE-Canary-Version haben Sie folgende Möglichkeiten: Aktivieren oder deaktivieren Sie die Pod-Überbereitstellung. In den folgenden Abschnitten wird beschrieben, wie Cloud Deploy die Anzahl der Pods, die für das Canary-Deployment in jeder Canary-Phase bereitgestellt werden.

Pod-Bereitstellung mit aktivierter Überbereitstellung

Überbereitstellung wird aktiviert (disablePodOverprovisioning: false) ermöglicht es Cloud Deploy, genügend zusätzliche Pods zu erstellen, um die Gewünschter Canary-Prozentsatz basierend auf der Anzahl der Pods, die Ihre bereits vorhandener Bereitstellung. Die folgende Formel zeigt, Cloud Deploy berechnet die Anzahl der Pods, die für den Canary-Deployment für jede Canary-Phase, wenn die Pod-Überbereitstellung aktiviert:

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

Mit dieser Formel kann die aktuelle Anzahl der Replikate (die Anzahl der Pods, die Sie bereits vor diesem Canary-Test mit dem Canary-Prozentsatz für den Wert und das Ergebnis wird durch (100 minus den Prozentsatz) dividiert.

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

Warnung: Wenn Sie Canary-Prozentsätze von mehr als 50% verwenden, kann dies zu einer sehr großen die Anzahl der Pods zunimmt. Im vorherigen Beispiel wurden vier führt ein Canary-Wert von 90% zu 36 Canary-Pods. Wenn Sie also Prozentsätze über 50 % verwenden möchten, empfehlen wir, wie im nächsten Abschnitt beschrieben.

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 den Pod berechnet Bereitstellung für das Canary-Deployment für jede Canary-Phase, wenn der Pod Überdimensionierung ist deaktiviert:

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

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

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

Gateway GKE/Enterprise

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

1. Zusätzlich zu den Referenzen für das Deployment und den Dienst geben Sie HTTPRoute-Ressource mit einer backendRefs-Regel, die auf den Dienst verweist.

2. Cloud Deploy erstellt ein neues Deployment mit dem Namen Ihrer ursprüngliches Deployment plus -canary und einen neuen Service mit dem ursprünglichen Dienstname 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.

   Weil es bei der Übertragung von Änderungen an „HTTPRoute“ zu Verzögerungen kommen kann Ressourcen, können Sie die Property routeUpdateWaitTime in Ihr Konfiguration, sodass das System eine bestimmte Zeit Verbreitung von Inhalten.

4. Während der stable-Phase wird das -canary-Deployment auf null und das ursprüngliche Deployment wird aktualisiert, um die Bereitstellung.

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

   Cloud Deploy ändert das ursprüngliche Deployment oder Dienst bis zur stable-Phase.

Cloud Run

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

• Geben Sie für ein Canary-Deployment in Cloud Run traffic stanza in die YAML-Datei Ihres Dienstes ein.

• Beim Erstellen eines neuen Roll-outs für die Canary-Version teilt Cloud Deploy auf zwischen der vorherigen Version, die erfolgreich von Cloud Deploy und eine neue Version.

Wenn Sie die Unterschiede zwischen den Phasen einer Canary-Bereitstellung sehen möchten, können Änderungen im gerenderten Manifest pro Phase sehen, das im Release Inspector. Sie können das bereits tun, Einführung hat begonnen. Wenn Sie eine parallelen Bereitstellung aktiviert haben, können Sie auch die gerendertes Manifest.

Hinweis: Wenn Cloud Deploy eine vorhandene bereitgestellte Ressource nicht finden kann, wird der Befehl Canary-Phasen beim ersten Lauf übersprungen das Canary-Deployment.

Canary-Deployment konfigurieren

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

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

Prüfen Sie, ob Sie die erforderlichen Berechtigungen haben

Zusätzlich zu den anderen Identity and Access Management-Berechtigungen, die Sie für die Verwendung von Cloud Deploy benötigen Sie die folgenden Berechtigungen, um weitere Aktionen ausführen, die möglicherweise für ein Canary-Deployment erforderlich sind:

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

Siehe IAM-Rollen und -Berechtigungen finden Sie weitere Informationen dazu, welche verfügbaren Rollen diese Berechtigungen enthalten.

skaffold.yaml vorbereiten

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

Die skaffold.yaml, die Sie für ein Canary-Deployment erstellen, hat keine spezielle über die Anforderungen für Standard- Bereitstellung.

Manifest- oder Dienstdefinition vorbereiten

Wie bei einer Standardbereitstellung benötigt auch Ihre Canary-Version ein Kubernetes-Manifest oder ein 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 der Bereitstellung angegeben.

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

Cloud Run

Für Canary in Cloud Run Cloud Run-Dienstdefinitionsdatei ist ausreichend, ohne eine traffic-Stanza. Cloud Deploy verwaltet Aufteilung zwischen der letzten erfolgreichen und der neuen Version.

Automatisiertes Canary konfigurieren

Die folgende Anleitung gilt für Cloud Run und Dienstbasiertes Netzwerk in GKE und GKE Enterprise Ziele. Wenn Sie die Kubernetes Gateway API mit GKE oder Informationen zu GKE Enterprise finden Sie in dieser 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. die du in deinem Manifest definiert hast.

• DEPLOYMENT_NAME ist der Name Ihrer Kubernetes-Instanz Bereitstellung, die in Ihrem Manifest definiert ist.

• PERCENTAGES ist eine durch Kommas getrennte Liste mit Prozentsätzen Werte, die Ihre Canary-Inkremente darstellen, z. B. [5, 25, 50].

  Außerdem ist 100 nicht enthalten, da eine Bereitstellung zu 100 % in der Canary-Version vorausgesetzt und vom stable-Phase.

• Sie können die Bereitstellungsprüfung aktivieren (verify: true). 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 mit Prozentsätzen Werte, die Ihre Canary-Inkremente darstellen, z. B. [25, 50, 75]. Hinweis dass 100 dabei nicht enthalten ist, weil eine Bereitstellung zu 100 % in der Canary-Version vorausgesetzt und vom stable-Phase.
• Sie können die Bereitstellungsprüfung aktivieren (verify: true). In diesem Fall wird jedem Job verify ein Job hinzugefügt. Canary-Phase.

Benutzerdefinierte Canary-Version konfigurieren

Sie können die Canary-Version manuell konfigurieren, anstatt sich vollständig auf das die von Cloud Deploy bereitgestellt wird. Mit benutzerdefiniertem Canary Konfiguration angeben, 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 oder stable). Mit einem benutzerdefinierten Canary-Code Sie können jeder Phase einen beliebigen Namen geben, solange dieser noch einmalig ist. für diese Canary-Phase und berücksichtigt Einschränkungen für Ressourcennamen. Aber die letzte (100%) muss stable sein.

• 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 oder dasselbe Profil verwenden. oder eine beliebige Kombination. Jedes Profil kann ein anderes Kubernetes-Manifest verwenden. oder Cloud Run-Dienstdefinition. Sie können auch mehr als für eine bestimmte Phase. Cloud Deploy kombiniert sie.

• Ob es für die Phase einen Verifizierungsjob gibt

  Wenn Sie die Überprüfung aktivieren, skaffold.yaml konfigurieren für zu überprüfen.

Alle Zieltypen für benutzerdefinierte Canary-Versionen unterstützt.

Benutzerdefinierte Canary-Konfigurationselemente

Die folgende YAML-Datei zeigt die Konfiguration für die Phasen der vollständig benutzerdefinierten Canary-Version Bereitstellung:

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 dasselbe Profil verwenden, für jede Phase, eine andere für jede Phase oder eine beliebige Kombination. Außerdem können Sie mehrere Profile angeben. Cloud Deploy verwendet alle von Ihnen angegebene Profile sowie das Profil oder Manifest, das vom allgemeinen .

• PERCENTAGE1

  Entspricht dem Prozentsatz, der in der ersten Phase bereitgestellt werden soll. Jede Phase muss eine eindeutige Prozentsatz, der ein ganzer Prozentwert sein muss (nicht 10.5 für ) und die Phasen müssen in aufsteigender Reihenfolge sein.

• verify: true|false

  Gibt Cloud Deploy an, ob für die Phase ein Prüfjob eingefügt werden soll. Skaffold verwendet in jeder Phase zur Verwendung der Verifizierung das gleiche Profil für Überprüfen Sie, ob für diese Phase für Rendering und Bereitstellung angegeben ist.

• stable

  Die letzte Phase muss den Namen stable haben.

Der Prozentsatz für die letzte Phase muss 100 sein. Phasen werden nach in der Reihenfolge, in der Sie sie in dieser ​customCanaryDeployment-Stanza konfigurieren, aber wenn nicht in aufsteigender Reihenfolge, wird der Befehl zum Bereitstellungspipeline registrieren schlägt mit einem Fehler fehl.

Die Konfiguration für eine benutzerdefinierte Canary-Version enthält kein runtimeConfig Stanza. Das Hinzufügen von runtimeConfig gilt als benutzerdefinierten automatisierten Canary-Test.

Benutzerdefinierte automatisierte Canary-Version konfigurieren

Ein benutzerdefiniertes automatisiertes Canary ähnelt einem benutzerdefinierten Canary. da Sie die separaten Canary-Phasen mit benutzerdefinierten Phasennamen angeben, Prozentwerte, Skaffold-Profile und Verifizieren von Jobs. Bei einem benutzerdefinierten Canary-Code Sie stellen nicht die Konfigurationen bereit, die die Traffic-Aufteilung definieren – Cloud Deploy macht das für Sie erstellen, aber Sie bieten Skaffold-Profile die für jede Phase verwendet werden.

Fügen Sie zum Konfigurieren einer benutzerdefinierten automatisierten Canary-Version eine runtimeConfig-Stanza wie folgt ein: hier sehen, und enthalten die customCanaryDeployment-Stanza, wie gezeigt. hier.

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

Mit einer Cloud Deploy-Canary-Bereitstellung können Sie Anwendung in einem dienstbasierten Kubernetes-Netzwerk bereitstellen Alternativ können Sie das Service Mesh der Kubernetes Gateway API verwenden. In diesem Abschnitt wird dies beschrieben.

Sie können die Gateway API mit Istio oder anderen unterstützte Implementierung.

1. Richten Sie die Gateway API-Ressourcen ein:

   • Istio verwenden

   • GKE Gateway Controller

   Hierbei handelt es sich lediglich um Beispiele.

2. Im Kubernetes-Manifest, das an Cloud Deploy bei folgenden Aktionen bereitgestellt wird: die den Release erstellt haben und Folgendes enthalten:

   • Ein HTTPRoute die auf Ihre Gateway-Ressource verweist

   • Eine Bereitstellung

   • Ein Dienst

3. Bereitstellungspipeline und das Ziel konfigurieren, das Sie im Rahmen eines Canary-Deployments bereitstellen möchten in:

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

   • Konfiguration der Bereitstellungspipeline in der Fortschrittsreihenfolge für die spezifisches Ziel, enthält eine gatewayServiceMesh-Stanza als Referenz auf Ihre Die HTTPRoute-Konfiguration der Kubernetes Gateway API sowie Ihr Deployment und Service.

     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 Routing definiert das gewünschte Verhalten.

     • SERVICE ist Ihre Dienstkonfiguration, die Cloud Deploy erfordert Canary-Bereitstellungen, um GKE und GKE Enterprise

     • DEPLOYMENT ist Ihre Deployment-Konfiguration, Cloud Deploy erfordert Canary-Bereitstellungen, um GKE und GKE Enterprise

     • WAIT_TIME ist die Zeitspanne, in der Cloud Deploy für Warten Sie, bis die Änderungen an der Ressource HTTPRoute vollständig übernommen wurden. verworfene Anfragen zu vermeiden. Beispiel: routeUpdateWaitTime: 60s.

       Wenn Sie Canary mit der Gateway API ohne Istio und dem Gateway ausführen ist die API mit einem Google Cloud-Load-Balancer kann Traffic verloren gehen, wenn die Canary-Instanz herunterskaliert wird. Sie können konfigurieren Sie diese Einstellung, 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 heißt, das Ziel, für das Sie die Bereitstellung schrittweise vornehmen, kann zwei oder mehr untergeordneten Zielen. Beispielsweise können Sie die Bereitstellung schrittweise in Clustern in separaten in verschiedenen Regionen.

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

• Wie beim Canary-Deployment mit einem einzelnen Ziel gilt auch hier Folgendes: GKE-Ziele benötigen Sie eine Kubernetes-Deployment-Konfiguration und eine Kubernetes-Dienstkonfiguration in Ihrem Manifest.

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

• Außerdem müssen Sie mehrere Ziele konfigurieren, und Sie müssen untergeordnete Ziele konfigurieren die auf mehrere Ziele verweist.

• Wenn du einen Release erstellst, wird ein Controller-Roll-out und die untergeordneten Roll-outs werden erstellt.

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

• Du kannst nicht fortfahren. ein untergeordnetes Roll-out.

  Sie können nur Controller-Roll-outs fortsetzen. Wenn du zum nächsten Schritt übergehst werden die untergeordneten Rollouts ebenfalls fortgeführt, Cloud Deploy:

• Du kannst es nicht wiederholen fehlgeschlagenen Jobs im Controller-Roll-out.

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

• Sie können nicht ignorieren. fehlgeschlagenen Jobs im Controller-Roll-out.

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

• Sie können ein Controller-Roll-out abbrechen. Untergeordnete Roll-outs können jedoch nicht abgebrochen werden.

• Sie können Jobausführungen beenden nur für ein untergeordnetes Roll-out und nicht für ein 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 zu einem anderen Roll-out je nachdem, was mit den untergeordneten Roll-outs geschieht:

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

• Wenn ein oder mehrere untergeordnete Roll-outs fehlschlagen, aber mindestens ein untergeordnetes Roll-out erfolgreich ist, Das Controller-Roll-out ist HALTED, wenn es nach dem aktuellen Status weitere Phasen gibt eins.

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

  HALTED gibt Ihnen die Möglichkeit, entweder ignore, wiederholen Fehlgeschlagene Jobs innerhalb des fehlgeschlagenen untergeordneten Roll-outs oder Controller-Roll-out abbrechen und verhindern, dass weitere Aktionen an den untergeordneten Roll-outs ausgeführt werden.

• Wenn das Controller-Roll-out aufgrund eines fehlerhaften untergeordneten Elements den Status HALTED hat und Sie ignorieren den fehlgeschlagenen Job im untergeordneten Roll-out, wird der Controller Roll-out wird 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 umfasst die automatisierte oder benutzerdefinierte Canary-Konfiguration, für die gewählte Laufzeit.

   Bei diesem Befehl wird davon ausgegangen, dass Ihre Ziele in derselben Datei definiert sind oder die andernfalls bereits registriert sind. Wenn nicht, registrieren Sie Ihre Ziele .

2. Release erstellen:

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

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

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 der nächsten Phase fortfahren.

   RELEASE_NAME ist der Name des Release, der Teil dieses Rollouts ist.

   PIPELINE_NAME ist der Name der Übermittlung mit der Sie die Bereitstellung dieses Release verwalten.

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

   In der Google Cloud SDK-Referenz finden Sie weitere Informationen zu den gcloud deploy rollouts advance-Befehl

   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 der den Fortschritt Ihrer Bereitstellungspipeline anzuzeigen.

   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.

      

      Beachten Sie, dass das Roll-out in diesem Beispiel eine canary-50-Phase und einen stable. Ihr Roll-out umfasst möglicherweise mehr Phasen oder unterschiedliche Phasen.

   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 dort noch nicht bereitgestellt wurde: überspringt Cloud Deploy die Canary-Phase und führt die stabile . Weitere Informationen finden Sie unter Phasen das erste Mal überspringen. um die Ursache zu ermitteln.

Nächste Schritte

• Kurzanleitung für das Canary-Deployment

• Lebenszyklus von Canary-Roll-outs verwalten

• Parallele Bereitstellung