Sichere Rollouts mit Config Sync

Dieses Dokument zeigt Clusteroperatoren und Plattformadministratoren, wie Sie mit Config Sync Änderungen sicher in mehreren Umgebungen vornehmen können. Mit diesem Ansatz können Sie Fehler vermeiden, die sich gleichzeitig auf alle Ihre Umgebungen auswirken.

Mit Config Sync können Sie einzelne Cluster, mehrmandantenfähige Cluster und Multi-Cluster-Kubernetes-Konfigurationen mithilfe von Dateien verwalten, die in einem Git-Repository gespeichert sind.

Konfigurationen können mehrere Dinge darstellen, darunter:

• Standard-GKE-Objekte wie Ressourcen vom Typ NetworkPolicies, DaemonSets oder RoleBindings Ressourcen.
• Google Cloud-Ressourcen wie Compute Engine-Instanzen oder Cloud SQL-Datenbanken mit Config Connector
• Einschränkungen über die Konfiguration selbst über den Policy Controller.

Config Sync eignet sich besonders zum Bereitstellen von Konfigurationen, Richtlinien und Arbeitslasten, die für die Ausführung der Plattform erforderlich sind, die Sie auf der Google Kubernetes Engine (GKE) Enterprise-Version erstellen, z. B. Sicherheits-Agents, Monitoring-Agents und Zertifikat-Manager.

Obwohl Sie Anwendungen mit Config Sync für Nutzer bereitstellen können, wird empfohlen, deren Releaselebenszyklus nicht mit dem zuvor veröffentlichten administrativen Arbeitslasten zu verknüpfen. Stattdessen empfehlen wir, ein Tool für die Anwendungsbereitstellung zu verwenden, z. B. ein Tool für die kontinuierliche Bereitstellung, damit Anwendungsteams ihren Releasezeitplans unter Kontrolle haben.

Config Sync ist ein leistungsstarkes Produkt, das viele Elemente verwalten kann. Daher benötigen Sie Leitlinien, um Fehler zu vermeiden, die große Auswirkungen haben. In diesem Dokument werden mehrere Methoden zum Erstellen von Leitlinien beschrieben. Der erste Abschnitt behandelt gestaffelte Rollouts und der zweite Abschnitt den Schwerpunkt auf Tests und Validierungen. Im dritten Abschnitt wird gezeigt, wie Sie Ihre Bereitstellungen überwachen.

Hinweis: In dieser Anleitung wird ein Git-Repository verwendet, um zu erläutern, wie Rollouts implementiert werden. OCI-Images und Helm-Diagramme werden ebenfalls unterstützt.

Gestaffelte Rollouts mit Config Sync implementieren

In einer Multi-Cluster-Umgebung, die für GKE Enterprise-Nutzer üblich ist, empfehlen wir, eine Konfigurationsänderung nicht auf alle Cluster gleichzeitig anzuwenden. Ein gestaffelter Rollout (Cluster pro Cluster) ist viel sicherer, da er die potenziellen Auswirkungen von Fehlern reduziert.

Es gibt mehrere Möglichkeiten, gestaffelte Rollouts mit Config Sync zu implementieren:

• Verwenden Sie Git-Commits oder Tags, um die Änderungen, die Sie auf die Cluster anwenden möchten, manuell anzuwenden.
• Verwenden Sie Git-Zweige, um die Änderungen automatisch anzuwenden, wenn die Änderungen zusammengeführt werden. Sie können für verschiedene Clustergruppen verschiedene Zweige verwenden.
• Verwenden Sie die Objekte ClusterSelector und NamespaceSelector, um Änderungen selektiv auf Untergruppen von Clustern oder Namespaces anzuwenden.

Alle Methoden für gestaffelte Rollouts haben Vor- und Nachteile. Die folgende Tabelle zeigt, welche dieser Methoden Sie gleichzeitig verwenden können.

Kompatibilität	Git-Commits oder -Tags	Git-Zweige	Cluster selectors	Namespace selectors
Git-Commits oder -Tags		Nicht kompatibel	Kompatibel	Kompatibel
Git-Zweige	Nicht kompatibel		Kompatibel	Kompatibel
Cluster selectors	Kompatibel	Kompatibel		Kompatibel
Namespace selectors	Kompatibel	Kompatibel	Kompatibel

