Konfigurationsdateien in einer „Source of Truth“ organisieren

Auf dieser Seite wird erläutert, wie Sie Konfigurationen in einer zentralen Quelle organisieren.

Wenn Ihre Organisation wächst, müssen Sie wahrscheinlich Konfigurationen für eine Flotte von Clustern verwalten und mehrere Teams unterstützen, die in denselben Repositorys arbeiten. Ein wichtiger Bestandteil einer erfolgreichen GitOps-Strategie ist es, dafür zu sorgen, dass Konfigurationen auf die richtigen Cluster angewendet werden und Teams zusammenarbeiten können, ohne sich gegenseitig zu behindern.

Konfigurationsdateien

Config Sync wurde für Clusteroperatoren entwickelt, die viele Cluster verwalten. Wenn Sie Config Sync für die Verwaltung von Namespaces, Roles, RoleBindings, ResourceQuotas und anderen wichtigen Kubernetes-Objekten in Ihrer gesamten Flotte verwenden, können Sie gewährleisten, dass Ihre Cluster die geltenden Unternehmens- und Compliancestandards erfüllen.

Wenn Config Sync diese Ressourcen verwaltet, werden Ihre registrierten Cluster mithilfe von Konfigurationen synchron gehalten. Eine Konfiguration ist eine YAML- oder JSON-Datei in einer „Source of Truth“. Config Sync unterstützt Git-Repositories, OCI-Images und Helm-Diagramme als „Source of Truth“. Konfigurationen enthalten dieselben Konfigurationsdetails, die Sie mit dem Befehl kubectl apply manuell auf einen Cluster anwenden können. Sie können eine Konfiguration für jedes Kubernetes-Objekt erstellen, das in einem Cluster vorhanden sein kann. Warnung: Einige Kubernetes-Objekte, z. B. Secrets, enthalten vertrauliche Informationen, die möglicherweise nicht in einer Single Source of Truth gespeichert werden sollten. Überlegen Sie sich gut, ob Sie diese Objekttypen mit Config Sync verwalten möchten.

Anforderungen und Einschränkungen

  • Einige Kubernetes-Ressourcen enthalten unveränderliche Felder, z. B. Pod-Selektoren in einem Deployment-Objekt. Sie können kein unveränderliches Feld in einer Konfiguration ändern, indem Sie den Wert in der Single Source of Truth ändern. Ein solcher Versuch führt zu einem KNV2009-Fehler. Wenn Sie ein unveränderliches Feld ändern müssen, löschen Sie das Objekt aus Ihrer „Source of Truth“, warten Sie, bis Config Sync das Objekt aus dem Cluster gelöscht hat, und erstellen Sie das Objekt dann mit Ihren Änderungen in Ihrer „Source of Truth“ neu.

  • Wenn Sie Git-Submodule verwenden, müssen Sie Config Sync Zugriff auf alle Repositorys gewähren, einschließlich aller Submodule.

  • Sie können Config Sync nicht verwenden, um integrierte Kubernetes-ClusterRoles direkt zu verwalten. GKE bietet einige integrierte nutzerorientierte Rollen, z. B. cluster-admin, admin, edit und view. Sie können diese ClusterRoles nicht direkt mit Config Sync verwalten, da Config Sync sonst mit GKE in Konflikt gerät. Wenn Sie den integrierten ClusterRoles Berechtigungen hinzufügen möchten, verwenden Sie die Rollenaggregation, um sie indirekt zu ändern. Wenn Sie die Rollen ändern möchten, erstellen Sie in Ihrer Source of Truth eine ClusterRole mit einem eindeutigen Namen und den entsprechenden Annotationen.

„Source of Truth“ organisieren

Sie können Config Sync so konfigurieren, dass die Synchronisierung aus einem gesamten Repository oder aus bestimmten Ordnern oder Branches erfolgt. Aufgrund dieser Flexibilität sollten Sie Ihre Konfigurationsdateien entsprechend den Anforderungen Ihres Teams oder Ihrer Organisation organisieren.

Wir empfehlen, beim Konfigurieren von Config Sync sourceFormat auf unstructured zu setzen. Der strukturierte (hierarchische) Quelltyp erfordert eine sehr spezifische Ordnerstruktur, damit Ihre Konfigurationen richtig synchronisiert werden. In den meisten Fällen führt er zu unnötiger Komplexität.

In der meisten Config Sync-Dokumentation, einschließlich dieser Seite, wird standardmäßig das unstrukturierte Format verwendet. Informationen zum hierarchischen Format finden Sie bei Bedarf unter Hierarchisches Repository verwenden.

Wenn Sie eine unstrukturierte Quelle verwenden, können Sie Ihre Konfigurationen flexibel an den Workflow Ihres Teams anpassen. In diesem Abschnitt finden Sie einige gängige Muster zum Strukturieren Ihres Repositorys.

Umgebungsbasiertes Layout

Ein gängiger Ansatz besteht darin, das Repository nach Umgebung zu organisieren.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

In diesem Beispiel ist die Source of Truth so organisiert:

  • cluster-essentials/: Enthält die Konfiguration, die für alle Cluster gilt, unabhängig von der Umgebung. Dazu gehören möglicherweise Ressourcen wie benutzerdefinierte Ressourcendefinitionen (Custom Resource Definitions, CRDs) und wichtige Namespaces.
  • environments/: Das übergeordnete Verzeichnis für alle umgebungsspezifischen Konfigurationen.
  • system/: Enthält Konfigurationen für Dienste auf Systemebene wie Monitoring.

