Canary-Bereitstellungen in GKE und GKE Enterprise mit dienstbasiertem Netzwerk

In diesem Dokument wird beschrieben, wie Sie Canary-Bereitstellungen konfigurieren und verwenden, um Ihre Anwendungen mit Cloud Deploy und dienstbasiertem Networking in GKE oder GKE Enterprise bereitzustellen.

Ein Canary-Deployment ist eine schrittweise Einführung einer neuen Version Ihrer Anwendung. Dabei wird der Prozentsatz des Traffics, der an die neue Version gesendet wird, nach und nach erhöht, während die Leistung der Anwendung überwacht wird. So können Sie potenzielle Probleme frühzeitig erkennen und die Auswirkungen auf Ihre Nutzer minimieren.

Funktionsweise von Canary-Bereitstellungen für GKE und GKE Enterprise mit dienstbasiertem Netzwerk

1. Sie geben den Namen der Deployment-Ressource und der Service-Ressource an.

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

Secrets und ConfigMaps werden ebenfalls kopiert und mit -canary umbenannt.

1. 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 Berechnung im Abschnitt zur Pod-Bereitstellung. Die Berechnung hängt davon ab, ob Sie Pod-Overprovisioning aktivieren oder deaktivieren.

   Wenn wir zur Phase stable springen, fügt Cloud Deploy die Labels hinzu, die zum Abgleichen von Pods verwendet werden. Sie sind also für nachfolgende Canary-Ausführungen verfügbar.

   Cloud Deploy erstellt ein Deployment mit dem phasenspezifischen Prozentsatz von Pods und aktualisiert es für jede Phase. Dazu wird die Anzahl der Pods als Prozentsatz der ursprünglichen Anzahl von Pods berechnet. Dies kann zu einer ungenauen Aufteilung des Traffics führen. Wenn Sie eine genaue Traffic-Aufteilung benötigen, können Sie das mit der Gateway API erreichen.

2. In der stable-Phase wird die -canary-Bereitstellung auf null skaliert und die ursprüngliche Bereitstellung durch die neue Bereitstellung ersetzt.

   Cloud Deploy ändert die ursprüngliche Bereitstellung erst in der Phase stable, sofern Sie die Überbereitstellung nicht deaktivieren.

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

Für GKE-Netzwerk-Canary können Sie Pod-Überbereitstellung 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 müssen.

Pod-Bereitstellung mit aktivierter Überdimensionierung

Wenn Sie die Überbereitstellung aktivieren (disablePodOverprovisioning: false), kann Cloud Deploy genügend zusätzliche Pods erstellen, um den gewünschten Prozentsatz für Canary-Bereitstellungen auszuführen. Die Anzahl der Pods basiert auf der Anzahl der Pods, die für die vorhandene Bereitstellung ausgeführt werden. Die folgende Formel zeigt, wie Cloud Deploy die Anzahl der Pods berechnet, die für die Canary-Bereitstellung für jede Canary-Phase bereitgestellt werden sollen, wenn die Überbereitstellung von Pods aktiviert ist:

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

