Zentrale Datenquellen

In diesem Dokument werden die verschiedenen Arten von „Source of Truth“ erläutert, aus denen Config Sync synchronisiert werden 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, die Kubernetes-Ressourcen definiert. Normalerweise wenden Sie Kubernetes-Objekte manuell mit dem Befehlszeilentool kubectl an. Mit Config Sync können diese Ressourcen jedoch automatisch aus einer einzigen Source of Truth wie einem Git-Repository angewendet werden. 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 so organisieren, wie es Ihren Anforderungen entspricht, 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 Source of Truth konfigurieren, verwendet Config Sync einen git-sync-Container im Abgleich-Pod, um Konfigurationen aus dem Git-Repository abzurufen. Sie können die Repository-URL, den Branch und die Revision (Commit oder Tag) konfigurieren, um besser zu steuern, wo Konfigurationen in Ihrem Git-Repository abgerufen werden sollen.

Beispielkonfiguration für RootSync

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 Repositorys https://github.com/example/my-configs.git und sucht alle 60 Sekunden nach Updates, ohne Authentifizierung.

Anwendungsbeispiel: Zentralisierte Verwaltung

Stellen Sie sich vor, Sie sind ein Plattformadministrator, der ein Git-Repository verwenden möchte, um grundlegende Richtlinien 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 es aus dem Repository standard-configs synchronisiert wird. So wird sichergestellt, 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 als Artefakte behandelt, ähnlich wie Container-Images. Dieser Ansatz bietet Vorteile wie Unveränderlichkeit und schnellere Leistung bei der Skalierung. Mit OCI können Sie die Container-Image-Infrastruktur und -Tools wie Artifact Registry verwenden, um Ihre Images zu verwalten, und Workload Identity Federation for GKE, um die Authentifizierung zu vereinfachen.

Für die Verwendung von OCI als Konfigurationsquelle ist in der Regel ein separater Prozess erforderlich, um Ihre Konfigurationsdateien in ein OCI-Image zu erstellen und es dann in eine Registry-Plattform 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 Abgleich-Pod, um das OCI-Image mit den Konfigurationen aus der Registry abzurufen.

Beispielkonfiguration für RootSync

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 so eingerichtet, dass es aus einem OCI-Image synchronisiert wird. Config Sync ruft das Image us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 aus Artifact Registry ab und verwendet ein Kubernetes-Dienstkonto für die Authentifizierung.

Anwendungsbeispiel: CI/CD-Pipeline-Einbindung

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 ausgeführt werden (z. B. mit dem Befehl nomos vet), die YAML-Dateien in ein OCI-Image erstellt und das Image in Artifact Registry übertragen wird. Config Sync erkennt und wendet dann automatisch die neue Version des Images auf Ihre Cluster an. So wird sichergestellt, dass alle Konfigurationsänderungen validiert und versioniert bereitgestellt werden.

Helm-Diagramme

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

Helm bietet eine konsistente 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 mit Helm noch nicht vertraut sind, können die Vorlagen- und Releaseprozesse die Komplexität Ihrer Konfigurationsmanagement-Pipeline erhöhen.

Wenn Sie Config Sync mit einem Helm-Diagramm als Source of Truth konfigurieren, verwendet Config Sync einen helm-sync-Container im Abgleich-Pod, um Diagramme aus einem Helm-Repository (z. B. Artifact Registry) oder einem Git-Repository abzurufen und das Diagramm dann 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.

Beispielkonfiguration für RootSync

Das folgende Beispiel zeigt ein RootSync-Manifest, das aus einem in Artifact Registry gespeicherten Helm-Diagramm 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.s3ns.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 so eingerichtet, dass ein Helm-Diagramm aus einem OCI-Repository synchronisiert wird. 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.s3ns.iam.gserviceaccount.com. Die Ressourcen des Diagramms werden im Namespace my-app-namespace unter dem Release-Namen my-chart-release bereitgestellt.

Anwendungsbeispiel: Anwendung eines Drittanbieters bereitstellen

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 es aus einem vorgefertigten Helm-Diagramm abgerufen wird, das Prometheus bereitstellt. 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 Diagrammversion und den Konfigurationen.

Quellentyp auswählen

Der beste Quellentyp hängt von den vorhandenen Tools, Workflows und Einstellungen Ihres Teams ab. In dieser Tabelle finden Sie die wichtigsten Merkmale der einzelnen Quellentypen, damit Sie eine fundierte Entscheidung treffen können:

Funktion Git-Repository OCI-Image Helm-Diagramm
Optimal für Allgemeines Konfigurationsmanagement; Flexibilität; Lesbarkeit Unveränderliche, versionierte Konfigurationen; Nutzung der Containerinfrastruktur Verpacken und Bereitstellen komplexer Anwendungen
Veränderlichkeit Veränderbar Nicht veränderbar Veränderbar (Diagrammversionen sind unveränderlich, Werte können sich jedoch ändern)
Rollbacks Commits zurücksetzen oder Branches ändern Vorheriges Image-Tag bereitstellen Rollback zu einer vorherigen Diagrammversion
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 der Skalierung Schnell beim Abrufen aus einem Diagramm-Repository
Authentifizierung Flexibel (SSH, Token), Einrichtung kann komplexer sein Vereinfacht mit Workload Identity Federation for GKE (z. B. mit Artifact Registry) Vereinfacht mit Workload Identity Federation for GKE (z. B. mit Artifact Registry)

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

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

Nächste Schritte