Der folgende Entscheidungsbaum kann Ihnen bei der Entscheidung helfen, wann Sie eine der gestaffelten Rollout-Methoden verwenden sollten.

Hinweis: Mit Config Sync können Sie Konfigurationen aus mehreren Repositories synchronisieren: ein Repository für die clusterbezogenen Konfigurationen und ein optionales Repository pro Namespace. Bei Verwendung von mehreren Repositories ist die Verwendung von Namespace-Selektoren unterschiedlich. Sie können aber alle anderen in diesem Abschnitt beschriebenen Methoden auf alle Repositories anwenden, von denen Sie Konfigurationen synchronisieren.

Git-Commits oder -Tags verwenden

Im Vergleich zu den anderen gestaffelten Rollout-Methoden bietet Git-Commits oder -Tags die größte Kontrolle und ist die sicherste. Über die Seite „Config Sync” in der Google Cloud Console können Sie in der Console mehrere Cluster gleichzeitig aktualisieren. Verwenden Sie diese Methode, wenn Sie Änderungen einzeln auf Ihre Cluster anwenden möchten und genau steuern möchten, wann dies geschieht.

Bei dieser Methode "fixieren" Sie jeden Cluster an eine bestimmte Version (entweder ein Commit oder ein Tag) Ihres Repositorys. Diese Methode ähnelt der Verwendung des Git-Commits als Container-Image-Tag. Zum Implementieren dieser Methode geben Sie das Commit, das Tag oder den Hash im Feld spec.git.revision der benutzerdefinierten Ressource RootSync oder RepoSync an.

Wenn Sie Ihre benutzerdefinierten RootSync- oder RepoSync-Ressourcen mit einem Tool wie Kustomize verwalten, können Sie die manuelle Arbeit für Rollouts reduzieren. Mit einem solchen Tool müssen Sie den Parameter revision nur an einer Stelle ändern und dann die neue benutzerdefinierte RootSync- oder RepoSync-Ressource in der von Ihnen ausgewählten Reihenfolge und Geschwindigkeit auf Ihre Cluster anwenden.

Darüber hinaus können Sie die Google Cloud Console verwenden, um den Parameter revision für mehrere Cluster gleichzeitig zu aktualisieren, die zur selben Flotte gehören. Wenn Sie Ihre Konfigurationen jedoch über ein automatisiertes System aktualisieren, sollten Sie die Google Cloud Console nicht zum Ändern der Konfiguration verwenden.

Die folgende RootSync-Definition konfiguriert beispielsweise Config Sync für die Verwendung des Tags 1.2.3:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: [e-mail]:gke/config-sync.git
    revision: 1.2.3
    auth: ssh

Wenn Sie diese Konfiguration auf Ihren Cluster anwenden, verwendet Config Sync das Tag 1.2.3 des Repositorys example.com:gke/config-sync.git.

Um einen Cluster zu aktualisieren, ändern Sie das Feld spec.git.revision in den neuen Wert für den Cluster. Auf diese Weise können Sie definieren, welche Cluster wann aktualisiert werden. Wenn Sie eine Änderung rückgängig machen möchten, ändern Sie das Feld spec.git.revision wieder in den vorherigen Wert.

Das folgende Diagramm veranschaulicht den Rollout-Prozess für diese Methode. Speichern Sie zuerst die Änderungen im Config Sync-Repository. Anschließend aktualisieren Sie die RootSync-Definitionen in allen Clustern:

Wir empfehlen Folgendes:

• Verwenden Sie Git-Commit-IDs anstelle von Tags. Durch die Art und Weise, wie Git funktioniert, gibt es eine Garantie, die sich niemals ändern wird. Ein git push --force kann beispielsweise das von Config Sync verwendete Commit nicht ändern. Dieser Ansatz eignet sich für Prüfzwecke und um zu verfolgen, welches Commit Sie in Logs verwenden. Außerdem wird der Commit für IDs im Gegensatz zu Tags nicht ausgeführt.
• Wenn Sie Git-Tags anstelle von Git-Commit-IDs verwenden möchten, können Sie Ihre Tags schützen, wenn Sie eine Git-Lösung verwenden, die Schutz unterstützt.
• Wenn Sie mehrere Cluster gleichzeitig aktualisieren möchten, können Sie dies in der Google Cloud Console tun. Wenn Sie mehrere Cluster gleichzeitig aktualisieren möchten, müssen sie Teil derselben Flotte und im selben Projekt sein.