Mit dieser Formel wird die aktuelle Anzahl der Replikate (die Anzahl der Pods, die Sie bereits vor diesem Canary-Release haben) mit dem Canary-Prozentsatz für die Phase multipliziert und das Ergebnis durch (100 minus dem 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, behandelt als .50.

Die Pod-Überdimensionierung ist das Standardverhalten.

Pod-Bereitstellung mit deaktivierter Überdimensionierung

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

Die folgende Formel zeigt, wie Cloud Deploy die Bereitstellung von Pods für die Canary-Bereitstellung für jede Canary-Phase berechnet, wenn die Überbereitstellung von Pods 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 kein ReplicaCountOfCanaryDeploymentOnCluster.

Wenn Sie mit 4 Pods beginnen, wird diese Zahl mit dem Canary-Prozentsatz (z. B. 50 % oder .5) multipliziert, um 2 zu erhalten. Das ursprüngliche Deployment wird also auf 2 Instanzen herunterskaliert und für das Canary-Deployment werden 2 neue Pods erstellt. Wenn Sie dann eine 75‑%‑Canary-Phase haben, haben Sie 2 (ursprüngliche Bereitstellung) +2 (erste Canary-Phase), *.75, um 3 Canary-Pods und 1 Pods zu erhalten, auf denen die ursprüngliche Bereitstellung ausgeführt wird.

Mit Cloud Deploy können Sie Canary-Deployments für GKE und GKE Enterprise in einer oder mehreren Phasen konfigurieren.

Die Anleitung hier enthält nur die für die Canary-Konfiguration spezifischen Informationen. Das Dokument In einem Google Kubernetes Engine-Cluster bereitstellen enthält die allgemeine Anleitung zum Konfigurieren und Ausführen Ihrer Bereitstellungspipeline.

Prüfen, ob Sie die erforderlichen Berechtigungen haben

Zusätzlich zu anderen Identity and Access Management-Berechtigungen, die Sie für die Verwendung von Cloud Deploy benötigen, sind die folgenden Berechtigungen erforderlich, um zusätzliche Aktionen auszuführen, die möglicherweise für eine Canary-Bereitstellung erforderlich sind:

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

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

skaffold.yaml vorbereiten

In der Datei skaffold.yaml wird definiert, wie Ihre Kubernetes-Manifeste gerendert und bereitgestellt werden. Achten Sie bei einem Canary-Deployment in GKE/GKE Enterprise darauf, dass es korrekt auf Ihre Manifeste verweist und alle erforderlichen Build-Artefakte definiert. In skaffold.yaml ist keine spezielle Canary-Konfiguration erforderlich, die über die für ein Standard-Deployment erforderliche Konfiguration hinausgeht. Sie können Skaffold-Profile verwenden, um verschiedene Manifestvarianten für benutzerdefinierte Canary-Phasen zu verwalten.

Kubernetes-Manifeste vorbereiten

Ihre Kubernetes-Manifeste müssen sowohl eine Deployment- als auch eine Service-Ressource enthalten. Im Service muss ein selector definiert sein, der mit den Labels der von Deployment verwalteten Pods übereinstimmt. Das Standardlabel, nach dem Cloud Deploy sucht, ist app. Dies kann jedoch in der Pipeline konfiguriert werden.

Automatisierte Canary-Analyse konfigurieren

Sie können ein automatisiertes Canary direkt in der Definition Ihrer Bereitstellungspipeline für eine bestimmte GKE- oder GKE Enterprise-Phase mit dem standardmäßigen Kubernetes-Dienstnetzwerk konfigurieren.

Fügen Sie in der Pipelinephase eine strategy-Property 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, der in Ihrem Manifest definiert ist.

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

• LABEL ist ein Pod-Selektorlabel. Dieser muss mit dem Label-Selektor 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 Ihre Canary-Inkremente darstellen, z. B. [5, 25, 50].

  100 ist ebenfalls nicht enthalten, da im Canary-Release eine Bereitstellung von 100% angenommen wird. Dies wird in der Phase stable behandelt.

• 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, den Sie in Ihrem 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.

Benutzerdefiniertes Canary konfigurieren

Sie können Ihr Canary manuell konfigurieren, anstatt sich vollständig auf die von Cloud Deploy bereitgestellte Automatisierung zu verlassen. Mit der benutzerdefinierten Canary-Konfiguration geben Sie in der Definition Ihrer Bereitstellungspipeline Folgendes an:

• Namen der Roll-out-Phasen

  Bei einem vollständig automatisierten Canary-Release benennt Cloud Deploy die Phasen für Sie (z. B. canary-25, canary-75, stable). Bei einem benutzerdefinierten Canary können Sie jeder Phase einen beliebigen Namen geben, sofern er unter allen Phasen für diese Canary-Phase eindeutig ist und die Einschränkungen für Ressourcen-IDs eingehalten werden. Der Name der letzten Phase (100%) muss 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 verwenden oder dasselbe Profil oder eine beliebige Kombination. Für jedes Profil kann ein anderes Kubernetes-Manifest verwendet werden. Sie können für eine bestimmte Phase auch mehrere Profile verwenden. Cloud Deploy kombiniert sie.

• Ob es einen Prüfjob für die Phase gibt

  Wenn Sie die Überprüfung aktivieren, müssen Sie auch Ihre skaffold.yaml konfigurieren.

• Ob es Pre-Deploy- oder Post-Deploy-Jobs für die Phase gibt

  Wenn Sie Pre-Deploy- oder Post-Deploy-Jobs aktivieren, müssen Sie Ihre skaffold.yaml für diese Jobs konfigurieren.

Alle Zieltypen werden für benutzerdefinierte Canary-Tests unterstützt.

Benutzerdefinierte Elemente der Canary-Konfiguration

Das folgende YAML zeigt die Konfiguration für die Phasen des vollständig benutzerdefinierten Canary-Deployments:

strategy:
  canary:
    # Custom configuration for each canary phase
    customCanaryDeployment:
      phaseConfigs:
      - phaseId: "PHASE1_NAME"
        percentage: PERCENTAGE1
        profiles: [ "PROFILE_NAME" ]
        verify: true | false
        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

• PHASE1_NAME

  Ist der Name der Phase. Jeder Phasenname muss eindeutig sein.

• [ "PROFILE_NAME" ]

  Ist der Name des Profils, das für die Phase verwendet werden soll. Sie können für jede Phase dasselbe Profil oder für jede Phase ein anderes Profil verwenden 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 Prozentwert haben, der eine ganze Zahl sein muss (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 einbeziehen soll. Für jede Phase, in der „verify“ verwendet werden soll, verwendet Skaffold dasselbe Profil für „verify“, das für „render“ und „deploy“ für diese Phase angegeben ist.

• PREDEPLOY_ACTION

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

• POSTDEPLOY_ACTION

  Entspricht dem ACTION_NAME, das 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 sein. Phasen werden in der Reihenfolge ausgeführt, in der Sie sie in diesem customCanaryDeployment-Abschnitt konfigurieren. Wenn die Prozentwerte jedoch nicht in aufsteigender Reihenfolge sind, schlägt der Befehl zum Registrieren der Bereitstellungspipeline mit einem Fehler fehl.

Die Konfiguration für einen benutzerdefinierten Canary-Release enthält keinen runtimeConfig-Abschnitt. Wenn Sie runtimeConfig angeben, wird das als Canary-Version auf Grundlage eines benutzerdefinierten Dienstes betrachtet.

Benutzerdefinierte automatisierte Canary-Analyse konfigurieren

Dabei wird die benutzerdefinierte Phasendefinition (Namen, Prozentsätze, Profile, Überprüfung, Hooks) mit der automatischen Traffic-Verwaltung von Cloud Deploy für GKE oder GKE Enterprise kombiniert. Sie definieren die Phasen, aber Cloud Deploy übernimmt die zugrunde liegende Ressourcenbearbeitung basierend auf den Prozentangaben und dem ausgewählten runtimeConfig.

Konfigurieren Sie dazu sowohl einen runtimeConfig-Abschnitt mit serviceNetworking als auch den customCanaryDeployment-Abschnitt (in dem phaseConfigs definiert werden) im Block „strategy.canary“. Cloud Deploy verwendet die angegebenen Skaffold-Profile für das Rendering, passt den Traffic aber automatisch an die runtimeConfig- und Phasenprozentsätze an.

serialPipeline:
  stages:
  - targetId: gke-prod
    profiles: []
    strategy:
      canary:
        # Include runtimeConfig for automatic traffic management
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: "my-app"
              deployment: "my-deployment"
        # Include customCanaryDeployment for phase customization
        customCanaryDeployment:
          phaseConfigs:
          - phaseId: "warmup"
            percentage: 10
            profiles: ["profile-a"] # Profile used for rendering this phase
            verify: true
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify: true
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify: true

GKE- oder GKE Enterprise-Canary ausführen

1. Pipeline und Ziele registrieren: Wenden Sie Ihre Lieferpipeline und die GKE- oder GKE Enterprise-Zielkonfigurationsdateien an.

   
   gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
   gcloud deploy apply --file=gke-targets.yaml --region=REGION
   

   Die Bereitstellungspipeline umfasst die automatische oder benutzerdefinierte Canary-Konfiguration für die ausgewählte Laufzeit.

2. Release erstellen: Starten Sie das Deployment und geben Sie den Image-Namen an.

   
   gcloud deploy releases create RELEASE_NAME \
                                   --delivery-pipeline=PIPELINE_NAME \
                                   --region=REGION
     # e.g., --images=my-cloudrun-service=gcr.io/my-project/my-app:v1.1
     # Add --skaffold-file or --source if not using default Skaffold config discovery
   

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

3. Canary-Phase 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, den Sie in die nächste Phase verschieben.

   RELEASE_NAME ist der Name des Releases, zu dem dieses Rollout 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 gcloud deploy rollouts advance-Befehl 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 Detailseite 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 des Roll-outs.

      Die Seite mit den Rollout-Details für diesen Rollout wird angezeigt.

      

      In diesem Beispiel hat die Einführung 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 der nächsten Phase fortgesetzt.

Übersprungene Phasen

Wenn Sie ein Canary-Deployment durchführen 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

• Kurzanleitung für Canary-Bereitstellung

• Informationen zum Verwalten des Lebenszyklus von Canary-Roll-outs

• Weitere Informationen zur parallelen Bereitstellung

• Weitere Informationen zu Cloud Deploy-Bereitstellungsstrategien