Sources of Truth

In diesem Dokument werden die verschiedenen Arten von „Source of Truth“ beschrieben, aus denen Config Sync synchronisieren kann.

Ein Schlüsselkonzept in GitOps-Workflows ist die Source of Truth, ein zentrales Repository, in dem Ihre Konfigurationsdateien gespeichert sind. Eine Konfigurationsdatei ist in der Regel eine YAML- oder JSON-Datei, in der Kubernetes-Ressourcen definiert werden. Normalerweise wenden Sie Kubernetes-Objekte manuell mit dem kubectl-Befehlszeilentool an. Config Sync kann diese Ressourcen jedoch automatisch aus einer Single Source of Truth wie einem Git-Repository anwenden. Config Sync überwacht dann die angegebene Source of Truth und wendet alle Änderungen automatisch auf Ihre Cluster an.

Config Sync kann Konfigurationsdateien aus drei verschiedenen Quelltypen synchronisieren: Git-Repositories, OCI-Images (Open Container Initiative) und Helm-Diagramme. In diesem Dokument werden die einzelnen Quelltypen und die Interaktion von Config Sync mit ihnen erläutert. Wenn Sie dieses Dokument lesen, können Sie die beste Quelloption für Ihren Workflow und Ihre Umgebung auswählen.

Git-Repositories

Git ist eine weit verbreitete Technologie für die Versionsverwaltung und Zusammenarbeit. Mit Git können Sie Ihr Repository nach Bedarf organisieren und bei Bedarf die Vorteile der Versionsverwaltung und des Branching nutzen. Da Git eine ausgereifte und weit verbreitete Technologie ist, haben Sie eine Vielzahl von Optionen für Anbieter und Tools.

Wenn Sie Config Sync mit einem Git-Repository als Single Source of Truth konfigurieren, verwendet Config Sync einen git-sync-Container im Reconciler-Pod, um Konfigurationen aus dem Git-Repository abzurufen. Sie können die Repository-URL, den Zweig und die Revision (Commit oder Tag) konfigurieren, um besser zu steuern, wo Konfigurationen in Ihrem Git-Repository abgerufen werden.

Beispiel für die RootSync-Konfiguration

Das folgende Beispiel zeigt ein RootSync-Manifest, das aus einem Git-Repository synchronisiert wird:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

Mit dieser Konfiguration wird Config Sync so eingerichtet, dass Manifeste aus einem Git-Repository synchronisiert werden. Config Sync überwacht das Verzeichnis cluster-configs im Branch main des Repository https://github.com/example/my-configs.git und sucht alle 60 Sekunden ohne Authentifizierung nach Aktualisierungen.

Anwendungsbeispiel: Zentrale Verwaltung

Angenommen, Sie sind ein Plattformadministrator, der ein Git-Repository verwenden möchte, um Basisrichtlinien für alle Cluster in einer Flotte zu erzwingen. In diesem Szenario können Sie Standard-NetworkPolicies, RoleBindings und ResourceQuotas in einem zentralen Git-Repository mit dem Namen standard-configs speichern. Wenn ein neuer Cluster bereitgestellt wird, wird Config Sync so konfiguriert, dass die Synchronisierung aus dem standard-configs-Repository erfolgt. So wird dafür gesorgt, dass alle Cluster von Anfang an den Organisationsstandards entsprechen.

OCI-Images

OCI-Images sind ein Standardformat für das Verpacken von Anwendungen und ihren Abhängigkeiten. Bei diesem Ansatz werden Ihre Konfigurationen wie Artefakte behandelt, ähnlich wie Container-Images. Dieser Ansatz bietet Vorteile wie Unveränderlichkeit und schnellere Leistung bei Skalierung. Mit OCI können Sie Container-Image-Infrastruktur und -Tools wie Artifact Registry verwenden, um Ihre Images zu verwalten, und die Workload Identity-Föderation für GKE, um die Authentifizierung zu vereinfachen.

Wenn Sie OCI als Konfigurationsquelle verwenden, ist in der Regel ein separater Prozess erforderlich, um Ihre Konfigurationsdateien in ein OCI-Image zu erstellen und es dann in eine Registrierungsplattform wie Artifact Registry zu übertragen. Dieser Ansatz ist möglicherweise weniger direkt lesbar als Konfigurationen, die als Dateien in einem Git-Repository gespeichert sind.

Wenn Sie Config Sync mit einem OCI-Image als „Source of Truth“ konfigurieren, verwendet Config Sync einen oci-sync-Container im Reconciler-Pod, um das OCI-Image mit den Konfigurationen aus der Registry abzurufen.

Beispiel für die RootSync-Konfiguration

Das folgende Beispiel zeigt ein RootSync-Manifest, das aus einem in Artifact Registry gespeicherten OCI-Image synchronisiert wird:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

Mit dieser Konfiguration wird Config Sync für die Synchronisierung aus einem OCI-Image eingerichtet. Config Sync ruft das us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0-Image aus Artifact Registry ab und verwendet zur Authentifizierung ein Kubernetes-Dienstkonto.

Beispielanwendungsfall: CI/CD-Pipeline-Integration

Stellen Sie sich vor, Sie möchten die Erstellung von OCI-Images in die CI/CD-Pipeline Ihrer Organisation einbinden. Wenn Änderungen an Konfigurationsdateien zusammengeführt werden, können Sie Ihre Pipeline so einrichten, dass Validierungstests (z. B. der Befehl nomos vet) ausgeführt werden, die YAML-Dateien in ein OCI-Image erstellt und das Image in Artifact Registry übertragen wird. Config Sync würde dann automatisch die neue Version des Images erkennen und auf Ihre Cluster anwenden. So wird ein validierter und versionierter Roll-out aller Konfigurationsänderungen gewährleistet.