Git-Zweige verwenden

Wenn Änderungen an Clustern angewendet werden sollen, sobald sie in Ihrem Git-Repository zusammengeführt wurden, konfigurieren Sie Config Sync so, dass es Git-Zweige anstelle von Commits oder Tags verwendet. Bei dieser Methode erstellen Sie mehrere langlebige Zweige in Ihrem Git-Repository und konfigurieren Config Sync in verschiedenen Clustern, um sie aus verschiedenen Zweige zu lesen.

Ein einfaches Muster hat beispielsweise zwei Zweige:

• Ein staging-Zweig für Nicht-Produktionscluster.
• Ein main-Zweig für Produktionscluster.

Warnung: Wenn Sie mit einer großen Anzahl von Clustern und Umgebungen arbeiten, benötigen Sie möglicherweise eine große Anzahl von Zweigen. Dies kann leicht zu verwalten sein. Deshalb empfehlen wir die Verwendung von Git-Commits über Zweige.

Erstellen Sie für Nicht-Produktionscluster das Objekt RootSync oder RepoSync, wobei das Feld spec.git.branch auf staging eingestellt ist. Erstellen Sie für Produktionscluster das Objekt RootSync oder RepoSync mit dem Parameter spec.git.branch auf main.

Beispiel: Die folgende RootSync-Definition konfiguriert Config Sync für die Verwendung des Zweigs main:

apiVersion: configsync.gke.io/v1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-sync-system
spec:
  git:
    repo: [e-mail]:gke/config-sync.git
    branch: main
    auth: ssh

Das folgende Diagramm veranschaulicht den Rollout-Prozess für diese Methode:

Sie können dieses Muster an bestimmte Anforderungen anpassen, indem Sie mehr als zwei Zweige verwenden oder Zweige verwenden, die nicht zu Umgebungen gehören. Wenn Sie eine Änderung rückgängig machen müssen, verwenden Sie den Befehl git revert, um ein neues Commit für denselben Zweig zu erstellen, der die Änderungen aus dem vorherigen Commit zurücksetzt.

Wir empfehlen Folgendes:

• Verwenden Sie bei der Arbeit mit mehreren Clustern mindestens zwei Git-Zweige, um zwischen Produktions- und Nicht-Produktionsclustern zu unterscheiden.
• Bei den meisten Git-Lösungen können Sie die geschützten Zweige verwenden, um Löschungen oder nicht überprüfte Änderungen dieser Zweige zu verhindern. Weitere Informationen finden Sie in der Dokumentation zu GitHub, GitLab und Bitbucket.

ClusterSelector- und NamespaceSelector-Objekte verwenden

Git-Zweige sind eine gute Möglichkeit, eine gestaffelte Einführung von Änderungen in mehreren Clustern durchzuführen, die letztendlich alle dieselben Richtlinien haben. Wenn Sie eine Änderung jedoch nur für eine Teilmenge von Clustern oder Namespaces bereitstellen möchten, verwenden Sie die Objekte ClusterSelector und NamespaceSelector. Diese Objekte haben ein ähnliches Ziel: Sie können Objekte nur auf Cluster oder Namespaces mit bestimmten Labels anwenden.

Beispiel:

• Mit ClusterSelector - Objekten können Sie je nach Land, in dem sie sich befinden, für verschiedene Compliance-Systeme unterschiedliche Richtlinien auf Cluster anwenden.
• Mit NamespaceSelector-Objekten können Sie verschiedene Richtlinien auf Namespaces anwenden, die von einem internen Team und von einem externen Auftragnehmer verwendet werden.

Mit ClusterSelector - und NamespaceSelector - Objekten können Sie außerdem erweiterte Test- und Freigabemethoden implementieren, z. B.:

• Canary-Releases von Richtlinien, mit denen Sie eine neue Richtlinie für eine kleine Anzahl von Clustern und Namespaces über einen längeren Zeitraum bereitstellen, um die Auswirkungen der Richtlinie zu untersuchen.
• A/B-Tests, bei denen Sie verschiedene Versionen derselben Richtlinie in verschiedenen Clustern bereitstellen, um die Auswirkungen der Richtlinienversionen zu untersuchen und anschließend die beste Version für alle Bereitstellungen auszuwählen.

Stellen Sie sich beispielsweise eine Organisation mit mehreren Produktionsclustern vor. Das Plattformteam hat bereits zwei Kategorien von Produktionsclustern namens canary-prod und prod mit den Objekten Cluster und ClusterSelector erstellt. Weitere Informationen finden Sie unter Verwenden ClusterSelectors).

Das Plattformteam möchte eine Richtlinie mit Policy Controller bereitstellen, um das Vorhandensein eines Teamlabels für Namespaces zu erzwingen, um zu ermitteln, zu welchem Team der jeweilige Namespace gehört. Sie haben bereits eine Version dieser Richtlinie im Probelaufmodus eingeführt und möchten sie jetzt für eine kleine Anzahl von Clustern erzwingen. Mit ClusterSelector-Objekten erstellen sie zwei verschiedene K8sRequiredLabels-Ressourcen, die auf verschiedene Cluster angewendet werden.

• Die Ressource K8sRequiredLabels wird auf Cluster vom Typ prod angewendet, wobei der Parameter enforcementAction auf dryrun gesetzt ist:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: prod
  Spec:
    enforcementAction: dryrun
    match:
      kinds:
        - apiGroups: [""]
          kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

• Die Ressource K8sRequiredLabels wird auf Cluster vom Typ canary-prod ohne den Parameter enforcementAction angewendet, was bedeutet, dass die Richtlinie tatsächlich erzwungen wird:

  apiVersion: constraints.gatekeeper.sh/v1beta1
  kind: K8sRequiredLabels
  metadata:
    name: ns-must-have-team
    annotations:
      configmanagement.gke.io/cluster-selector: canary-prod
  spec:
    match:
      kinds:
        - apiGroups: [""]
      kinds: ["Namespace"]
    parameters:
      labels:
        - key: "team"
  

Mit der Annotation configmanagement.gke.io/cluster-selector kann das Team die Richtlinie nur in Clustern vom Typ canary-prod erzwingen. Dadurch wird verhindert, dass unbeabsichtigte Nebenwirkungen an die gesamte Produktionsumgebung weitergegeben werden. Weitere Informationen zur Probelauffunktion von Policy Controller finden Sie unter Einschränkungen erstellen.

Wir empfehlen Folgendes:

• Verwenden Sie die Objekte ClusterSelector und NamespaceSelector, wenn Sie eine Konfigurationsänderung nur auf eine Teilmenge von Clustern oder Namespaces anwenden möchten – entweder unbegrenzt oder eine lange Zeit.
• Wenn Sie eine Änderung mithilfe von Selectors bereitstellen, sollten Sie sehr vorsichtig sein. Wenn Sie Git-Commits verwenden, wirkt sich jeder Fehler nur auf jeweils einen Cluster aus, da Sie den Cluster nach Cluster bereitstellen. Wenn Sie jedoch den Git-Zweig verwenden, kann sich jeder Fehler auf alle Cluster auswirken, die diesen Zweig verwenden. Wenn Sie Selectors verwenden, kann sich ein Fehler auf alle Cluster gleichzeitig auswirken.

Rezensionen, Tests und Validierungen implementieren

Ein Vorteil von Config Sync besteht darin, dass alles deklarativ verwaltet wird – Kubernetes-Ressourcen, Cloud-Ressourcen und Richtlinien. Das bedeutet, dass Dateien in einem Versionsverwaltungssystem für Ressourcen die Ressourcen darstellen (im Fall von Config Sync). Mit diesem Feature können Sie Entwicklungsworkflows implementieren, die Sie bereits für den Quellcode einer Anwendung verwenden: Überprüfungen und automatisierte Tests.

Rezensionen implementieren

Da Config Sync auf Git basiert, können Sie das Config Sync-Repository mit Ihrer bevorzugten Git-Lösung hosten. Ihre Git-Lösung verfügt wahrscheinlich über eine Funktion zur Codeüberprüfung, mit der Sie Änderungen prüfen können, die an dem Config Sync-Repository vorgenommen wurden.

