Best Practices für Kubernetes GitOps mit Config Sync

Diese Seite bietet einen Ausgangspunkt, um CI/CD-GitOps-Pipelines für Kubernetes zu planen und zu konzipieren, damit 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 gibt es jedoch viele Möglichkeiten. Wenn Sie Ihre Optionen sowie die Vor- und Nachteile dieser Entscheidungen verstehen, können Sie zukünftige Umformulierungen Ihrer Architektur vermeiden.

Sie müssen nicht alle auf dieser Seite aufgeführten Best Practices anwenden. Welche Best Practices Sie anwenden, hängt von Ihrer individuellen Situation ab. Das Ziel dieser Seite ist es, Ihnen beim Einrichten Ihrer GitOps-Architektur fundierte Entscheidungen zu treffen.

Ein zentrales, privates Paket-Repository verwenden

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

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

Sie können die Schreibberechtigungen für das Repository auf nur 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 senden.

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

Vorteile

Nachteile

Nehmen Sie öffentliche Pakete in einem festgelegten Rhythmus auf, um Unterbrechungen durch Konnektivität oder Upstream-Abwanderung zu vermeiden. Freigegebene Pakete prüfen und scannen. Bietet eine einfache Möglichkeit, herauszufinden, was verwendet wird und was unterstützt wird. Teams können beispielsweise das standardmäßige Redis-Deployment, das im zentralen Repository gespeichert ist, einfacher finden. Nehmen Sie Änderungen an vorgelagerten Paketen vor, damit sie internen Standards wie Standardwerte, Hinzufügen von Labels und Container-Image-Repositories entsprechen.

Jemand muss das zentrale Repository pflegen. Dies bietet mehr Abläufe für Bewerbungsteams.

Nass-Repositorys erstellen

Erstellen Sie Repositories mit der YAML-Ausgabe, die dem gewünschten Status Ihres Clusters oder Namespace entspricht. Die Änderungen am nassen oder vollständig hydrierten Repository sollten mithilfe eines Unterschieds leicht zu überprüfen sein. Es empfiehlt sich, Änderungen nur am Wet 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
Sie können den Unterschied leichter untersuchen. Es ist keine Verarbeitung erforderlich, um den gewünschten Status der Konfiguration zu sehen.	Eine vollständige Hydrationskonfiguration kann zu wiederholten YAML-Dateien führen.

Zum Validieren von Konfigurationen nach links verschieben

Wenn Sie auf Probleme warten, bis Config Sync mit der Synchronisierung beginnt, kann dies zu unnötigen Git-Commits und einer langen Feedbackschleife führen. Bevor eine Konfiguration auf einen Cluster angewendet wird, können viele Probleme mit kpt-Validator-Funktionen wie kubeval ermittelt werden.

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

Vorteile	Nachteile
Die Angabe von Konfigurationsänderungen in einer Änderungsanfrage kann dazu beitragen, zu 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 Phasenzweig eine anstehende Änderung der Konfiguration oder eine dauerhafte Differenz 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

Das Erkennen von Ordnern ist einfacher als Zweige. Unterschiede für Ordner sind mit vielen CLI- und GUI-Tools möglich, während Zweig-Unterschiede außerhalb von Git-Anbietern seltener vorkommen. Mit Ordnern ist es einfacher, dauerhafte von nicht hochgestuften Unterschieden zu unterscheiden. Sie können mit einer Änderungsanfrage Änderungen an mehreren Clustern und Namespaces einführen, während Zweige mehrere Änderungsanfragen an verschiedene Zweige erfordern.

Konfigurationsänderungen können nicht mithilfe einer Änderungsanfrage für dieselben Dateien hochgestuft werden.

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 Zustand 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 aufgeführt, wenn ClusterSelectors nicht verwendet wird:

Vorteile	Nachteile
Es ist einfacher, die Konfiguration für den Cluster in einem Ordner zusammenzuführen, anstatt diese Entscheidung für den Cluster zu treffen. Reduziert die mentale Belastung beim Verständnis, was tatsächlich auf den Cluster angewendet wird.	Labels sind eine einfache Möglichkeit, einem Cluster eine Eigenschaft hinzuzufügen, und es ist komplexer, ein neues „RepoSync“ zu erstellen.

Verwalten von Jobs mit Config Sync vermeiden

Config Sync kann Jobs zwar für Sie anwenden, aber sie eignen sich aus folgenden Gründen nicht für eine GitOps-Bereitstellung:

• 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 das Objekt jedoch nur, wenn Sie es aus der Quelle entfernen.

• Unbeabsichtigte Ausführung von Jobs: Wenn Sie einen Job mit Config Sync synchronisieren und diesen Job anschließend aus dem Cluster löschen, berücksichtigt Config Sync diese Abweichung vom ausgewählten Status und erstellt den Job neu. Wenn Sie eine Job-Gültigkeitsdauer (TTL) angeben, wird der Job automatisch gelöscht, Config Sync erstellt ihn automatisch neu und startet den Job neu, bis Sie ihn aus der „Source of Truth“ löschen. Häufig ist dies nicht beabsichtigt, da Config Sync den Job noch einmal ausführt.

