Diese Seite wurde von der Cloud Translation API übersetzt.

Canary-Bereitstellungen in GKE- und GKE-angehängten Clustern 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 angehängten GKE-Clustern 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-angehängte Cluster mit dienstbasiertem Netzwerk

Sie geben den Namen der Deployment-Ressource und der Service-Ressource an.
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.

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.
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 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 Repliken skaliert 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-Bereitstellungen für GKE- und angehängte GKE-Cluster 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.

Sie müssen 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

Ihre skaffold.yaml-Datei definiert, wie Ihre Kubernetes-Manifeste gerendert und bereitgestellt werden. Achten Sie bei einer Canary-Bereitstellung in GKE oder in GKE angehängten Clustern darauf, dass sie 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-Release direkt in der Definition Ihrer Bereitstellungspipeline für eine bestimmte Phase in GKE- oder angehängten GKE-Clustern mit dem Standard-Kubernetes-Dienstnetzwerk konfigurieren.

Fügen Sie in der Pipelinephase das Attribut strategy 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. Er 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 nicht enthalten, da im Canary-Release eine Bereitstellung von 100% angenommen wird. Dies wird in der Phase stable verarbeitet.
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.

Benutzerdefinierte automatisierte Canary-Analyse konfigurieren

Ein benutzerdefiniertes automatisiertes Canary kombiniert eine benutzerdefinierte Phasendefinition (Namen, Prozentsätze, Profile, Verify, Hooks) mit der automatischen Traffic-Verwaltung von Cloud Deploy für GKE- oder GKE-angehängte Cluster. Sie definieren die Phasen, aber Cloud Deploy übernimmt die zugrunde liegende Ressourcenbearbeitung basierend auf den Prozentzahlen und dem ausgewählten runtimeConfig.

Wenn Sie eine benutzerdefinierte automatisierte Canary-Analyse konfigurieren möchten, müssen Sie sowohl einen runtimeConfig-Abschnitt mit serviceNetworking als auch den customCanaryDeployment-Abschnitt (mit der Definition von phaseConfigs) im Block „strategy.canary“ angeben. Cloud Deploy verwendet die angegebenen Skaffold-Profile für das Rendern, passt den Traffic jedoch 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

Canary-Test für GKE- oder angehängte GKE-Cluster ausführen

Pipeline und Ziele registrieren: Wenden Sie Ihre Bereitstellungspipeline und die Konfigurationsdateien für GKE- oder GKE-angehängte Cluster 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.

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.

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 Rollouts unter Details zur Bereitstellungspipeline auf den Namen des Rollouts.
  
  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 in dieser 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.