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 wird weiterhin ausgeführt, aber ein größerer Teil des Traffics wird an die neuen Pods gesendet.

Wenn Sie die Bereitstellung in Cloud Run vornehmen, wird der Traffic in Cloud Run entsprechend den von Ihnen konfigurierten Prozentsätzen zwischen der alten und der neuen Version aufgeteilt.

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 custom-automated 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
  • Gibt an, ob ein Job vor der Bereitstellung, einen Job nach der Bereitstellung oder beides einbezogen werden soll

  Sie müssen jedoch keine Informationen zum Traffic-Balancing bereitstellen. Cloud Deploy erstellt den notwendig sind.

• 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
  • Ob ein Job vor oder nach der Bereitstellung oder beides enthalten sein soll

  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 eine Canary-Bereitstellung erstellen, wird das Roll-out mit einer Phase für jedes Canary-Inkrement sowie einer abschließenden stable-Phase für 100 % erstellt.

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

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:

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. Das ist sogar möglich, bevor das Roll-out begonnen hat. Wenn Sie eine parallelen Bereitstellung aktiviert haben, können Sie auch die gerendertes Manifest.

Canary-Bereitstellung konfigurieren

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

Die Anleitung hier enthält nur die für die Canary-Konfiguration spezifischen Schritte. 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.

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 GKE Enterprise verwenden, lesen Sie diese Dokumentation.

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

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "SERVICE_NAME"
              deployment: "DEPLOYMENT_NAME"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

serialPipeline:
  stages:
  - targetId: prod
    profiles: []
    strategy:
      canary:
        runtimeConfig:
          cloudRun:
            automaticTrafficControl: true
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

Benutzerdefinierten Canary 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. Der Name der letzten Phase (100 %) muss jedoch stable sein.

• Prozentuale Ziele 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 ein Profil 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.

• Gibt an, ob für die Phase Jobs vor oder nach der Bereitstellung vorhanden sind

  Wenn Sie Jobs vor oder nach der Bereitstellung aktivieren, müssen Sie Ihre skaffold.yaml für diese Jobs konfigurieren.

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
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"
      - …
      - phaseId: "stable"
        percentage: 100
        profiles: [ "LAST_PROFILE_NAME" ]
        verify: true|false
        predeploy:
          actions: "PREDEPLOY_ACTION"
        postdeploy:
          actions: "POSTDEPLOY_ACTION"

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. Sie können auch mehrere Profile angeben. Cloud Deploy verwendet alle von Ihnen angegebenen Profile sowie das Profil oder Manifest, das für die gesamte Phase verwendet wird.

• stable

  Die letzte Phase muss den Namen stable haben.

• 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 an, ob Cloud Deploy einen Überprüfungsjob für die Phase einschließen soll. Skaffold verwendet für jede Phase zur Verwendung Überprüfen Sie, ob für diese Phase für Rendering und Bereitstellung angegeben ist.

• PREDEPLOY_ACTION

  Ist mit der ACTION_NAME identisch, die Sie in Ihrem skaffold.yaml, um die benutzerdefinierte Aktion zu definieren, die vor der Bereitstellung ausgeführt werden soll.

• POSTDEPLOY_ACTION

  Ist mit der ACTION_NAME identisch, die Sie in Ihrem skaffold.yaml zum Definieren der benutzerdefinierten Aktion, die Sie nach der Bereitstellung ausführen möchten.

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. Wenn Sie runtimeConfig angeben, wird es als benutzerdefinierter automatischer Canary betrachtet.

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, Überprüfung von Jobs sowie Vor- und Nachbereitung Jobs. Bei einem benutzerdefinierten Canary-Code hingegen Konfigurationen 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.

Wenn Sie einen benutzerdefinierten, automatisierten Canary konfigurieren möchten, fügen Sie einen runtimeConfig-Abschnitt wie hier und einen customCanaryDeployment-Abschnitt wie hier ein.

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. Fügen Sie Ihrem Kubernetes-Manifest, das Sie beim Erstellen des Release an Cloud Deploy gesendet haben, Folgendes hinzu:

   • 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 Verweis 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"
              podSelectorLabel: "LABEL"
        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 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.

     • LABEL ist ein Pod-Auswahllabel. Muss mit dem Label übereinstimmen im Kubernetes-Dienst und -Deployment, die in Ihrem Manifest definiert sind. Dies ist optional. Der Standardwert ist app.

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 nur einem 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 Sie einen Release erstellen, werden ein Controller-Roll-out und die untergeordneten Roll-outs 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 Level wechselst 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.

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

  Sie können fehlgeschlagene Jobs nur in untergeordneten Roll-outs ignorieren.

• 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 anderweitig bereits registriert wurden. Falls nicht, müssen Sie Ihre Ziele auch registrieren.

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 Releases, zu dem dieses Roll-out gehört.

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

   REGION ist der Name der Region, in der die 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 Seite mit den Details der Lieferpipeline zeigt eine grafische Darstellung des Fortschritts der Lieferpipeline.

   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.

      

      Beachten Sie, dass das Roll-out in diesem Beispiel eine canary-50-Phase und einen stable. Ihr Roll-out kann mehr Phasen oder andere Phasen umfassen 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 noch nicht dort bereitgestellt wurde: überspringt Cloud Deploy die Canary-Phase und führt die stabile . Weitere Informationen finden Sie unter Phasen beim ersten Mal überspringen.

Nächste Schritte

• Kurzanleitung für das Canary-Deployment

• Weitere Informationen zum Verwalten des Lebenszyklus der Canary-Roll-outs

• Weitere Informationen zur parallelen Bereitstellung