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 progressives Roll-out einer Anwendung, bei dem der Traffic zwischen einer bereits bereitgestellten Version und einer neuen Version aufgeteilt wird. Die neue Version wird für einen Teil der Nutzer eingeführt, bevor sie vollständig eingeführt wird.

Unterstützte Zieltypen

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

Canary funktioniert auch mit mehreren Zielen.

Warum sollten Sie eine Canary-Release-Strategie verwenden?

Mit einer Canary-Bereitstellung können Sie Ihre Anwendung teilweise veröffentlichen. So können Sie sichergehen, dass die neue Version Ihrer Anwendung zuverlässig ist, bevor Sie sie für alle Nutzer bereitstellen.

Wenn Sie beispielsweise in GKE oder GKE Enterprise bereitstellen, können Sie die neue Version Ihrer Anwendung in einer begrenzten Anzahl von Pods bereitstellen. 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.

Arten von Canary

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

  • Automatisiert

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

  • Benutzerdefiniert automatisiert

    Für einen benutzerdefinierten, automatisierten Canary können Sie Folgendes angeben:

    • den Namen der Phase
    • Das prozentuale Ziel
    • Das Skaffold-Profil, das für die Phase verwendet werden soll
    • Ob ein Bestätigungsjob enthalten sein soll
    • Ob ein Job vor oder nach der Bereitstellung oder beides enthalten sein soll

    Sie müssen jedoch keine Informationen zum Traffic-Balancing angeben. Die erforderlichen Ressourcen werden von Cloud Deploy erstellt.

  • Benutzerdefiniert

    Bei einem benutzerdefinierten Canary-Test konfigurieren Sie jede Canary-Phase separat, einschließlich der folgenden:

    • den Namen der Phase
    • Das prozentuale Ziel
    • Das Skaffold-Profil, das für die Phase verwendet werden soll
    • Ob ein Bestätigungsjob enthalten sein soll
    • Ob ein Job vor oder nach der Bereitstellung oder beides enthalten sein soll

    Bei einem vollständig benutzerdefinierten Canary müssen Sie außerdem die gesamte Traffic-Balancing-Konfiguration angeben, wie hier beschrieben.

Phasen eines Canary-Deployments

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 für Steigerungen von 25%, 50 % und 75% konfigurieren, umfasst das Roll-out die folgenden Phasen:

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

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

Was passiert bei einem automatischen oder benutzerdefinierten Canary-Test?

Zur Unterstützung Ihrer Canary-Bereitstellung enthält Cloud Deploy spezielle Verarbeitungsschritte beim Rendern Ihres Kubernetes-Manifests oder Ihrer 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 Deployment-Ressource und der Dienstressource an.

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

  3. Cloud Deploy ändert den Dienst, um den Selektor so anzupassen, dass die Pods im aktuellen Deployment und die Canary-Pods ausgewählt werden.

    Cloud Deploy berechnet die Anzahl der Pods, die für den Canary verwendet werden sollen, anhand der hier beschriebenen Berechnung. 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 den phasenspezifischen Prozentsatz der Pods enthält, und aktualisiert es für jede Phase. Dazu wird die Anzahl der Pods als Prozentsatz der ursprünglichen Anzahl der Pods berechnet. Dies kann zu einer ungenauen Aufteilung der Zugriffe führen. Wenn Sie eine genaue Traffic-Aufteilung benötigen, können Sie die Gateway API verwenden.

    Außerdem werden Secrets und ConfigMaps mit -canary kopiert und 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 die ursprüngliche Bereitstellung erst in der stable-Phase.

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

Bei einem GKE-Netzwerk-basierten Canary können Sie die Überprovisionierung von Pods aktivieren oder deaktivieren. In den folgenden Abschnitten wird beschrieben, wie Cloud Deploy die Anzahl der Pods berechnet, die für die Canary-Bereitstellung für jede Canary-Phase bereitgestellt werden sollen.

Pod-Bereitstellung mit aktivierter Überdimensionierung

Wenn Sie die Überprovisionierung aktivieren (disablePodOverprovisioning: false), kann Cloud Deploy anhand der Anzahl der Pods, in denen Ihre vorhandene Bereitstellung ausgeführt wird, genügend zusätzliche Pods erstellen, um den gewünschten Canary-Prozentsatz auszuführen. In der folgenden Formel wird gezeigt, wie Cloud Deploy die Anzahl der Pods berechnet, die für die Canary-Bereitstellung für jede Canary-Phase bereitgestellt werden sollen, wenn die Überprovisionierung von Pods aktiviert ist:

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