Dieser Ansatz ist einfach zu verstehen und zu handhaben und bietet einen klaren Pfad für Änderungen von einer Umgebung in eine andere.

Wenn Sie Config Sync in diesem Szenario einrichten, erstellen Sie in jedem Cluster mehrere RootSync-Objekte. Beispiel: Ein Entwicklungscluster hat RootSync-Objekte, die von cluster-essentials/, system/ und environments/dev/ synchronisiert werden.

Clusterbasiertes Layout

Wenn Sie eine Flotte einzelner Cluster mit unterschiedlichen Konfigurationen verwalten möchten, ist ein clusterbasiertes Layout möglicherweise besser geeignet.

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

In diesem Beispiel ist die „Source of Truth“ so organisiert:

  • clusters/: enthält ein Verzeichnis für jeden Cluster, den Sie verwalten.
  • shared/: Enthält Konfigurationen, die für alle Cluster gelten, z. B. RBAC-Rollen und Sicherheitsrichtlinien.

Dieser Ansatz ist effektiv für die Verwaltung vieler Cluster, wenn diese alle eindeutige Konfigurationen haben, da er eine klare Zuordnung und Isolation von Konfigurationen ermöglicht. Dieser Ansatz kann schwieriger zu verwalten sein, wenn Sie viele freigegebene Clusterkonfigurationen haben.

Wenn Sie Config Sync in diesem Szenario einrichten, können Sie ein RepoSync verwenden, um jeden Cluster für die Synchronisierung sowohl aus shared als auch aus dem clusterspezifischen Verzeichnis zu konfigurieren.

Teambasiertes Layout

Für Organisationen, in denen verschiedene Teams unterschiedliche Anwendungen oder Dienste verwalten, kann ein teambasiertes Layout sinnvoll sein. So wird die Struktur der „Source of Truth“ an Ihre Organisationsstruktur angepasst.

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

In diesem Beispiel ist die Quelle der Wahrheit so organisiert:

  • teams/: Konfiguration nach Team organisiert, wobei jedes Team seine eigenen Anwendungs- und Dienstkonfigurationen verwaltet.
  • platform/: Enthält clusterweite Konfigurationen, die von einem zentralen Plattformteam verwaltet werden und die alle Teams verwenden.

So können Teams ihre eigenen Konfigurations- und Releasezyklen verwalten und die Wahrscheinlichkeit wird verringert, dass die Änderungen eines Teams versehentlich ein anderes Team beeinträchtigen. Dieser Ansatz erfordert jedoch eine sorgfältige Verwaltung der Abhängigkeiten zwischen App- und Plattformteams.

Wenn Sie Config Sync für dieses Szenario einrichten, verwendet jedes Team ein RootSync-Objekt, um Konfigurationen zu synchronisieren. Das Team team-alpha synchronisiert beispielsweise Daten aus teams/team-alpha/.

Konfigurationsdateien validieren

Nachdem Sie Konfigurationsdateien für eine „Source of Truth“ erstellt, organisiert und hinzugefügt haben, prüfen Sie mit dem Befehl nomos vet --source-format=unstructured die Syntax und Gültigkeit Ihrer Konfigurationen. So lassen sich Fehler während oder nach der Synchronisierung vermeiden.

Objektmutationen ignorieren

Wenn Sie nicht möchten, dass Config Sync den Status des Objekts in einem Cluster behält, nachdem es vorhanden ist, können Sie dem Objekt die Annotation client.lifecycle.config.k8s.io/mutation: ignore hinzufügen, dass Config Sync Mutationen ignorieren soll.

Das folgende Beispiel zeigt, wie Sie die Annotation einem Objekt hinzufügen:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

Sie können diese Annotation nicht manuell für verwaltete Objekte im Cluster ändern.

Hierarchisches Repository in unstrukturiertes Repository umwandeln

Wenn Sie ein hierarchisches Repository verwenden und es in ein unstrukturiertes Repository konvertieren möchten, führen Sie den folgenden Befehl aus:

nomos hydrate PATH

Ersetzen Sie PATH durch den Pfad zu Ihrem Arbeitsverzeichnis.

Mit diesem Befehl wird im aktuellen Arbeitsverzeichnis ein compiled/-Verzeichnis erstellt. Innerhalb dieses Verzeichnisses wird für jeden registrierten Cluster ein Unterverzeichnis erstellt. Diese Unterverzeichnisse enthalten die vollständig aufgelösten Konfigurationen und können in einem unstrukturierten Repository verwendet werden.

Weitere Informationen finden Sie unter nomos-Befehle.

Wenn Sie Ihr Repository manuell konvertieren möchten, führen Sie die folgenden Schritte aus:

  1. Entfernen Sie Repo-Konfigurationen im Verzeichnis system/ aus Ihrem Git-Repository. Die Repo-Ressource wird für ein unstrukturiertes Repository nicht benötigt.

  2. Das abstrakte Namespace-Verzeichnis wird in einem unstrukturierten Repository nicht unterstützt. Daher müssen Sie den Namespace aller Ressourcen deklarieren, die ursprünglich im Verzeichnis namespaces/ und in dessen Unterverzeichnissen enthalten sind.

  3. Die Namespace-Übernahme wird in einem unstrukturierten Repository nicht unterstützt. Daher müssen Sie alle Ressourcen deklarieren, die ursprünglich in untergeordnete Namespaces übernommen wurden, also solche, die ursprünglich im Verzeichnis namespaces/ enthalten sind.

Nächste Schritte