• Abgleichsprobleme: Config Sync wartet nach dem Anwenden normalerweise auf den Abgleich von Objekten. Jobs gelten jedoch als abgeglichen, wenn sie mit der Ausführung begonnen haben. Das bedeutet, dass Config Sync nicht auf den Abschluss des Jobs wartet, bevor weitere Objekte angewendet werden. Wenn der Job jedoch später fehlschlägt, gilt dies als nicht abgleichbarer Job. In einigen Fällen kann dies die Synchronisierung anderer Ressourcen verhindern und Fehler verursachen, bis Sie das Problem beheben. In anderen Fällen ist die Synchronisierung möglicherweise erfolgreich und nur der Abgleich schlägt fehl.

Aus diesen Gründen raten wir davon ab, Jobs mit Config Sync zu synchronisieren.

In den meisten Fällen sollten Jobs und andere situative Aufgaben von einem Dienst verwaltet werden, der sich um die Lebenszyklusverwaltung kümmert. Sie können diesen Dienst dann mit Config Sync statt mit den Jobs selbst verwalten.

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

Vorteile

Nachteile

Erhöht die GitOps-Kompatibilität. Jobs funktionieren aufgrund der unveränderlichen Felder nicht gut mit dem deklarativen, versionsgesteuerten Ansatz von GitOps. Unbeabsichtigte Folgen werden reduziert. Es besteht keine Gefahr, dass Config Sync gelöschte Jobs automatisch neu erstellt, was zu einer unerwarteten Ausführung führen kann. Weniger Synchronisierungsfehler. Potenzielle Synchronisierungskonflikte und Fehler, die durch fehlgeschlagene Jobs ausgelöst werden, werden vermieden.

Manuelle Jobverwaltung. Sie müssen einen anderen Dienst zum Verwalten von Jobs suchen.

Unstrukturierte Repositories verwenden

Config Sync unterstützt zwei Strukturen zum Organisieren eines Repositorys: unstrukturiert und hierarchisch. Unstrukturiert ist der empfohlene Ansatz, da Sie ein Repository so organisieren können, wie es für Sie am bequemsten ist. Hierarchische Repositories erzwingen im Vergleich dazu 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 mehr Aufwand verursacht.

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

Vorteile	Nachteile
Sie können freigegebene Konfigurationspakete auch dann wiederverwenden, wenn sie CRDs oder andere clusterweite Definitionen enthalten.	Ohne Prozess oder Richtlinien können die Repository-Strukturen je nach Team variieren, was die Implementierung von Tools für den gesamten Gerätepool erschweren kann.

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

Separate Code- und Konfigurations-Repositories

Beim Skalieren eines Mono-Repositorys ist ein für jeden Ordner spezifischer Build erforderlich. Für Personen, die am Code arbeiten und an der Clusterkonfiguration arbeiten, gelten in der Regel unterschiedliche Berechtigungen und Bedenken. Da Code- und Konfigurations-Repositories getrennt bleiben, 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 Schleifen von Commits. Beispielsweise kann der Commit in einem 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 unterschiedliche Berechtigungen für Personen verwenden, die an Anwendungscode und Clusterkonfiguration arbeiten.	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.

Separate Repositories zum Isolieren von Änderungen verwenden

Beim Skalieren eines Mono-Repositorys sind unterschiedliche Berechtigungen für verschiedene Ordner erforderlich. Aus diesem Grund ermöglicht das Trennen von Repositories Sicherheitsgrenzen zwischen der Sicherheits-, Plattform- und Anwendungskonfiguration. Außerdem empfiehlt es sich, Produktions- und Nicht-Produktions-Repositories zu trennen.

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

Vorteile

Nachteile

In einer Organisation mit Plattform-, Sicherheits- und Anwendungsteams unterscheidet sich der Rhythmus von Änderungen und Berechtigungen. Berechtigungen verbleiben auf Repository-Ebene. Mit CODEOWNERS-Dateien können Organisationen die Schreibberechtigung einschränken, aber weiterhin Leseberechtigungen zulassen. Config Sync unterstützt mehrere Synchronisierungen pro Namespace, wodurch ein „Mix-In-Effekt“ aus mehreren Repositories erzielt werden kann.

Die Verwaltung vieler Repositories ist eine eigene Aufgabe. Wenn Sie also ein neues Repository pro Cluster erstellen, muss das Problem der Einrichtung/Entfernung des Clusters jetzt die Repository-Verwaltung einschließen.

Paketversionen anpinnen

Unabhängig davon, ob Sie Helm oder Git verwenden, sollten Sie die Version des Konfigurationspakets an etwas anpinnen, das nicht versehentlich ohne explizites Rollout weitergeleitet wird.

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

Vorteile	Nachteile
Eine Aktualisierung der freigegebenen Konfiguration kann größere Auswirkungen 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. Dadurch können Kubernetes-Arbeitslasten auf sichere und verwaltbare Weise auf Google-Dienste zugreifen.

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

Vorteile	Nachteile
Reduziert die Komplexität und mögliche 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 Arten von Repositories:

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

Nächste Schritte

• Erste Schritte mit Config Sync