Bei dieser Formel wird die aktuelle Anzahl der Replikate (die Anzahl der Pods, die Sie bereits vor diesem Canary haben) mit dem Canary-Prozentsatz für die Phase multipliziert und das Ergebnis durch (100 minus den Prozentsatz) geteilt.

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

Die Pod-Überdimensionierung ist das Standardverhalten.

Pod-Bereitstellung mit deaktivierter Überdimensionierung

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

In der folgenden Formel wird gezeigt, wie Cloud Deploy die Pod-Bereitstellung für die Canary-Bereitstellung für jede Canary-Phase berechnet, wenn die Pod-Überprovisionierung deaktiviert ist:

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

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

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

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 Bereitstellungs- und Dienstreferenzen geben Sie eine HTTPRoute-Ressource mit einer backendRefs-Regel an, die auf den Dienst verweist.

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

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

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

    Da es zu Verzögerungen bei der Weitergabe von Änderungen an HTTPRoute-Ressourcen kommen kann, können Sie die Property routeUpdateWaitTime in Ihre Konfiguration aufnehmen. Das System wartet dann eine bestimmte Zeit auf die Weitergabe.

  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 jetzt auf die von Ihnen angegebene Originalversion 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 eine Canary-Bereitstellung für Cloud Run aus:

  • Geben Sie für eine Canary-Bereitstellung in Cloud Run in der YAML-Datei des Dienstes keinen traffic-Abschnitt an.

  • Wenn Sie ein neues Canary-Roll-out erstellen, teilt Cloud Deploy den Traffic zwischen der vorherigen Version, die von Cloud Deploy erfolgreich bereitgestellt wurde, 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 phasenweise gerenderten Manifest ansehen, das im Release-Inspektor verfügbar ist. Das ist sogar möglich, bevor das Roll-out begonnen hat. Wenn Sie die parallele Bereitstellung verwenden, können Sie auch das gerenderte Manifest jedes untergeordneten Elements prüfen.

Canary-Bereitstellung konfigurieren

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

Die Anleitung hier enthält nur die für die Canary-Konfiguration spezifischen Schritte. Im Dokument Anwendung bereitstellen finden Sie allgemeine Anweisungen zum Konfigurieren und Ausführen Ihrer Bereitstellungspipeline.

Prüfen, 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 zusätzliche Aktionen auszuführen, die für eine Canary-Bereitstellung erforderlich sein können:

  • 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 Rollen diese Berechtigungen enthalten, finden Sie unter IAM-Rollen und -Berechtigungen.

skaffold.yaml vorbereiten

Wie bei einer Standardbereitstellung benötigt Ihr Canary eine skaffold.yaml-Datei, in der festgelegt wird, wie Manifeste und Dienstdefinitionen gerendert und bereitgestellt werden.

Für die skaffold.yaml, die Sie für eine Canary-Bereitstellung erstellen, gelten keine besonderen Anforderungen, die über die für die Standardbereitstellung erforderlichen hinausgehen.

Manifest oder Dienstdefinition vorbereiten

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

GKE und GKE Enterprise

Das Manifest für Canary-Versionen muss Folgendes enthalten:

  • Ein Deployment und ein Dienst.

  • Der Dienst muss einen Selektor definieren und dieser Selektor muss die Pods der angegebenen Bereitstellung auswählen. Der Standardwert ist app.

  • Wenn Sie einen Gateway API-basierten Canary verwenden, muss das Manifest auch eine HTTPRoute enthalten.

Cloud Run

Für Canary-Versionen in Cloud Run reicht die normale Cloud Run-Dienstdefinition ohne traffic-Strophe aus. Cloud Deploy verwaltet die Aufteilung des Traffics zwischen der letzten erfolgreichen Version und der neuen Version.

Automatischen Canary konfigurieren

Die folgende Anleitung gilt für Cloud Run- und GKE- sowie GKE Enterprise-Dienste, die als netzwerkbasierte Ziele verwendet werden. Wenn Sie die Kubernetes Gateway API mit GKE oder GKE Enterprise verwenden, lesen Sie diese Dokumentation.

