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

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 nachdem, ob Sie die Überprovisionierung von Pods aktivieren oder deaktivieren.

   Wenn wir zur Phase stable springen, 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 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 die -canary-Bereitstellung auf null skaliert und die ursprüngliche Bereitstellung durch die neue 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 Ihr Canary auf dem Traffic basieren soll, müssen Sie 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 Überdimensionierung

Ü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 Überprovisionierung (disablePodOverprovisioning: true) deaktivieren, damit Cloud Deploy die Anzahl der Repliken 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 zum Deployment und zum 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 die -canary-Bereitstellung auf null skaliert und die ursprüngliche Bereitstellung wird aktualisiert, um die Bereitstellung der neuen Version zu verwenden.

   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 eine Canary-Bereitstellung für Cloud Run aus:

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

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

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.

GKE und GKE Enterprise

Für Canary muss das Manifest Folgendes enthalten:

• Ein Deployment und einen Dienst.

• Der Dienst muss einen Selector definieren, der die Pods auswählen muss des angegebenen Deployments. Der Standardwert ist app.

• 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 die Aufteilung des Traffics zwischen der letzten erfolgreichen Version 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 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"
              podSelectorLabel: "LABEL"
        canaryDeployment:
          percentages: [PERCENTAGES]
          verify: true|false
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

In dieser Konfiguration...

• SERVICE_NAME ist der Name des Kubernetes-Dienstes. die in deinem Manifest definiert sind.

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

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

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

  Außerdem wird 100 nicht berücksichtigt, weil eine Bereitstellung zu 100 % in der Canary-Version vorausgesetzt und vom stable-Phase.

• Sie können die Bereitstellungsüberprüfung (verify: true) aktivieren. In diesem Fall wird in jeder Phase ein verify-Job aktiviert.

• PREDEPLOY_ACTION

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

• POSTDEPLOY_ACTION

  Ist mit der ACTION_NAME identisch, die Sie in Ihrem skaffold.yaml zum Definieren der benutzerdefinierten Aktion, die ausgeführt werden soll Bereitstellung.

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
          predeploy:
            actions: "PREDEPLOY_ACTION"
          postdeploy:
            actions: "POSTDEPLOY_ACTION"

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

• PREDEPLOY_ACTION

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

• POSTDEPLOY_ACTION

  Entspricht der ACTION_NAME, die Sie in Ihrem skaffold.yaml verwendet haben, um die benutzerdefinierte Aktion zu definieren, die nach der Bereitstellung ausgeführt werden soll.

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