Die Best Practices für die Überprüfung von Änderungen an Ihrem Repository sind die gleichen wie bei einer normalen Codeüberprüfung:

• Entwicklung nach Baumschema üben.
• Mit kleinen Batches arbeiten.
• Achten Sie darauf, dass die Codeüberprüfung synchron oder zumindest sofort erfolgt.
• Die Person, die die Änderung überprüft und genehmigt, sollte nicht dieselbe Person sein, die die Änderung vorgeschlagen hat.

Aufgrund der Vertraulichkeit der Config Sync-Codebasis sollten Sie außerdem, wenn möglich, mit den folgenden Konfigurationen Ihre Git-Lösung erstellen:

• Schützen Sie die Zweige, die direkt von Clustern verwendet werden. Weitere Informationen finden Sie in der Dokumentation zu GitHub, GitLab und Bitbucket. Mit GitLab können Sie auch Tags schützen.
• Nachdem die Zweige geschützt sind, können Sie die Genehmigungen optimieren, die für das Zusammenführen einer Änderung erforderlich sind:
  • Aktivieren Sie auf GitHub die erforderlichen Rezensionen.
  • Verwenden Sie für GitLab Code-Inhaber, um Genehmigungsberechtigungen auf Basis von Dateien oder Verzeichnissen zu erteilen. Mit den Genehmigungen für Zusammenführungsanfragen können Sie festlegen, dass verschiedene Personen aus verschiedenen Teams eine Anfrage genehmigen müssen, bevor sie zusammengeführt wird.
  • Kombinieren Sie in Bitbucket Standardprüfer mit standardmäßigen Zusammenführungsprüfungen. Optional können Sie ein Plug-in für Codeinhaber für Bitbucket verwenden im Atlassian Marketplace. Mit diesem Plug-in können Sie steuern, wer Änderungen für Unterbereiche des Repositorys genehmigen kann.

Mit diesen verschiedenen Features können Sie Genehmigungen für jede Änderungsanfrage an Ihrer Codebasis erzwingen. Beispielsweise können Sie sicherstellen, dass jede Änderung von mindestens einem Mitglied des Plattformteams, das den Cluster verwaltet, und von einem Mitglied des Sicherheitsteams, der sich in für die Definition und Implementierung von Sicherheitsrichtlinien.

Wir empfehlen Folgendes:

• Erzwingen Sie Peer-Reviews für Ihr Repository und schützen Sie die von Ihren Clustern verwendeten Git-Zweigs.

Automatisierte Tests implementieren

Eine gängige Best Practice beim Arbeiten in einer Codebasis besteht darin, die Continuous Integration zu implementieren. Dies bedeutet, dass Sie automatisierte Tests konfigurieren, die ausgeführt werden, wenn eine Änderungsanfrage erstellt oder aktualisiert wird. Mit automatisierten Tests können viele Fehler erkannt werden, bevor ein Mitarbeiter die Änderungsanfrage überprüft. Dadurch wird die Feedbackschleife für den Entwickler verschärft. Sie können dieselbe Idee mit denselben Tools für das Config Sync-Repository implementieren.

Ein guter Ausgangspunkt hierfür ist beispielsweise, den nomos vet-Befehl bei neuen Änderungen automatisch auszuführen. Mit diesem Befehl wird überprüft, ob die Syntax Ihres Config Sync-Repositorys gültig ist. Sie können diesen Test mithilfe von Cloud Build implementieren. Folgen Sie dazu der Anleitung Konfigurationen prüfen. Sie können Cloud Build mit den folgenden Optionen integrieren:

• Bitbucket mithilfe von Build-Triggern.
• GitHub mit der GitHub-Anwendung "Google Cloud Build". Build-Trigger sind auch für GitHub verfügbar, die GitHub-Anwendung ist jedoch die bevorzugte Integrationsmethode.

Wie Sie in der Anleitung Konfigurationen überprüfen sehen können, wird der Test mit einem Container-Image durchgeführt. Daher können Sie den Test in jeder Continuous Integration-Lösung implementieren, die Container ausführt, nicht nur in Cloud Build.