Sie konfigurieren den automatischen Canary in der Definition der Bereitstellungspipeline:

GKE und GKE Enterprise

Fügen Sie in der Pipeline-Phase eine strategy-Property hinzu:

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"

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

  • LABEL ist ein Pod-Selektor-Label. Sie muss mit der Labelauswahl im Kubernetes-Dienst übereinstimmen, der in Ihrem Manifest definiert ist. Dies ist optional. Der Standardwert ist app.

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

    100 ist hiervon ausgenommen, da im Canary-Release eine 100-prozentige Bereitstellung vorausgesetzt wird und von der stable-Phase abgedeckt wird.

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

  • PREDEPLOY_ACTION

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

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

Cloud Run

Fügen Sie in der Pipeline-Phase eine strategy-Property hinzu:

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 von Prozentwerten, die die Canary-Steigerung darstellen, z. B. [25, 50, 75]. 100 ist hiervon ausgenommen, da im Canary-Release eine 100-prozentige Bereitstellung vorausgesetzt wird und von der stable-Phase abgedeckt wird.

  • Sie können die Bereitstellungsbestätigung (verify: true) aktivieren. In diesem Fall wird jeder Canary-Phase ein verify-Job hinzugefügt.

  • PREDEPLOY_ACTION

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

  • 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 Ihren Canary manuell konfigurieren, anstatt sich vollständig auf die Automatisierung von Cloud Deploy zu verlassen. Bei einer benutzerdefinierten Canary-Konfiguration geben Sie in der Definition der Bereitstellungspipeline Folgendes an:

  • Namen der Einführungsphasen

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

  • Prozentuale Ziele für jede Phase

    Geben Sie die Prozentsätze für jede Phase separat an.

  • Skaffold-Profile, die für die Phase verwendet werden sollen

    Sie können für jede Phase ein separates Skaffold-Profil oder dasselbe Profil oder eine beliebige Kombination verwenden. Für jedes Profil kann ein anderes Kubernetes-Manifest oder eine andere Cloud Run-Dienstdefinition verwendet werden. Sie können auch mehrere Profile für eine bestimmte Phase verwenden. Cloud Deploy kombiniert beides.

  • Gibt an, ob es für die Phase einen Überprüfungsjob gibt.

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

  • Ob es für die Phase Jobs vor der Bereitstellung oder nach der Bereitstellung gibt

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

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

Benutzerdefinierte Canary-Konfigurationselemente

Die folgende YAML-Datei zeigt die Konfiguration für die Phasen einer vollständig benutzerdefinierten Canary-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 diesem YAML-File

  • PHASE1_NAME

    Ist der Name der Phase. Die Namen der Phasen müssen 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 verwenden, für jede Phase ein anderes 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 stable heißen.

  • PERCENTAGE1

    Der Prozentsatz, der für die erste Phase bereitgestellt werden soll. Jede Phase muss einen eindeutigen Prozentsatz haben. Dieser Wert muss ein ganzer Prozentsatz sein (z. B. nicht 10.5). Die Phasen müssen in aufsteigender Reihenfolge angegeben werden.

  • verify: true|false

    Gibt an, ob Cloud Deploy einen Überprüfungsjob für die Phase einschließen soll. Für jede Phase, in der „verify“ verwendet wird, verwendet Skaffold dasselbe Profil für „verify“, das für die Rendering- und Bereitstellungsschritte dieser Phase angegeben ist.

  • PREDEPLOY_ACTION

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

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

Der Prozentsatz für die letzte Phase muss 100 betragen. Die Phasen werden in der Reihenfolge ausgeführt, in der du sie in diesem ​customCanaryDeployment-Satz konfigurierst. Wenn die Prozentwerte jedoch nicht in aufsteigender Reihenfolge sind, schlägt der Befehl zum Registrieren der Bereitstellungspipeline mit einer Fehlermeldung fehl.

Die Konfiguration für einen benutzerdefinierten Canary enthält keine runtimeConfig-Strophe. Wenn Sie runtimeConfig angeben, wird es als benutzerdefinierter automatischer Canary betrachtet.

Benutzerdefinierte automatisierte Canary-Version konfigurieren

