Best Practices für Kubernetes GitOps mit Config Sync

Diese Seite bietet einen Ausgangspunkt zum Planen und Entwerfen von CI/CD-GitOps-Pipelines für Kubernetes, mit dem Sie Config Sync optimal nutzen können.

GitOps selbst ist eine universelle Best Practice für Organisationen, die die Kubernetes-Konfiguration in großem Maßstab verwalten. Bei der Architektur dieser Lösung haben Sie jedoch viele Möglichkeiten. Wenn Sie die Optionen sowie die Vor- und Nachteile dieser Entscheidungen kennen, können Sie vermeiden, Ihre Architektur in Zukunft neu zu schreiben.

Sie müssen nicht alle auf dieser Seite aufgeführten Best Practices verwenden. Welche Best Practices Sie anwenden, hängt von Ihrer individuellen Situation ab. Diese Seite soll Ihnen dabei helfen, fundierte Entscheidungen beim Einrichten Ihrer GitOps-Architektur zu treffen.

Zentralisiertes, privates Paket-Repository verwenden

Durch die Verwendung eines zentralen Repositorys für öffentliche oder interne Pakete (z. B. Helm oder kpt) können Teams Pakete leichter finden. Sie können Dienste wie Artifact Registry- oder Git-Repositories verwenden.

Das Plattformteam kann Richtlinien implementieren, bei denen Anwendungsteams Pakete nur aus dem zentralen Repository verwenden können. Alternativ kann das zentrale Repository als eine Reihe geprüfter Pakete verwendet werden.

Sie können die Schreibberechtigungen für das Repository auf nur wenige Entwickler beschränken. Der Rest der Organisation kann Lesezugriff haben. Es wird empfohlen, einen Prozess zum Hochstufen von Paketen im zentralen Repository zu implementieren und Updates zu senden.

In der folgenden Tabelle sind die Vor- und Nachteile der Verwendung eines zentralen, privaten Paket-Repositorys aufgeführt:

Vorteile

Nachteile

Nehmen Sie öffentliche Pakete in einem festgelegten Rhythmus auf, um eine Unterbrechung der Verbindung oder einer Upstream-Abwanderung zu vermeiden. Freigegebene Pakete prüfen und scannen. Bietet eine einfache Möglichkeit, herauszufinden, was verwendet und unterstützt wird. Beispielsweise können Teams das standardmäßige Redis-Deployment, die im zentralen Repository gespeichert sind, leichter finden. Nehmen Sie Änderungen an vorgelagerten Paketen vor, um sicherzustellen, dass sie internen Standards wie Standardwerten entsprechen, Labels hinzufügen und Container-Image-Repositories erfüllen.

Ein Nutzer muss das zentrale Repository verwalten. Mehr Abläufe für Anwendungsteams.

Wet-Repositories erstellen

Erstellen Sie Repositories mit der YAML-Ausgabe, die dem gewünschten Status Ihres Clusters oder Namespace entspricht. Die Änderungen am eigentlichen oder vollständig hydrierten Repository sollten mithilfe eines Diffs einfach zu prüfen sein. Es empfiehlt sich, Änderungen nur am eigentlichen Repository im Rahmen eines Überprüfungsprozesses vorzunehmen (in GitHub wäre dies beispielsweise eine Pull-Anfrage).

In der folgenden Tabelle sind die Vor- und Nachteile der Erstellung von Wet-Repositories aufgeführt:

Vorteile	Nachteile
Es ist einfacher, die Unterschiede zu untersuchen. Es ist keine Verarbeitung erforderlich, um den beabsichtigten Status der Konfiguration zu ermitteln.	Eine vollständig hydratisierte Konfiguration kann zu wiederholter YAML-Datei führen.

Shift-Left-Modell zum Validieren von Konfigurationen

Wenn Sie auf die Überprüfung von Problemen mit Config Sync warten, kann dies zu unnötigen Git-Commits und zu einer langen Feedbackschleife führen. Mit kpt-Validierungsfunktionen wie kubeval können Sie viele Probleme ermitteln, bevor eine Konfiguration auf einen Cluster angewendet wird.

In der folgenden Tabelle sind die Vor- und Nachteile der Prüfung auf Probleme aufgeführt, bevor eine Konfiguration angewendet wird:

Vorteile	Nachteile
Durch das Anzeigen von Konfigurationsänderungen in einer Änderungsanfrage können Sie verhindern, dass Fehler in ein Repository übertragen werden. Reduziert die Auswirkungen von Problemen in gemeinsam genutzten Konfigurationen.	Sie müssen Ihrem Commit-Prozess Tools und Logik hinzufügen, um Probleme zu erkennen.

Ordner anstelle von Zweigen verwenden

Verwenden Sie Ordner für Varianten der Konfiguration anstelle von Zweigen. Bei Ordnern können Sie mit dem Befehl tree Varianten aufrufen. Bei Zweigen können Sie beispielsweise nicht feststellen, ob das Delta zwischen einem Produktions- und einem Phasenzweig eine bevorstehende Änderung der Konfiguration oder ein permanenter Unterschied zwischen der Phase und der Produktion ist.

In der folgenden Tabelle sind die Vor- und Nachteile der Verwendung von Ordnern anstelle von Zweigen aufgeführt:

Vorteile

Nachteile

Die Erkennung von Ordnern ist einfacher als von Zweigen. Unterschiede bei Ordnern lassen sich mit vielen Befehlszeilen- und GUI-Tools erheben. Für Zweige sind diese Tools außerhalb von Git-Anbietern weniger verbreitet. Mit Ordnern lässt sich leichter zwischen dauerhaften und nicht hochgestuften Unterschieden unterscheiden. Sie können Änderungen an mehreren Clustern und Namespaces mit einer Änderungsanfrage einführen, während Zweige mehrere Änderungsanfragen an verschiedene Zweige erfordern.

Das Hochstufen von Konfigurationsänderungen mithilfe einer Änderungsanfrage für dieselben Dateien ist nicht möglich.

Verwendung von ClusterSelectors minimieren

Mit ClusterSelectors können Sie bestimmte Teile einer Konfiguration auf eine Teilmenge von Clustern anwenden. Anstatt RootSync oder RepoSync zu konfigurieren, können Sie entweder die angewendete Ressource ändern oder den Clustern Labels hinzufügen. Wenn jedoch die Anzahl der ClusterSelectors mit der Zeit zunimmt, kann es kompliziert werden, den endgültigen Status des Clusters zu verstehen.

Mit Config Sync können Sie mehrere RootSyncs und RepoSyncs gleichzeitig synchronisieren. Dies bedeutet, dass Sie die relevante Konfiguration einem separaten Repository hinzufügen und dann mit den gewünschten Clustern synchronisieren können.

In der folgenden Tabelle sind die Vor- und Nachteile der Verwendung von ClusterSelectors aufgeführt:

Vorteile	Nachteile
Es ist einfacher, die im Cluster enthaltene Konfiguration in einem Ordner zusammenzustellen, anstatt diese Entscheidung über den Cluster zu treffen. Reduziert die psychische Belastung, zu verstehen, was tatsächlich auf den Cluster angewendet wird.	Labels sind eine einfache Möglichkeit, einem Cluster ein Merkmal hinzuzufügen, und es ist komplexer, ein neues „RepoSync“ zu erstellen.

Verwaltung von Jobs mit Config Sync vermeiden

Config Sync kann zwar Jobs für Sie anwenden, Jobs sind jedoch aus folgenden Gründen nicht gut für die GitOps-Bereitstellung geeignet:

• Unveränderliche Felder: Viele Jobfelder sind unveränderlich. Wenn Sie ein unveränderliches Feld ändern möchten, muss das Objekt gelöscht und neu erstellt werden. Config Sync löscht Ihr Objekt jedoch nur, wenn Sie es aus der Quelle entfernen.

• Unbeabsichtigte Ausführung von Jobs: Wenn Sie einen Job mit Config Sync synchronisieren und dieser Job dann aus dem Cluster gelöscht wird, berücksichtigt Config Sync diesen Abweichung von Ihrem ausgewählten Status und erstellt den Job. Wenn Sie eine Job-Gültigkeitsdauer (TTL) angeben, wird der Job automatisch gelöscht und Config Sync erstellt ihn automatisch neu. Der Job wird dann neu gestartet, bis Sie den Job aus der "Source of Truth". Oft ist dies nicht beabsichtigt, da Config Sync den Job noch einmal ausführt.

