Best Practices für Kubernetes GitOps mit Config Sync

Diese Seite bietet einen Ausgangspunkt für die Planung und Entwicklung von CI/CD-GitOps-Pipelines für Kubernetes. So können Sie Config Sync optimal nutzen.

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

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

Ein zentralisiertes, privates Paket-Repository verwenden

Wenn Sie ein zentrales Repository für öffentliche oder interne Pakete wie Helm oder kpt verwenden, können Teams Pakete einfacher 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 können sie das zentrale Repository als Gruppe überprüfter Pakete verwenden.

Sie können Schreibberechtigungen für das Repository auf eine kleine Anzahl von Entwicklern beschränken. Der Rest der Organisation kann Lesezugriff haben. Wir empfehlen, einen Prozess zum Hochstufen von Paketen in das zentrale Repository zu implementieren und Aktualisierungen zu übertragen.

Die folgende Tabelle enthält die Vorteile und Nachteile der Verwendung eines zentralisierten, privaten Paket-Repositorys:

Vorteile

Nachteile

Nehmen Sie öffentliche Pakete in einem festgelegten Rhythmus auf. So vermeiden Sie eine Unterbrechung der Verbindung oder der vorgelagerten Abwanderung. Freigegebene Pakete prüfen und scannen. Bietet eine einfache Möglichkeit, herauszufinden, was verwendet wird und unterstützt wird. Beispielsweise können Teams die standardmäßige Redis-Bereitstellung leichter finden, die im zentralen Repository gespeichert ist. Ändern Sie vorgelagerte Pakete so, dass sie interne Standards wie Standardwerte, Labels und Container-Image-Repositories erfüllen.

Ein Nutzer muss das zentrale Repository verwalten. Dadurch wird der Prozess für die Anwendungsteams erweitert.

Nasse Repositories erstellen

Erstellen Sie Repositories mit der YAML-Ausgabe, die dem gewünschten Status Ihres Clusters oder Namespace entspricht. Die Änderungen am feuchten oder voll hydratisierten Repository sollten anhand eines Unterschieds leicht geprüft werden können. Es empfiehlt sich, Änderungen nur am Nass-Repository während eines Überprüfungsprozesses vorzunehmen. In GitHub wäre dies beispielsweise eine Pull-Anfrage.

In der folgenden Tabelle sind die Vorteile und Nachteile des Erstellens von Nass-Repositories aufgeführt:

Vorteile	Nachteile
Es ist einfacher, den Unterschied zu untersuchen. Es ist keine Verarbeitung erforderlich, um den vorgesehenen Status der Konfiguration zu sehen.	Eine vollständig hydratisierende Konfiguration kann zu einer wiederholten YAML-Datei führen.

Zum Validieren von Konfigurationen nach links verschieben

Das Warten auf das Synchronisieren von Config Sync auf Probleme kann zu unnötigen Git-Commits und einer langen Feedbackschleife führen. Viele Probleme können auftreten, bevor eine Konfiguration auf einen Cluster angewendet wird. Verwenden Sie dazu kpt-Validierungsfunktionen wie kubeval.

In der folgenden Tabelle sind die Vor- und Nachteile einer Prüfung auf Probleme vor dem Anwenden einer Konfiguration aufgeführt:

Vorteile	Nachteile
Das Anzeigen von Konfigurationsänderungen in einer Änderungsanfrage kann dazu beitragen, dass Fehler in einem Repository auftreten. Reduziert die Auswirkungen von Problemen in freigegebenen Konfigurationen.	Dem Tool müssen Tools und Logik hinzugefügt werden, um Probleme zu erkennen.

Ordner anstelle von Zweigen verwenden

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

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

Vorteile

Nachteile

Ordner können leichter zu finden sein als Zweige. Bei vielen CLI- und GUI-Tools ist es möglich, Unterschiede bei Ordnern zu tun, während Zweigunterschiede außerhalb von Git-Anbietern seltener sind. Es ist einfacher, Ordner von nicht permanenten Unterschieden zu unterscheiden. Sie können Änderungen an mehreren Clustern und Namespaces in einer Änderungsanfrage einführen, während Zweige mehrere Änderungsanfragen an verschiedene Zweige erfordern.

Es ist nicht möglich, für Konfigurationsänderungen mit einer Änderungsanfrage dieselben Dateien zu verwenden.

Nutzung von ClusterSelectors minimieren

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

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

In der folgenden Tabelle sind die Vorteile und Nachteile von ClusterSelectors nicht aufgeführt:

Vorteile	Nachteile
Es ist einfacher, die auf dem Cluster vorhandene Konfiguration in einem Ordner zu speichern, als diese Entscheidung im Cluster zu treffen. Verringert die mentale Belastung, die versteht, was tatsächlich auf den Cluster angewendet wird.	Labels sind eine einfache Möglichkeit, einem Cluster einen Merkmal hinzuzufügen. Außerdem ist es komplexer, eine neue „RepoSync“ zu erstellen.