Ein benutzerdefinierter, automatisierter Canary ähnelt einem benutzerdefinierten Canary, da Sie die einzelnen Canary-Phasen mit benutzerdefinierten Phasennamen, Prozentwerten, Skaffold-Profilen, Überprüfungsjobs sowie Pre-Deploy- und Post-Deploy-Jobs angeben. Bei einem benutzerdefinierten Canary müssen Sie jedoch keine Konfigurationen angeben, die die Traffic-Aufteilung definieren. Das übernimmt Cloud Deploy für Sie. Sie müssen jedoch die Skaffold-Profile angeben, die für jede Phase verwendet werden sollen.

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

Sie können zwar eine Cloud Deploy-Kanarienbereitstellung verwenden, um Ihre Anwendung in einem dienstbasierten Kubernetes-Netzwerk bereitzustellen, aber es gibt auch die Möglichkeit, das Kubernetes-Service-Mesh der Gateway API zu verwenden. In diesem Abschnitt wird beschrieben, wie Sie das tun.

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

  1. Richten Sie Ihre Gateway API-Ressourcen ein:

    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:

    • Eine HTTPRoute, die auf Ihre Gateway-Ressource verweist

    • Eine Bereitstellung

    • Ein Dienst

  3. Konfigurieren Sie die Bereitstellungspipeline und das Ziel, für das Sie einen Canary-Release bereitstellen möchten:

    • Die Konfiguration für das Ziel ist mit der für jedes andere Ziel identisch.

    • Die Bereitstellungspipelinekonfiguration enthält in der Fortschrittssequenz für das jeweilige Ziel einen gatewayServiceMesh-Abschnitt, der auf die HTTPRoute-Konfiguration der Kubernetes Gateway API sowie auf die Bereitstellung und den Dienst verweist.

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

      Wobei:

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

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

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

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

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

      • LABEL ist ein Pod-Selektor-Label. Sie muss mit der Labelauswahl im Kubernetes-Dienst und der Bereitstellung übereinstimmen, die in Ihrem Manifest definiert sind. Dies ist optional. Der Standardwert ist app.

Parallele Bereitstellung mit einer Canary-Bereitstellungsstrategie verwenden

Sie können eine Canary-Bereitstellung mithilfe einer parallelen Bereitstellung ausführen. Das bedeutet, dass das Ziel, auf das Sie nach und nach umstellen, aus zwei oder mehr untergeordneten Zielen bestehen kann. Sie können beispielsweise gleichzeitig in Clustern in verschiedenen Regionen nach und nach einrichten.

Wie unterscheidet sich ein paralleler Canary von einem Canary mit einzelnem Ziel

  • Wie bei der Canary-Bereitstellung mit nur einem Ziel benötigen Sie bei der Bereitstellung auf GKE-Ziele eine Kubernetes-Bereitstellungskonfiguration und eine Kubernetes-Dienstkonfiguration in Ihrem Manifest.

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

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

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

    Sowohl für die Kontrollgruppe als auch für die untergeordnete Gruppe gibt es separate Phasen für alle konfigurierten Canary-Prozentsätze und eine stable-Phase für den Canary mit 100%.

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

    Sie können nur Controller-Roll-outs fortsetzen. Wenn Sie das Controller-Roll-out in die nächste Phase verschieben, werden die untergeordneten Roll-outs von Cloud Deploy ebenfalls fortgesetzt.

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

    Sie können einen Job nur in untergeordneten Roll-outs noch einmal versuchen.

  • 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, aber keine untergeordneten Roll-outs.

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

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

Wenn ein untergeordnetes Roll-out fehlschlägt, kann das Controller-Roll-out in einen anderen Status übergehen, je nachdem, was mit den untergeordneten Roll-outs passiert:

  • Wenn ein oder mehrere untergeordnete Roll-outs fehlschlagen, aber mindestens ein untergeordnetes Roll-out weiterhin 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, ist der Status des Controller-Roll-outs HALTED, wenn nach der aktuellen Phase weitere Phasen folgen.

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

    Mit HALTED können Sie fehlgeschlagene Jobs im fehlgeschlagenen untergeordneten Roll-out entweder ignorieren oder erneut ausführen. Sie können auch das Controller-Roll-out abbrechen und weitere Aktionen für die untergeordneten Roll-outs verhindern.

  • Wenn das Controller-Roll-out aufgrund eines fehlgeschlagenen untergeordneten Roll-outs den Status HALTED hat und Sie den fehlgeschlagenen Job im untergeordneten Roll-out ignorieren, kehrt das Controller-Roll-out zum Status IN_PROGRESS zurück.