Helm-Diagramme

Helm ist ein beliebter Paketmanager für Kubernetes, der ein Paketformat namens „Charts“ verwendet. Config Sync kann Ressourcen abrufen, rendern und synchronisieren, die in Helm-Diagrammen definiert sind.

Helm bietet eine einheitliche Möglichkeit, Kubernetes-Anwendungen zu verpacken und wiederzuverwenden. Sie können Vorlagen oder vorgefertigte Helm-Diagramme für konsistente und wiederverwendbare Konfigurationen verwenden.

Wenn Sie noch nicht mit Helm vertraut sind, können die Vorlagen und der Releaseprozess die Komplexität Ihrer Pipeline für die Konfigurationsverwaltung erhöhen.

Wenn Sie Config Sync mit einem Helm-Diagramm als „Source of Truth“ konfigurieren, verwendet Config Sync einen helm-sync-Container im Reconciler-Pod, um Diagramme aus einem Helm-Repository (z. B. Artifact Registry) oder einem Git-Repository abzurufen und dann das Diagramm zu rendern, um Kubernetes-Manifeste zu erstellen. Alternativ können Sie Config Sync mit Kustomize verwenden, um Helm-Diagramme zu rendern. Weitere Informationen zu diesem Ansatz finden Sie unter Config Sync mit Kustomize und Helm verwenden.

Beispiel für die RootSync-Konfiguration

Das folgende Beispiel zeigt ein RootSync-Manifest, das aus einem in Artifact Registry gespeicherten Helm-Chart synchronisiert wird:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

Mit dieser Konfiguration wird Config Sync für die Synchronisierung eines Helm-Diagramms aus einem OCI-Repository eingerichtet. Config Sync ruft Version 1.2.0 des Diagramms my-chart aus dem Repository oci://us-central1-docker.pkg.dev/my-project/my-helm-repo ab und authentifiziert sich mit dem Dienstkonto my-service-account@my-project.iam.gserviceaccount.com. Die Ressourcen des Diagramms werden im Namespace my-app-namespace unter dem Release-Namen my-chart-release bereitgestellt.

Beispielanwendungsfall: Bereitstellung einer Drittanbieteranwendung

Stellen Sie sich vor, Sie sind Teil eines Anwendungsteams, das Prometheus in einem Cluster bereitstellen möchte. Sie können Config Sync so konfigurieren, dass Daten aus einem vorgefertigten Helm-Chart abgerufen werden, mit dem Prometheus bereitgestellt wird. Anstatt Helm-Befehle manuell auszuführen, definieren Sie die Diagrammquelle, die Version und alle benutzerdefinierten values im RootSync- oder RepoSync-Objekt von Config Sync. Config Sync synchronisiert die Bereitstellung dann mit der angegebenen Chart-Version und den Konfigurationen.

Quellentyp auswählen

Der beste Quelltyp hängt von den vorhandenen Tools, Workflows und Einstellungen Ihres Teams ab. Anhand dieser Tabelle können Sie die wichtigsten Merkmale der einzelnen Quelltypen nachvollziehen und so eine fundierte Entscheidung treffen:

Funktion Git-Repository OCI-Image Helm-Diagramm
Optimal für Konfigurationsverwaltung für allgemeine Zwecke; Flexibilität; Lesbarkeit für Menschen Unveränderliche, versionierte Konfigurationen; Nutzung der Containerinfrastruktur Komplexe Anwendungen verpacken und verteilen
Änderbarkeit Veränderlich Nicht veränderbar Veränderbar (Diagrammversionen sind unveränderlich, aber Werte können sich ändern)
Rollbacks Commits zurücksetzen oder Branches ändern Vorheriges Image-Tag bereitstellen Rollback zu einer vorherigen Diagrammversion durchführen
Tools Standard-Git-Clients, CI/CD-Pipelines Docker oder Podman, Container-Registries Helm-Befehlszeile, Helm-Repositories
Leistung Kann bei großen Repositories langsamer sein Schneller, insbesondere bei Skalierung Schnelles Abrufen aus einem Diagramm-Repository
Authentifizierung Flexibel (SSH, Token), kann komplexer einzurichten sein Vereinfacht mit der Identitätsföderation von Arbeitslasten für GKE (z. B. mit Artifact Registry) Vereinfacht mit der Identitätsföderation von Arbeitslasten für GKE (z. B. mit Artifact Registry)

Es ist auch möglich, für verschiedene Zwecke im selben Cluster unterschiedliche Quelltypen zu verwenden. Ein Cluster könnte beispielsweise Folgendes haben:

  • Ein RootSync, das aus einem Git-Repository synchronisiert wird, das grundlegende clusterweite Ressourcen und Richtlinien enthält, die vom Plattformteam verwaltet werden.
  • Ein RepoSync in einem bestimmten Namespace wird über ein Helm-Chart synchronisiert, um eine Redis-Instanz bereitzustellen, die von einem Anwendungsteam verwaltet wird.
  • Ein weiteres RepoSync in einem anderen Namespace, das über ein OCI-Image synchronisiert wird, das eine Reihe von anwendungsspezifischen Konfigurationen enthält, die von einem separaten CI/CD-Prozess erstellt wurden.

Nächste Schritte