Wenn Sie die Feedback Loop noch stärker eingrenzen möchten, können Sie den Befehl nomos vet als Git-Pre-Commit-Hook ausführen. Ein Nachteil ist, dass einige Nutzer möglicherweise keinen Zugriff auf die von Config Sync verwalteten Kubernetes-Cluster haben und unter Umständen nicht die vollständige Validierung von ihrer Workstation aus ausführen können. Führen Sie den Befehl nomos vet --clusters "" aus, um die Validierung auf semantische und syntaktische Prüfungen einzuschränken.

Wir empfehlen Folgendes:

• Tests in einer CI-Pipeline implementieren.
• Führen Sie mindestens den Befehl nomos vet für alle vorgeschlagenen Änderungen aus.

Rollouts überwachen

Auch wenn Sie alle Guard-Funktionen implementieren, die in diesem Dokument behandelt werden, können Fehler auftreten. Im Folgenden sind zwei häufig auftretende Fehlertypen aufgeführt:

• Fehler, die für Config Sync selbst kein Problem darstellen, aber verhindern, dass Ihre Arbeitslasten ordnungsgemäß funktionieren, z. B. eine zu restriktive NetworkPolicy, die die Kommunikation von Komponenten Ihrer Arbeitslast verhindert.
• Fehler, die Config Sync unmöglich macht, Änderungen auf einen Cluster anzuwenden, z. B. ein ungültiges Kubernetes-Manifest oder ein von einem Admission-Controller abgelehntes Objekt. Mit den oben beschriebenen Methoden sollten die meisten dieser Fehler abgefangen werden.

Die Ermittlung der Fehler, die im ersten Punkt beschrieben wurden, ist auf der Ebene von Config Sync fast unmöglich, da dies den Status jeder Ihrer Arbeitslasten erfordert. Aus diesem Grund sollten diese Fehler am besten von Ihrem bestehenden Überwachungssystem erkannt werden, das Sie benachrichtigt, wenn eine Anwendung fehlerhaft ist.

Das Erkennen der im zweiten vorangegangenen Punkt beschriebenen Fehler, die selten auftreten sollten, wenn Sie alle Leitplanken implementiert haben, erfordern eine spezielle Einrichtung. Standardmäßig schreibt Config Sync Fehler in seine Logs, die Sie standardmäßig in Cloud Logging finden. Die Fehler werden auch auf der Google Cloud Console-Seite für Config Sync angezeigt. Weder Logs noch die Konsole sind in der Regel ausreichend, um Fehler zu erkennen, da sie wahrscheinlich nicht immer überwacht werden. Die einfachste Möglichkeit, die Fehlererkennung zu automatisieren, besteht in der Ausführung des nomos status-Befehls. Dieser gibt an, ob ein Fehler in einem Cluster aufgetreten ist.

Sie können auch eine fortgeschrittenere Lösung mit automatischen Warnungen für Fehler einrichten. Config Sync stellt Messwerte im Prometheus-Format bereit. Weitere Informationen finden Sie unter Config Sync überwachen.

Wenn die Config Sync-Messwerte in Ihrem Überwachungssystem vorhanden sind, erstellen Sie eine Benachrichtigung, um informiert zu werden, wenn der Messwert gkeconfig_monitor_errors größer als 0 ist. Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien für Cloud Monitoring verwalten oder Benachrichtigungsregeln für Prometheus.

Zusammenfassung der Mechanismen für sichere Rollouts mit Config Sync

In der folgenden Tabelle sind die verschiedenen Mechanismen zusammengefasst, die zuvor in diesem Dokument beschrieben wurden. Keiner dieser Mechanismen ist exklusiv. Sie können einige oder alle Elemente für unterschiedliche Zwecke verwenden.

