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 der Nutzer 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 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 angehängten GKE-Clustern) bereitstellen, stellen Sie die neue Version Ihrer Anwendung in einer begrenzten Anzahl von Pods bereit. 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 selbst zwischen den alten und neuen Überarbeitungen auf, entsprechend den von Ihnen konfigurierten Prozentzahlen.

Arten von Canaries

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 zusätzliche Vorgänge in Ihrem Namen 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 Pre-Deploy- oder Post-Deploy-Job 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 Pre-Deploy- oder Post-Deploy-Job oder beides enthalten sein soll

    Bei einem vollständig benutzerdefinierten Canary stellen Sie außerdem die gesamte Konfiguration für den Lastausgleich 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‑Prozent-Schritte konfigurieren, hat das Rollout 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 ist für die Bereitstellung in GKE-Zielen eine Kubernetes-Deployment-Konfiguration und eine Kubernetes-Dienstkonfiguration in Ihrem Manifest erforderlich.

  • 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-Rollout und die untergeordneten Rollouts erstellt.

    Für beide Arten von Rollouts – Controller und untergeordnet – gibt es 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 im 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 erfolgreich ist, aber mindestens ein untergeordnetes Roll-out fehlschlägt, 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, entweder fehlgeschlagene Jobs im fehlgeschlagenen untergeordneten Roll-out 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