HTTPRoute in einem anderen Cluster bereitstellen

Wenn Sie einen Canary mit der Gateway API-Service Mesh-Konfiguration haben, können Sie einen alternativen Cluster angeben, in dem die HTTPRoute bereitgestellt werden soll.

Dazu verwenden Sie in der Konfiguration Ihrer Canary-Strategie einen routeDestinations-Abschnitt, um den Zielcluster oder die Zielcluster für die HTTPRoute anzugeben, und eine boolesche Einstellung, um den Dienst an denselben Cluster zu übertragen, der kein Zielcluster ist. Sie erstellen außerdem einen associatedEntities-Abschnitt in Ihrer Zielkonfiguration, um die Cluster zu identifizieren.

  1. Konfigurieren Sie associatedEntities für Ihr Ziel.

    Jede Entität ist ein Cluster, in dem Cloud Deploy die HTTP-Route und optional den Kubernetes-Dienst bereitstellt. Fügen Sie in Ihrer Zieldefinition einen associatedEntities-Abschnitt ein:

    associatedEntities:
  [KEY]:
    gkeClusters:
    - cluster: [PATH]
      internalIp: [true|false]
      proxyUrl:

    Wobei:

    • KEY ist ein beliebiger Name für diese Gruppe verknüpfter Entitäten. Mit diesem Namen wird in der Canary-Konfiguration auf die Entitäten aus der routeDestinations verwiesen.

    • PATH ist der Ressourcenpfad, der den GKE-Cluster angibt, in dem Ihre HTTPRoute (und optional der Dienst) bereitgestellt wird.

    • Mit internalIp wird angegeben, ob die interne IP-Adresse (private IP-Adresse) verwendet werden soll, wenn für den Cluster sowohl eine interne als auch eine öffentliche IP-Adresse konfiguriert ist. Der Standardwert ist false.

    Sie können eine beliebige Anzahl von Clustern mit oder ohne internalIp angeben.

  2. Konfigurieren Sie routeDestinations in Ihrer Canary-Konfiguration.

    Jedes Routenziel verweist auf einen associatedEntities-Abschnitt und gibt an, ob der Dienst auch im alternativen Cluster bereitgestellt werden soll. Fügen Sie in der Canary-Konfiguration in der gatewayServiceMesh-Stanza Folgendes hinzu:

    routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]

    Wobei:

    • KEY ist der Name, den Sie in associatedEntities im Ziel konfiguriert haben. Verwenden Sie diesen Namen, um in Ihrer Canary-Konfiguration auf die Entitäten aus dem routeDestinations zu verweisen.

      Sie können auch den Wert @self angeben, um die HTTPRoute zusätzlich zum zugehörigen Ziel im Zielcluster bereitzustellen.

    • Mit propagateService wird angegeben, ob der Dienst zusätzlich zur HTTPRoute im zugehörigen Cluster bereitgestellt werden soll. Der Standardwert ist false.

Konfigurierten Canary ausführen

So führen Sie das Canary-Deployment aus:

  1. Registrieren Sie die konfigurierte Bereitstellungspipeline und die Ziele.

    gcloud deploy apply --file=PIPELINE

    Die Bereitstellungspipeline enthält die automatische 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. Falls nicht, müssen Sie Ihre Ziele auch registrieren.

  2. So erstellst du einen Release:

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

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

  3. Canary-Version aktualisieren:

    gcloud-CLI 

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

    Wobei:

    ROLLOUT_NAME ist der Name der aktuellen Einführung, die Sie in die nächste Phase übergehen.

    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 Version 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 Details zum Roll-out wird angezeigt.

      Details zur Einführung in der Google Cloud Console

      In diesem Beispiel hat das Roll-out eine canary-50-Phase und eine stable-Phase. Ihr Roll-out kann mehr oder andere Phasen haben.

    4. Klicken Sie auf Roll-out fortsetzen.

      Das Roll-out wird in die nächste Phase fortgesetzt.

Übersprungene Phasen

Wenn Sie einen Canary-Release bereitstellen und Ihre Anwendung noch nicht für diese Laufzeit bereitgestellt wurde, überspringt Cloud Deploy die Canary-Phase und führt die stabile Phase aus. Weitere Informationen finden Sie unter Phasen beim ersten Mal überspringen.

Nächste Schritte