Mechanismus	Einsatzmöglichkeit	Nicht geeignet für	Anwendungsbeispiel
Git-Commit-IDs und -Tags	Verwenden Sie bestimmte Git-Commit-IDs oder -Tags, um genau zu steuern, auf welche Clusteränderungen angewendet werden.	Verwenden Sie keine Git-Commit-IDs oder -Tags für langlebige Unterschiede zwischen Clustern. Verwenden Sie Clusterselektoren.	Alle Cluster sind so konfiguriert, dass das Git-Commit 12345 angewendet wird. Sie nehmen eine Änderung mit einem neuen Commit (abcdef) vor, den Sie testen möchten. Sie ändern die Konfiguration eines einzelnen Clusters, um dieses neue Commit zum Validieren der Änderung zu verwenden.
Git-Zweige	Verwenden Sie mehrere Git-Zweige, wenn Sie dieselbe Änderung in mehreren Umgebungen bereitstellen möchten: in der anderen.	Verwenden Sie nicht mehrere Git-Zweige für langlebige Unterschiede zwischen Clustern. Die Zweige unterscheiden sich erheblich und werden nur schwer zusammengeführt.	Führen Sie zuerst die Änderung im Staging-Zweig zusammen, wo sie von Staging-Clustern übernommen wird. Führen Sie dann die Änderung im Master-Zweig zusammen, wo sie von Produktionsclustern übernommen wird.
Cluster-Selektoren und Namespace-Selektoren	Verwenden Sie Selektoren für langlebige Unterschiede zwischen Clustern und Namespaces.	Verwenden Sie keine Selektoren für einen bereitgestellten Rollout in mehreren Umgebungen. Wenn Sie eine Änderung zuerst im Staging testen und dann in der Produktion bereitstellen möchten, verwenden Sie separate Git-Zweigen.	Wenn die Anwendungsteams vollen Zugriff auf Entwicklungscluster, aber Lesezugriff auf Produktionscluster benötigen, verwenden Sie das Objekt ClusterSelector, um die richtigen RBAC-Richtlinien nur auf die relevanten Cluster anzuwenden.
Rezensionen anderer Nutzer	Achten Sie darauf, dass die relevanten Teams die Änderungen genehmigen.	Prüfer erfassen nicht alle Fehler, insbesondere Elemente wie Syntaxfehler.	Ihre Organisation verlangt, dass das Sicherheitsteam Konfigurationsänderungen überprüfen muss, die mehrere Systeme betreffen. Ein Mitglied des Sicherheitsteams muss die Änderungen überprüfen.
Automatisierte Tests in der CI-Pipeline	Verwenden Sie automatisierte Tests, um Fehler in Änderungsvorschlägen zu erkennen.	Automatisierte Tests können Prüfer nicht vollständig ersetzen. Beide verwenden.	Das Ausführen des Befehls nomos vet für alle vorgeschlagenen Änderungen bestätigt, dass das Repository eine gültige Config Sync-Konfiguration ist.
Überwachen Sie Synchronisierungsfehler	Config Sync muss Änderungen tatsächlich auf Ihre Cluster anwenden.	Synchronisierungsfehler treten nur auf, wenn Config Sync ein ungültiges Repository anwendet oder der Kubernetes API-Server einige der Objekte ablehnt.	Ein Nutzer umgeht Ihre Tests und Überprüfungen und übergibt eine ungültige Änderung an das Config Sync-Repository. Diese Änderung kann nicht auf Ihre Cluster angewendet werden. Wenn Sie Synchronisierungsfehler überwachen, werden Sie benachrichtigt, wenn ein Fehler auftritt.

Beispiel für eine Rollout-Strategie

In diesem Abschnitt werden die in diesem Artikel vorgestellten Konzepte verwendet, um eine End-to-End-Einführungsstrategie für alle Cluster in Ihrer Organisation zu erstellen. Bei dieser Strategie wird davon ausgegangen, dass Sie separate Flotten für Entwicklung, Staging und Produktion haben (siehe Flottenbeispiel 1 – Ansatz 1).

Warnung: Diese Rollout-Strategie ist komplex. Die Implementierung ist nur dann sinnvoll, wenn Sie eine komplexe Infrastruktur mit mindestens zwei Flotten und mindestens drei Clustern pro Flotte haben. Wenn Sie eine große Anzahl von Flotten haben, aber jeweils einen einzelnen Cluster, können Sie diese Strategie anpassen. Verwenden Sie dazu „Canary-Flotten“ anstelle von „Canary-Clustern“ verwenden.

In diesem Szenario konfigurieren Sie jeden Cluster für die Synchronisierung mit Ihrem Git-Repository mithilfe eines bestimmten Git-Commits. Die Bereitstellung einer Änderung in einer bestimmten Flotte umfasst vier Schritte:

