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 progressiver Rollout einer Anwendung, bei dem der Traffic zwischen einer bereits bereitgestellten Version und einer neuen Version aufgeteilt wird. Die neue Version wird zuerst für eine Teilmenge von Nutzern bereitgestellt, bevor sie vollständig eingeführt wird.

Unterstützte Zieltypen

Canary-Deployment in Cloud Deploy unterstützt alle Zieltypen, einschließlich der folgenden:

Canary funktioniert auch mit mehreren Zielen.

Warum sollten Sie eine Canary-Deployment-Strategie verwenden?

Mit einem Canary-Deployment können Sie Ihre Anwendung teilweise veröffentlichen. So können Sie sicherstellen, 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, würden Sie die neue Version Ihrer Anwendung in einer begrenzten Anzahl von Pods bereitstellen. Die alte Version würde weiterhin ausgeführt, aber ein größerer Teil des Traffics würde an die neuen Pods gesendet.

Wenn Sie in Cloud Run bereitstellen, teilt Cloud Run den Traffic zwischen den alten und neuen Überarbeitungen entsprechend den von Ihnen konfigurierten Prozentzahlen auf.

Arten von Canary-Releases

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

  • Automatisiert

    Bei einer automatisierten Canary-Bereitstellung (für Service Networking, Gateway API oder Cloud Run) konfigurieren Sie Cloud Deploy mit einer Reihe von Prozentwerten, die eine progressive Bereitstellung darstellen. Cloud Deploy führt in Ihrem Namen zusätzliche Vorgänge aus, um die Trafficprozentsätze zwischen der alten und der neuen Version aufzuteilen.

  • Benutzerdefiniert automatisiert

    Für einen benutzerdefinierten automatisierten Canary (für Service Networking, Gateway API oder Cloud Run) können Sie Folgendes angeben:

    • Den Namen der Phase
    • Das prozentuale Ziel
    • Das Skaffold-Profil, das für die Phase verwendet werden soll
    • Gibt an, 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-Ausgleich angeben. Cloud Deploy erstellt die erforderlichen Ressourcen (für Service Networking, Gateway API oder Cloud Run).

  • Benutzerdefiniert

    Bei einem benutzerdefinierten Canary-Release konfigurieren Sie jede Canary-Phase separat. Dazu gehören:

    • Den Namen der Phase
    • Das prozentuale Ziel
    • Das Skaffold-Profil, das für die Phase verwendet werden soll
    • Gibt an, 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 stellen Sie außerdem die gesamte Konfiguration für den Traffic-Ausgleich bereit.

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

Phasen eines Canary-Deployments

Wenn Sie einen Release für eine Canary-Bereitstellung erstellen, wird das Roll-out mit einer Phase für jede Canary-Inkrementierung und einer finalen stable-Phase für 100 % erstellt.

Wenn Sie beispielsweise ein Canary-Release für 25%, 50 % und 75% konfigurieren, hat das Roll-out die folgenden Phasen:

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

Weitere Informationen zu Rollout-Phasen, Jobs und Jobläufen finden Sie unter Rollouts verwalten.

Paralleles Deployment mit einer Canary-Deployment-Strategie verwenden

Sie können ein Canary-Deployment mit paralleler Bereitstellung ausführen. Das bedeutet, dass das Ziel, auf das Sie die Bereitstellung schrittweise ausweiten, zwei oder mehr untergeordnete Ziele umfassen kann. Sie können beispielsweise gleichzeitig progressiv in Clustern in separaten Regionen bereitstellen.

Wie unterscheidet sich ein paralleler Canary von Single-Target-Canaries?

  • Wie bei der Canary-Bereitstellung mit einem einzelnen Ziel müssen Sie bei der Bereitstellung für GKE-Ziele eine Kubernetes-Deployment-Konfiguration und eine Kubernetes-Dienstkonfiguration in Ihrem Manifest haben.

  • Wie bei der Canary-Bereitstellung mit einem einzelnen Ziel muss Ihre Lieferpipeline-Konfiguration einen strategy.canary-Abschnitt in der Stufendefinition für die entsprechende Stufe enthalten.

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

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

    Beide Arten von Rollouts – Controller und untergeordnet – haben separate Phasen für alle konfigurierten Canary-Prozentsätze und eine stable-Phase für den Canary-Prozentsatz von 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 verschoben.

  • Sie können fehlgeschlagene Jobs beim Controller-Roll-out nicht wiederholen.

    Sie können einen Job nur in untergeordneten Roll-outs wiederholen.

  • Sie können fehlgeschlagene Jobs beim Controller-Roll-out nicht ignorieren.

    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 Job-Ausführungen nur in einem untergeordneten Roll-out, nicht in einem Controller-Roll-out beenden.

Vorgehensweise bei einem fehlgeschlagenen parallelen Rollout in Canary

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

  • Wenn mindestens ein untergeordnetes Roll-out fehlschlägt, aber mindestens ein untergeordnetes Roll-out noch IN_PROGRESS ist, bleibt das Controller-Roll-out IN_PROGRESS.

  • Wenn mindestens ein untergeordnetes Roll-out fehlschlägt, aber mindestens ein untergeordnetes Roll-out erfolgreich ist, hat das Controller-Roll-out den Status HALTED, wenn es nach der aktuellen Phase weitere Phasen gibt.

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

    Mit HALTED haben Sie die Möglichkeit, fehlgeschlagene Jobs im fehlgeschlagenen untergeordneten Roll-out entweder zu ignorieren oder noch einmal zu versuchen oder das Controller-Roll-out abzubrechen und weitere Aktionen für die untergeordneten Roll-outs zu verhindern.

  • Wenn sich das Controller-Roll-out aufgrund eines fehlgeschlagenen untergeordneten Roll-outs im Status HALTED befindet und Sie den fehlgeschlagenen Job im untergeordneten Roll-out ignorieren, wechselt das Controller-Roll-out zurück in den Status IN_PROGRESS.

Nächste Schritte