Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Canary-Bereitstellungen in GKE- und angehängten GKE-Clustern mit Gateway API-Netzwerk

In diesem Dokument wird beschrieben, wie Sie Canary-Deployments konfigurieren und verwenden, um Ihre Anwendungen mit Cloud Deploy und Kubernetes Gateway API Service Meshin GKE- oder angehängten GKE-Clustern bereitzustellen.

Ein Canary-Deployment ist ein schrittweiser Roll-out einer neuen Version Ihrer Anwendung. Dabei erhöhen Sie schrittweise den Prozentsatz des Traffics, der an die neue Version gesendet wird, und beobachten gleichzeitig die Leistung der Anwendung. So können Sie potenzielle Probleme frühzeitig erkennen und die Auswirkungen auf Ihre Nutzer minimieren.

Funktionsweise von Canary-Deployments für GKE- und angehängte GKE-Cluster mit der Gateway API

Neben den Deployment- und Service-Referenzen geben Sie eine HTTPRoute-Ressource mit einer backendRefs-Regel an, die auf den Service verweist.
Cloud Deploy erstellt ein neues Deployment mit dem Namen Ihres ursprünglichen Deployments plus -canary und einen neuen Service mit dem ursprünglichen Servicenamen plus -canary.

Secrets, ConfigMaps und horizontale Pod-Autoscaler werden ebenfalls kopiert und mit -canary umbenannt.
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 Eigenschaft routeUpdateWaitTime in Ihre Konfiguration aufnehmen, damit das System eine bestimmte Zeit auf diese Weitergabe wartet.
In der Phase stable wird das Deployment -canary auf null skaliert und das ursprüngliche Deployment wird aktualisiert, um das Deployment des neuen Release zu verwenden.

Außerdem wird die HTTPRoute jetzt auf die ursprüngliche zurückgesetzt, die Sie angegeben haben.

Cloud Deploy ändert das ursprüngliche Deployment oder den ursprünglichen Service erst in der Phase stable.

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

Die Anleitung hier enthält nur Informationen, die speziell für die Canary-Konfiguration gelten. Im Dokument Bereitstellung in einem Google Kubernetes Engine-Cluster finden Sie die allgemeine Anleitung zum Konfigurieren und Ausführen Ihrer Bereitstellungspipeline.

Sie müssen die erforderlichen Berechtigungen haben.

Zusätzlich zu 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 ein Canary-Deployment 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 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. Für ein Canary-Deployment in GKE- oder angehängten GKE-Clustern muss die Datei skaffold.yaml korrekt auf Ihre Manifeste verweisen und alle erforderlichen Build-Artefakte definieren. Über das, was für ein Standard-Deployment erforderlich ist, hinaus ist in skaffold.yaml keine spezielle Canary-Konfiguration erforderlich. Sie können auch Skaffold-Profile verwenden, um verschiedene Manifestvarianten für benutzerdefinierte Canary-Phasenzu verwalten.

Kubernetes-Manifeste vorbereiten

Ihre Kubernetes-Manifeste müssen sowohl eine Deployment- als auch eine Service-Ressource enthalten. Der Service muss einen selector definieren, der mit den Labels der Pods übereinstimmt, die vom Deployment verwaltet werden. Das Standardlabel, nach dem Cloud Deploy sucht, ist app. Dies kann jedoch in der Pipeline konfiguriert werden.

Neben Deployment und Service müssen Ihre Manifeste eine HTTPRoute-Ressource enthalten, die für die Traffic-Aufteilung konfiguriert ist und auf den Service und das zugehörige Gateway verweist.

Automatisierte Canary-Bereitstellung konfigurieren

Verwenden Sie die Kubernetes Gateway API (mit Istio oder einer unterstützten Implementierung) für eine präzise, prozentuale Traffic-Aufteilung, die vom Mesh/Gateway verwaltet und von Cloud Deploy orchestriert wird.

