Diese Seite wurde von der Cloud Translation API übersetzt.

Canary-Bereitstellungen in GKE und GKE Enterprise mit Gateway API-Netzwerken

In diesem Dokument wird beschrieben, wie Sie Canary-Bereitstellungen konfigurieren und verwenden, um Ihre Anwendungen mit Cloud Deploy in GKE oder GKE Enterprise mit dem Gateway API-Service-Mesh von Kubernetes 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 der Gateway API

Zusätzlich zu den Deployment- und Service-Referenzen stellen Sie eine HTTPRoute-Ressource mit einer backendRefs-Regel bereit, die auf den Service verweist.
Cloud Deploy erstellt ein neues Deployment mit dem Namen Ihres ursprünglichen Deployments plus -canary und einen neuen Dienst mit dem ursprünglichen Dienstnamen plus -canary.

Secrets, ConfigMaps und horizontale Pod-Autoscalings werden ebenfalls kopiert und mit -canary umbenannt.
In jeder 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 Übertragung von Änderungen an HTTPRoute-Ressourcen kommen kann, können Sie die Property routeUpdateWaitTime in Ihre Konfiguration aufnehmen, damit das System eine bestimmte Zeit auf diese Übertragung wartet.
Während der stable-Phase wird das -canary-Deployment auf null skaliert und das ursprüngliche Deployment wird aktualisiert, um das Deployment der neuen Version zu verwenden.

Außerdem wurde die HTTPRoute 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.

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 allgemeinen Anleitungen 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.

Zusätzlich zu Deployment und Service müssen Ihre Manifeste eine HTTPRoute-Ressource enthalten, die für die Aufteilung des Traffics konfiguriert ist und auf Service und das zugehörige Gateway verweist.

Automatisierte Canary-Analyse konfigurieren

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

Gateway API-Ressourcen einrichten: Achten Sie darauf, dass Ihr Gateway und das zugrunde liegende Service Mesh (z.B. Istio) oder Gateway-Controller in Ihren Clustern richtig konfiguriert sind.
- Istio verwenden
- GKE Gateway Controller
Fügen Sie in Ihr Kubernetes-Manifest, das Cloud Deploy beim Erstellen des Releases bereitgestellt wurde, Folgendes ein:
- Eine HTTPRoute, die auf Ihre Gateway-Ressource verweist
- Deployment
- Ein Dienst
Konfigurieren Sie Ihre Bereitstellungspipeline und das Ziel, für das Sie Canary-Bereitstellung verwenden möchten:
- Die Konfiguration für das Ziel ist dieselbe wie für jedes andere Ziel.
- Die Konfiguration der Bereitstellungspipeline enthält in der Fortschrittssequenz für das jeweilige Ziel einen gatewayServiceMesh-Abschnitt, in dem auf Ihre Kubernetes Gateway API-Konfiguration HTTPRoute sowie auf Ihre Bereitstellung und Ihren Dienst verwiesen wird.
```
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 Routingverhalten definiert.
  - SERVICE ist Ihre Dienstkonfiguration, die für Canary-Bereitstellungen in GKE und GKE Enterprise erforderlich ist.
  - DEPLOYMENT ist Ihre Bereitstellungskonfiguration, die Cloud Deploy für Canary-Bereitstellungen in GKE und GKE Enterprise benötigt.
  - WAIT_TIME ist ein Zeitraum, in dem Cloud Deploy darauf wartet, dass die Änderungen an der HTTPRoute-Ressource vollständig übertragen werden, um abgebrochene 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 geringer Teil des Traffics verloren gehen, wenn die Canary-Instanz skaliert wird. Sie können diese Einstellung konfigurieren, wenn Sie dieses Verhalten beobachten.
  - LABEL ist ein Pod-Selektorlabel. Er muss mit dem Label-Selektor im Kubernetes-Service und -Deployment übereinstimmen, die in Ihrem Manifest definiert sind. Dies ist optional. Der Standardwert ist app.

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-Test der Gateway API 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:
            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: 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

HTTPRoute in einem anderen Cluster bereitstellen

Wenn Sie einen Canary-Release 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.

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

Konfigurieren Sie associatedEntities für Ihr Ziel.

Jede Entität ist ein Cluster, in dem Cloud Deploy die HTTPRoute und optional den Kubernetes-Dienst 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 zugehöriger Einheiten. Mit diesem Namen verweisen Sie in Ihrer Canary-Konfiguration auf die Einheiten aus routeDestinations.
- PATH ist der Ressourcenpfad, der den GKE-Cluster identifiziert, in dem Ihre HTTPRoute (und optional der Dienst) 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 eine beliebige Anzahl von Clustern einfügen, mit oder ohne internalIp.
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 Ihrer Canary-Konfiguration Folgendes in die gatewayServiceMesh-Stanza ein:
```
routeDestinations:
  destinationIds: ["KEY"]
  propagateService: [true|false]
```
Wobei:
- KEY ist der Name, den Sie im Ziel in associatedEntities konfiguriert haben. Verwenden Sie diesen Namen, um in Ihrer Canary-Konfiguration auf die Einheiten aus routeDestinations zu verweisen.
  
  Sie können auch den Wert @self angeben, um die HTTPRoute zusätzlich zum zugehörigen Ziel im Zielcluster bereitzustellen.
- propagateService gibt an, ob Sie den Dienst zusätzlich zur HTTPRoute im zugehörigen Cluster bereitstellen möchten. Der Standardwert ist false.

GKE- oder GKE Enterprise-Canary ausführen

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.

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