Sichere Roll-outs mit Config Sync

In diesem Dokument erfahren Sie, wie Clusteroperatoren und Plattformadministratoren mit Config Sync sicher Änderungen in mehreren Umgebungen einführen können. Mit diesem Ansatz können Sie Fehler vermeiden, die alle Ihre Umgebungen gleichzeitig betreffen.

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 verschiedene Aspekte 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 zum Ausführen der Plattform erforderlich sind, die Sie auf der Google Kubernetes Engine (GKE) Enterprise-Version erstellen, z. B. Sicherheits-Agents, Monitoring-Agents und Zertifikatmanager.

Obwohl Sie mit Config Sync Anwendungen für Nutzer bereitstellen können, raten wir davon ab, deren Release-Lebenszyklus mit dem Release-Lebenszyklus der zuvor erwähnten 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, mit dem viele Elemente verwaltet werden können. Daher benötigen Sie Schutzmaßnahmen, um Fehler mit erheblichen Auswirkungen zu vermeiden. In diesem Dokument werden mehrere Methoden zum Erstellen von Leitlinien beschrieben. Der erste Abschnitt befasst sich mit gestaffelten Roll-outs und der zweite Abschnitt konzentriert sich auf Tests und Validierungen. Im dritten Abschnitt wird beschrieben, wie Sie Ihre Bereitstellungen überwachen.

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

Gestaffelte Roll-outs mit Config Sync implementieren

In einer Multi-Cluster-Umgebung, die für GKE Enterprise-Nutzer häufig auftritt, raten wir davon ab, eine Konfigurationsänderung auf alle Cluster gleichzeitig anzuwenden. Ein gestaffeltes Rollout (Cluster pro Cluster) ist viel sicherer, da es die potenziellen Auswirkungen von Fehlern reduziert.

Es gibt mehrere Möglichkeiten, gestaffelte Roll-outs 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. Auf der Seite „Config Sync“ in der Google Cloud Console in der Console können Sie 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 „pinnen“ Sie jeden Cluster an eine bestimmte Version (entweder einen Commit oder ein Tag) Ihres Repositorys an. Diese Methode ähnelt der Verwendung des Git-Commits als Container-Image-Tag. Zur Implementierung dieser Methode geben Sie den Commit, das Tag oder den Hash im Feld spec.git.revision der benutzerdefinierten Ressource RootSync oder RepoSync an.

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

Darüber hinaus können Sie die Google Cloud Console verwenden, um den revision-Parameter für mehrere Cluster gleichzeitig zu aktualisieren, die zur selben Flotte gehören. Wenn Sie jedoch ein automatisiertes System zum Aktualisieren Ihrer Konfigurationen haben, raten wir davon ab, die Google Cloud Console für Konfigurationsänderungen zu verwenden.

Durch die folgende RootSync-Definition wird Config Sync beispielsweise so konfiguriert, dass das Tag 1.2.3 verwendet wird:

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 den 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. Zuerst führen Sie einen Commit für Änderungen im Config Sync-Repository durch und aktualisieren dann 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 den von Config Sync verwendeten 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.
• In der Google Cloud Console können Sie mehrere Cluster gleichzeitig aktualisieren. Wenn Sie mehrere Cluster gleichzeitig aktualisieren möchten, müssen diese Teil derselben Flotte (und im selben Projekt) sein.

Git-Zweige verwenden

Wenn Änderungen auf Cluster angewendet werden sollen, sobald sie in Ihrem Git-Repository zusammengeführt wurden, konfigurieren Sie Config Sync, um Git-Zweige anstelle von Commits oder Tags zu verwenden. Bei dieser Methode erstellen Sie mehrere langlebige Zweige in Ihrem Git-Repository und konfigurieren Config Sync in verschiedenen Clustern, um die Konfiguration aus verschiedenen Zweigen 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. Aus diesem Grund empfehlen wir die Verwendung von Git-Commits über Zweige.

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

Die folgende RootSync-Definition konfiguriert Config Sync beispielsweise 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 vorheriges Commit.

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 einführen 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 Objekten vom Typ Cluster und ClusterSelector erstellt (siehe ClusterSelectors verwenden).

Das Plattformteam möchte eine Richtlinie mit Policy Controller einführen, um das Vorhandensein eines Teamlabels für Namespaces zu erzwingen und so zu identifizieren, zu welchem Team jeder 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. Dies bedeutet, dass Dateien in einem Versionsverwaltungssystem die Ressourcen darstellen (im Fall von Config Sync Git-Dateien). 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 hat wahrscheinlich ein Codeüberprüfungsfeature, mit dem Sie Änderungen am Config Sync-Repository überprüfen können.

Die Best Practices zum Überprüfen 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 empfehlen wir außerdem, nach Möglichkeit mit Ihrer Git-Lösung die folgenden Konfigurationen zu 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 verfeinern, die zum Zusammenführen einer Änderung erforderlich sind:
  • Aktivieren Sie auf GitHub die erforderlichen Überprüfungen.
  • Verwenden Sie für GitLab Codeinhaber, um Genehmigungsberechtigungen auf Datei- oder Verzeichnisbasis zu delegieren. Mithilfe von 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 Ihre 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 Überprüfungen durch andere Teilnehmende für Ihr Repository und schützen Sie die Git-Zweige, die von Ihren Clustern verwendet werden.

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 den gleichen Vorschlag mit denselben Tools für das Config Sync-Repository umsetzen.

Ein guter Ausgangspunkt hierfür ist beispielsweise, den nomos vet-Befehl bei neuen Änderungen automatisch auszuführen. Dieser Befehl prüft, ob die Syntax des 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 mithilfe der Google Cloud Build-GitHub-Anwendung erstellen. 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 besteht darin, dass einige Nutzer möglicherweise keinen Zugriff auf die von Config Sync verwalteten Kubernetes-Cluster haben und die vollständige Validierung nicht auf ihrer Workstation 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 im ersten vorherigen Aufzählungspunkt beschriebenen Fehler zu erkennen, ist auf Config Sync-Ebene fast unmöglich, da Sie dafür den Status Ihrer einzelnen Arbeitslasten verstehen müssen. 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. Config Sync schreibt standardmäßig Fehler in seine Logs. Diese finden Sie standardmäßig in Cloud Logging. Fehler werden auch auf der Google Cloud Console-Seite „Config Sync“ angezeigt. Weder Logs noch die Console 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 zur Verfügung. Weitere Informationen finden Sie unter Config Sync überwachen.

Nachdem die Config Sync-Messwerte in Ihrem Monitoringsystem vorhanden sind, erstellen Sie eine Benachrichtigung, 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 Roll-outs 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.	Wenn Sie für alle vorgeschlagenen Änderungen den Befehl nomos vet ausführen, bestätigen Sie, dass das Repository eine gültige Config Sync-Konfiguration ist.
Überwachen Sie Synchronisierungsfehler	Achten Sie darauf, dass Config Sync Änderungen tatsächlich auf Ihre Cluster anwendet.	Synchronisierungsfehler treten nur auf, wenn Config Sync versucht, ein ungültiges Repository anzuwenden, oder wenn der Kubernetes API-Server einige Objekte ablehnt.	Ein Nutzer umgeht alle Ihre Tests und Überprüfungen und führt eine ungültige Änderung an das Config Sync-Repository durch. 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 mit einem bestimmten Git-Commit für die Synchronisierung mit Ihrem Git-Repository. 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 wie erwartet funktioniert, indem Sie Tests ausführen und den Rollout überwachen.
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 ein Nutzer eine Änderungsanfrage im Git-Repository von Config Sync öffnet, stellen Sie diese Änderung in einem 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

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