Unstrukturierte Repositories verwenden

Config Sync unterstützt zwei Strukturen zum Organisieren eines Repositorys: unstrukturiert und hierarchisch. Wir empfehlen die Option „Unstrukturiert“, da Sie damit ein Repository auf eine Weise verwalten können, die für Sie am besten geeignet ist. Hierarchische Repositories erzwingen dagegen eine bestimmte Struktur. CRDs müssen sich beispielsweise in einem bestimmten Verzeichnis befinden. Dies kann zu Problemen führen, wenn Sie Konfigurationen freigeben müssen. Wenn ein Team beispielsweise ein Paket veröffentlicht, das eine CRD enthält, muss ein anderes Team, das dieses Paket verwenden muss, die CRD in ein cluster-Verzeichnis verschieben, wodurch der Prozess erhöht wird.

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

Vorteile	Nachteile
Sie können freigegebene Konfigurationspakete auch dann wiederverwenden, wenn sie CRDs oder andere clusterweite Definitionen enthalten.	Ohne einen Prozess oder Richtlinien können die Repository-Strukturen je nach Team variieren, was die Implementierung von flottenweiten Tools erschwert.

Informationen zum Konvertieren eines hierarchischen Repositorys finden Sie unter Ein hierarchisches Repository in ein unstrukturiertes Repository konvertieren.

Code- und Konfigurations-Repositories trennen

Zum Hochskalieren eines Mono-Repositorys ist ein individueller Build für jeden Ordner erforderlich. Berechtigungen und Bedenken für Personen, die am Code arbeiten und an der Clusterkonfiguration arbeiten, sind im Allgemeinen unterschiedlich. Wenn Sie Code- und Konfigurations-Repositories getrennt halten, kann jedes Repository eigene 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 „Loop“-Commits. Wenn für einen Code-Repository z. B. ein Commit durchgeführt wird, kann eine CI-Anfrage ausgelöst werden, wodurch ein Bild erstellt wird, für das dann ein Code-Commit erforderlich ist, usw. Sie können verschiedene Berechtigungen für Personen verwenden, die an Anwendungscode und Clusterkonfiguration arbeiten.	Verringert die Erkennung von Anwendungskonfigurationen, da sie sich nicht im selben Repository wie Anwendungscode befindet. Die Verwaltung vieler Repositories kann zeitaufwendig sein.

Änderungen mit separaten Repositories isolieren

Beim Hochskalieren eines Mono-Repositorys sind unterschiedliche Berechtigungen für verschiedene Ordner erforderlich. Aus diesem Grund ermöglicht das Trennen von Repositories Sicherheitsgrenzen zwischen Sicherheits-, Plattform- und Anwendungskonfigurationen. Es ist auch sinnvoll, Produktions- und Nicht-Produktions-Repositories zu trennen.

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

Vorteile

Nachteile

In einer Organisation mit Plattform-, Sicherheits- und Anwendungsteams sind die Kadenz der Änderungen und Berechtigungen unterschiedlich. Berechtigungen bleiben auf Repository-Ebene. Mit CODEOWNERS-Dateien können Organisationen die Schreibberechtigung einschränken und gleichzeitig Leseberechtigungen erteilen. Config Sync unterstützt mehrere Synchronisierungen pro Namespace, die einen „Mix-In-Effekt“ aus mehreren Repositories erzielen können.

Das Verwalten vieler Repositories ist eine eigene Aufgabe. Wenn Sie also ein neues Repository pro Cluster erstellen, muss das Problem beim Einrichten/Löschen des Clusters die Repository-Verwaltung sein.

Paketversionen anpinnen

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

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

Vorteile	Nachteile
Eine freigegebene Konfigurationsaktualisierung kann mehr als die beabsichtigte Wirkung haben, wenn die Paketversion nicht angepinnt ist.	Roll-outs erfordern Prüfungen, wenn freigegebene Pakete aktualisiert werden.

Workload Identity verwenden

Sie können Workload Identity in GKE-Clustern aktivieren, mit der Kubernetes-Arbeitslasten sicher und überschaubar auf Google-Dienste zugreifen können.

In der folgenden Tabelle sind die Vorteile und Nachteile von Workload Identity aufgeführt:

Vorteile	Nachteile
Weniger komplexe und potenzielle Probleme mit Geheimnissen und Passwörtern	Workload Identity-Dienste außerhalb von Google Cloud, z. B. GitHub und GitLab, unterstützen Workload Identity nicht.

Gesamtarchitektur

Grundsätzlich möchten Sie mindestens vier Arten von Repositories:

1. Ein Paket-Repository, in dem die freigegebene Konfiguration gespeichert wird. Dies kann auch ein Helm-Diagramm sein, das in Artifact Registry gespeichert ist.
2. Ein Plattform-Repository, in dem das Plattformteam eine 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 zu einem 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. App-Teams können dann Code in einen Build übertragen.

Nächste Schritte

• Erste Schritte mit Config Sync