Gateway API-Ressourcen einrichten: Prüfen Sie, ob Ihr Gateway und das zugrunde liegende Service Mesh (z.B. Istio) oder der Gateway-Controller in Ihren Clustern richtig konfiguriert sind.
- Istio verwenden
- GKE Gateway Controller
Fügen Sie in das Kubernetes-Manifest, das Cloud Deploy beim Erstellen des Release bereitgestellt wurde, Folgendes ein:
- Eine HTTPRoute die auf Ihre Gateway-Ressource verweist
- Ein Deployment
- Ein Service
Konfigurieren Sie Ihre Lieferpipeline und das Ziel, für das Sie ein Canary-Deployment durchführen möchten:
- Die Konfiguration für das Ziel ist dieselbe wie für jedes andere Ziel.
- Die Konfiguration der Lieferpipeline enthält in der Abfolge für das jeweilige Ziel einen gatewayServiceMesh-Abschnitt, der auf Ihre HTTPRoute-Konfiguration der Kubernetes Gateway API sowie auf Ihr Deployment und Ihren Service verweist.
```
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 gewünschte Routing Verhalten definiert.
  - SERVICE ist Ihre Dienstkonfiguration, die Cloud Deploy für Canary-Deployments in GKE- und angehängten GKE-Clustern benötigt.
  - DEPLOYMENT ist Ihre Deployment-Konfiguration, die Cloud Deploy für Canary-Deployments in GKE- und angehängten GKE-Clustern benötigt.
  - WAIT_TIME ist ein Zeitraum, in dem Cloud Deploy auf die Weitergabe von Änderungen an der HTTPRoute Ressource wartet, um verworfene Anfragen zu vermeiden. Beispiel: routeUpdateWaitTime: 60s.
    
    Wenn Sie Canary mit der Gateway API ohne Istio ausführen und die Gateway API mit einem Google Cloud Load-Balancer verbunden ist, kann ein kleiner Teil des Traffics verloren gehen, wenn die Canary-Instanz herunterskaliert wird. Sie können diese Einstellung konfigurieren, wenn Sie dieses Verhalten beobachten.
  - LABEL ist ein Pod-Selektorlabel. Es muss mit dem Label-Selektor im Kubernetes-Service und -Deployment übereinstimmen, der in Ihrem Manifest definiert ist. Dies ist optional. Der Standardwert ist app.

Benutzerdefinierte automatisierte Canary-Bereitstellung konfigurieren

Eine benutzerdefinierte automatisierte Canary-Bereitstellung kombiniert die benutzerdefinierte Phasenkonfiguration (Namen, Prozentsätze, Profile, Überprüfung, Hooks) mit der automatischen Traffic-Verwaltung von Cloud Deploy für GKE- oder angehängte GKE-Cluster. Sie definieren die Phasen, aber Cloud Deploy übernimmt die zugrunde liegende Ressourcenmanipulation basierend auf den Prozentsätzen und der ausgewählten runtimeConfig.

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

serialPipeline:
  stages:
  - targetId: gke-prod
    profiles: []
    strategy:
      canary:
        # Include runtimeConfig for automatic traffic management
        runtimeConfig:
          kubernetes:
            gatewayServiceMesh:
              httpRoute: "my-route"
              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:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []
          - phaseId: "scaling"
            percentage: 50
            profiles: ["profile-b"] # Different profile for this phase
            verify:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []
          - phaseId: "stable"
            percentage: 100
            profiles: ["profile-b"] # Can reuse profiles
            verify:
              tasks: []
            predeploy:
              tasks: []
            postdeploy:
              tasks: []

HTTPRoute in einem anderen Cluster bereitstellen

Wenn Sie ein Canary-Deployment mit Gateway API Service Mesh konfiguriert haben, können Sie einen alternativen Cluster angeben, der nicht das Ziel ist, in dem die HTTPRoute bereitgestellt werden soll.

Verwenden Sie dazu in der Konfiguration Ihrer Canary-Strategie einen routeDestinations-Abschnitt, um den oder die Zielcluster für die HTTPRoute anzugeben, und eine boolesche Einstellung, um den Service an denselben Cluster weiterzugeben, der nicht das Ziel ist. Erstellen Sie außerdem in Ihrer Zielkonfiguration einen associatedEntities-Abschnitt, um die Cluster zu identifizieren.

associatedEntities für Ihr Ziel konfigurieren

Jede Entität ist ein Cluster, in dem Cloud Deploy die HTTPRoute und optional den Kubernetes-Service bereitstellt. Fügen Sie in Ihre Zieldefinition einen associatedEntities-Abschnitt ein:
```
associatedEntities:
  [KEY]:
    gkeClusters:
    - cluster: [PATH]
      dnsEndpoint: [true|false]
      internalIp: [true|false]
      proxyUrl:
```
Wobei:
- KEY ist ein beliebiger Name für diese Gruppe verknüpfter Entitäten. Mit diesem Namen verweisen Sie in Ihrer Canary-Konfiguration von routeDestinations auf die Entitäten.
- PATH ist der Ressourcenpfad, der den GKE-Cluster identifiziert, in dem Ihre HTTPRoute (und optional der Service) bereitgestellt wird.
- dnsEndpoint gibt an, ob der DNS-Endpunkt des Clusters verwendet werden soll, wenn mehrere Endpunkte konfiguriert sind. Der Standardwert ist false.
- internalIp gibt an, ob die interne IP-Adresse (private IP) des Clusters verwendet werden soll, wenn mehrere Endpunkte konfiguriert sind. Der Standardwert ist false.
Sie können beliebig viele Cluster mit oder ohne internalIp einbeziehen.
routeDestinations in Ihrer Canary-Konfiguration konfigurieren

Jedes Routenziel verweist auf einen associatedEntities-Abschnitt und gibt an, ob der Service auch im alternativen Cluster bereitgestellt werden soll. Fügen Sie in Ihrer Canary-Konfiguration Folgendes in den gatewayServiceMesh-Abschnitt ein:
```
routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]
```
Wobei:
- KEY ist der Name, den Sie im Ziel in associatedEntities konfiguriert haben. Mit diesem Namen verweisen Sie in Ihrer Canary-Konfiguration von routeDestinations auf die Entitäten.
  
  Sie können auch den Wert @self angeben, um die HTTPRoute zusätzlich zum verknüpften Ziel im Zielcluster bereitzustellen.
- propagateService gibt an, ob Sie den Service zusätzlich zur HTTPRoute im verknüpften Cluster bereitstellen möchten. Der Standardwert ist false.

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

Pipeline und Ziele registrieren: Wenden Sie Ihre Konfigurationsdateien für die Lieferpipeline und das Ziel für GKE- oder angehängte GKE-Cluster an.
```
gcloud deploy apply --file=delivery-pipeline.yaml --region=REGION
gcloud deploy apply --file=gke-targets.yaml --region=REGION
```
Die Lieferpipeline enthält die automatisierte oder benutzerdefinierte Canary-Konfiguration für die von Ihnen ausgewählte Laufzeit.

Release erstellen: Starten Sie die Bereitstellung und geben Sie den Bildnamen 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 Lieferpipeline enthält die in diesem Dokument beschriebene automatisierte oder benutzerdefinierte Canary-Konfiguration.

Canary-Deployment 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 zur nächsten Phase fortsetzen.

RELEASE_NAME ist der Name des Release, zu dem dieser 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 das 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 Liefer pipelines.
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 der Lieferpipeline auf den Namen Ihres Roll-outs.
  
  Die Roll-out-Detailseite wird für diesen Roll-out angezeigt.
  
  In diesem Beispiel hat der Roll-out eine canary-50- und eine stable-Phase. Ihr Roll-out kann mehr oder andere Phasen haben.
4. Klicken Sie auf Roll-out fortsetzen.
  
  Der Roll-out wird zur 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. Unter Phasen beim ersten Mal überspringen erfahren Sie, warum das passiert.

Nächste Schritte

Kurzanleitung für Canary-Deployments
Erfahren Sie, wie Sie den Lebenszyklus der Rollouts Ihres Canarys verwalten.
Erfahren Sie mehr über die parallele Bereitstellung.
Erfahren Sie mehr über Bereitstellungsstrategien von Cloud Deploy.