• Abgleichsprobleme: Config Sync wartet nach der Anwendung normalerweise auf den Abgleich von Objekten. Jobs werden jedoch als abgeglichen betrachtet, wenn sie ausgeführt werden. Das bedeutet, dass Config Sync nicht wartet, bis der Job abgeschlossen ist, bevor weitere Objekte angewendet werden. Wenn der Job jedoch später fehlschlägt, wird dies als Fehler für den Abgleich betrachtet. In einigen Fällen kann dies verhindern, dass andere Ressourcen synchronisiert werden, und Fehler verursachen, bis Sie das Problem beheben. In anderen Fällen kann die Synchronisierung erfolgreich sein und nur der Abgleich schlägt fehl.

Aus diesen Gründen empfehlen wir, Jobs nicht mit Config Sync zu synchronisieren.

In den meisten Fällen sollten Jobs und andere kontextbezogene Aufgaben von einem Dienst verwaltet werden, der für die Verwaltung des Lebenszyklus zuständig ist. Anschließend haben Sie die Möglichkeit, diesen Dienst mit Config Sync anstelle der Jobs selbst zu verwalten.

In der folgenden Tabelle sind die Vor- und Nachteile aufgeführt, wenn Sie Config Sync nicht zum Verwalten von Jobs verwenden:

Vorteile

Nachteile

Erhöht die GitOps-Kompatibilität. Jobs funktionieren aufgrund ihrer unveränderlichen Felder nicht gut mit dem deklarativen, versionsgesteuerten Ansatz von GitOps. Es werden unbeabsichtigte Folgen reduziert. Beseitigt das Risiko, dass Config Sync gelöschte Jobs automatisch neu erstellt und sie möglicherweise unerwartet ausgeführt werden. Weniger Synchronisierungsfehler. Potenzielle Synchronisierungskonflikte und Fehler, die durch fehlgeschlagene Jobs ausgelöst werden, werden vermieden.

Manuelle Jobverwaltung. Sie benötigen einen anderen Dienst, um Jobs zu verwalten.

Unstrukturierte Repositories verwenden

Config Sync unterstützt zwei Strukturen zum Organisieren eines Repositorys: unstrukturiert und hierarchisch. Unstrukturiert ist der empfohlene Ansatz, da Sie damit ein Repository so organisieren können, wie es für Sie am besten ist. Hierarchische Repositories erzwingen im Vergleich eine bestimmte Struktur. Beispielsweise müssen sich CRDs in einem bestimmten Verzeichnis befinden. Dies kann zu Problemen führen, wenn Sie Konfigurationen freigeben müssen. Wenn beispielsweise ein Team ein Paket mit einer CRD veröffentlicht, muss ein anderes Team, das dieses Paket verwenden muss, die CRD in ein Verzeichnis cluster verschieben, wodurch der Prozess erhöht wird.

In der folgenden Tabelle sind die Vor- und Nachteile der Verwendung unstrukturierter Repositories aufgeführt:

Vorteile	Nachteile
Sie können freigegebene Konfigurationspakete wiederverwenden, auch wenn sie CRDs oder andere clusterweite Definitionen enthalten.	Ohne Prozess oder Richtlinien können die Repository-Strukturen zwischen Teams variieren, was die Implementierung von flottenweiten Tools erschweren kann.

Informationen zum Konvertieren eines hierarchischen Repositorys finden Sie unter Hierarchisches Repository in ein unstrukturiertes Repository umwandeln.

Separate Code- und Konfigurations-Repositories

Beim Hochskalieren eines Mono-Repositorys ist für jeden Ordner ein eigener Build erforderlich. Berechtigungen und Bedenken für Personen, die am Code arbeiten und mit der Clusterkonfiguration arbeiten, unterscheiden sich in der Regel. Wenn Code- und Konfigurations-Repositories getrennt sind, kann jedes Repository seine eigenen Berechtigungen und Strukturen haben.

In der folgenden Tabelle sind die Vor- und Nachteile der Trennung von Code- und Konfigurations-Repositories aufgeführt:

Vorteile	Nachteile
Vermeidet Commits in Schleifen. Zum Beispiel kann das Commit an ein Code-Repository eine CI-Anfrage auslösen, die möglicherweise ein Image erzeugt, für das dann ein Code-Commit erforderlich ist usw. Sie können für Personen, die am Anwendungscode und an der Clusterkonfiguration arbeiten, unterschiedliche Berechtigungen verwenden.	Reduziert die Erkennung für die Anwendungskonfiguration, da sie sich nicht im selben Repository wie der Anwendungscode befindet. Die Verwaltung vieler Repositories kann zeitaufwendig sein.

Änderungen mit separaten Repositories isolieren

Beim Hochskalieren eines Mono-Repositorys sind für verschiedene Ordner unterschiedliche Berechtigungen erforderlich. Aus diesem Grund ermöglicht die Trennung von Repositories Sicherheitsgrenzen zwischen Sicherheit, Plattform und Anwendungskonfiguration. Es empfiehlt sich außerdem, Produktions- und Nicht-Produktions-Repositories zu trennen.

In der folgenden Tabelle sind die Vor- und Nachteile der Isolierung von Änderungen in separaten Repositories aufgeführt:

Vorteile

Nachteile

In einer Organisation mit Plattform-, Sicherheits- und Anwendungsteams ist die Häufigkeit von Änderungen und Berechtigungen unterschiedlich. Berechtigungen bleiben auf Repository-Ebene erhalten. Mit CODEOWNERS-Dateien können Organisationen die Schreibberechtigung beschränken und gleichzeitig die Leseberechtigung zulassen. Config Sync unterstützt mehrere Synchronisierungen pro Namespace, was zu einem „Mix-In-Effekt“ aus mehreren Repositories führen kann.

Die Verwaltung vieler Repositories ist eine eigene Aufgabe. In einem Fall, in dem Sie ein neues Repository pro Cluster erstellen, muss das Problem der Einrichtung/Entfernung des Clusters jetzt die Repository-Verwaltung umfassen.

Paketversionen anpinnen

Unabhängig davon, ob Sie Helm oder Git verwenden, sollten Sie die Version des Konfigurationspakets an etwas anheften, das nicht versehentlich ohne explizites Roll-out verschoben wird.

In der folgenden Tabelle sind die Vor- und Nachteile des Anpinnen von Paketversionen aufgeführt:

Vorteile	Nachteile
Die Aktualisierung einer freigegebenen Konfiguration kann größere Auswirkungen haben, wenn die Paketversion nicht angepinnt ist.	Rollouts erfordern Prüfungen, wenn freigegebene Pakete aktualisiert werden.

Workload Identity verwenden

Sie können Workload Identity in GKE-Clustern aktivieren, damit Kubernetes-Arbeitslasten sicher und verwaltbar auf Google-Dienste zugreifen können.

In der folgenden Tabelle sind die Vor- und Nachteile der Verwendung von Workload Identity aufgeführt:

Vorteile	Nachteile
Reduziert die Komplexität und potenzielle Probleme mit Secrets und Passwörtern.	Dienste außerhalb von Google Cloud (z. B. GitHub und GitLab) unterstützen Workload Identity nicht.

Gesamtarchitektur

Auf übergeordneter Ebene benötigen Sie wahrscheinlich mindestens vier Repository-Typen:

1. Ein Paket-Repository, in dem eine gemeinsam genutzte Konfiguration gespeichert ist. Dies kann auch ein in Artifact Registry gespeichertes Helm-Diagramm sein.
2. Ein Plattform-Repository, in dem das Plattformteam die flottenweite Konfiguration für Cluster und Namespaces speichert.
3. Ein Anwendungskonfigurations-Repository
4. Ein Anwendungscode-Repository.

Das folgende Diagramm zeigt das Layout dieser Repositories:

Das folgende Diagramm zeigt den Konfigurationsfluss vom Anwendungscode in ein Anwendungskonfigurations-Repository. Entwicklungsteams übertragen Code für Anwendungen und Anwendungskonfigurationen in ein Repository. Der Code für Anwendungen und Konfigurationen wird am selben Ort gespeichert und Anwendungsteams haben die Kontrolle über diese Repositories. Anwendungsteams können dann Code in einen Build übertragen.

Nächste Schritte

• Erste Schritte mit Config Sync