1. Sie aktualisieren einen einzelnen (den „Canary“)-Cluster in der Flotte, um das neue Commit zuerst zu verwenden.
2. Sie prüfen, ob alles erwartungsgemäß funktioniert. Führen Sie dazu Tests aus und überwachen Sie den Rollout.
3. Sie aktualisieren die übrigen Cluster in der Flotte.
4. Sie prüfen noch einmal, ob alles wie erwartet funktioniert.

Wenn Sie eine Änderung in allen Clustern bereitstellen möchten, wiederholen Sie diesen Vorgang für jede Flotte. Sie können diese Methode technisch auf jedem Git-Commit anwenden. Wir empfehlen Ihnen aber, den folgenden Prozess zu folgen, um Probleme frühzeitig während der Prüfung zu identifizieren:

1. Wenn jemand eine Änderungsanfrage im Git-Repository von Config Sync öffnet, stellen Sie diese Änderung für einen der Entwicklungscluster bereit.
2. Wenn die Änderungsanfrage akzeptiert und in Ihrem Hauptzweig zusammengeführt wurde, führen Sie das vollständige Deployment für alle Flotten wie oben beschrieben aus.

Auch wenn einige Änderungen möglicherweise nur auf eine bestimmte Flotte ausgerichtet sind, empfehlen wir, alle Änderungen erst später für alle Flotten bereitzustellen. Diese Strategie beseitigt das Problem der Verfolgung, welche Flotte mit welchem Commit synchronisiert werden soll. Achten Sie besonders auf die Änderungen, die nur auf die Produktionsflotte ausgerichtet sind, da in früheren Flotten keine ordnungsgemäßen Tests möglich waren. Dies bedeutet beispielsweise, dass Sie länger warten müssen, bis Probleme zwischen der Bereitstellung in den Canary-Clustern und den übrigen Clustern auftreten.

Zusammenfassend sieht eine vollständige End-to-End-Bereitstellung folgendermaßen aus:

1. Ein Änderungsantrag wird geöffnet.
2. Automatisierte Tests und Validierungen werden durchgeführt und eine manuelle Prüfung wird durchgeführt.
3. Sie lösen einen Job manuell aus, um die Änderung für den Canary-Cluster in der Entwicklungsflotte bereitzustellen. In diesem Cluster werden automatische End-to-End-Tests ausgeführt.
4. Wenn alles in Ordnung ist, führen Sie die Änderungsanfrage im Hauptzweig zusammen.
5. Die Zusammenführung löst einen automatisierten Job aus, um den neuen Zweigspitzen-Commit für den Canary-Cluster in der Entwicklungsflotte bereitzustellen. In diesem Cluster werden automatische End-to-End-Tests ausgeführt, um mögliche Inkompatibilitäten zwischen zwei Änderungsanfragen zu ermitteln, die erstellt und etwa zeitgleich erstellt wurden.
6. Die folgenden Jobs werden nacheinander ausgeführt (Sie lösen sie manuell oder nach einer vordefinierten Zeit aus, um Nutzerberichte über Regressionen zu ermöglichen):
   1. In allen Clustern der Entwicklungsflotte bereitstellen.
   2. Tests und Validierungen in den Clustern der Entwicklungsflotte ausführen.
   3. Im Canary-Cluster der Staging-Flotte bereitstellen.
   4. Tests und Validierungen im Canary-Cluster der Staging-Flotte durchführen.
   5. In allen Clustern der Staging-Flotte bereitstellen.
   6. Tests und Validierungen in den Clustern der Staging-Flotte ausführen.
   7. Im Canary-Cluster der Produktionsflotte bereitstellen.
   8. Tests und Validierungen im Canary-Cluster des Produktionsflotte ausführen.
   9. In allen Clustern der Produktionsflotte bereitstellen.
   10. Tests und Validierungen in den Clustern der Produktionsflotte ausführen.

Nächste Schritte

• Monitoring von Config Sync
• Weitere Informationen zu Flotten
• Erfahren Sie, wie Sie Ihre Anwendung mit Unternehmensrichtlinien in einer CI-Pipeline validieren.