Zentrale Datenquellen

Mit Config Sync können Sie Kubernetes-Ressourcenbereitstellungen in Ihren Clustern von einer zentralen Source of Truth aus automatisieren und manuelle kubectl-Befehle ersetzen. In GitOps-Workflows ist eine „Source of Truth“ das zentrale Repository, in dem Sie YAML- oder JSON-Konfigurationsdateien speichern, die Ihre Clusterressourcen definieren. Config Sync überwacht dieses Repository kontinuierlich und wendet Änderungen automatisch auf Ihre Cluster an.

Sie können Konfigurationsdateien aus drei Arten von Quellen synchronisieren: Git-Repositories, OCI-Images (Open Container Initiative) und Helm-Diagramme. Wenn Sie wissen, wie Config Sync mit den einzelnen Quelltypen interagiert, können Sie die beste Option 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 Verzweigung nutzen. Da Git ausgereift ist und weithin unterstützt wird, stehen Ihnen eine Vielzahl von Optionen für Anbieter und Tools zur Verfügung.

Wenn Sie Config Sync mit einem Git-Repository als „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 Überarbeitung (Commit oder Tag) konfigurieren, um besser zu steuern, wo Konfigurationen in Ihrem Git-Repository abgerufen werden.

Beispiel für eine 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 Zweig main des Repositorys https://github.com/example/my-configs.git und sucht alle 60 Sekunden ohne Authentifizierung nach Aktualisierungen.

Anwendungsbeispiel: Zentrale 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 durchzusetzen. 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 Repository standard-configs erfolgt. So wird sichergestellt, dass alle Cluster von Anfang an den Organisationsstandards entsprechen.

OCI-Images

OCI-Images sind ein Standardformat zum 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 im großen Maßstab. 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 dann an eine Registry-Plattform wie Artifact Registry zu übertragen. Dieser Ansatz ist möglicherweise weniger direkt menschenlesbar 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 eine RootSync-Konfiguration

Das folgende Beispiel zeigt ein RootSync-Manifest, das mit 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 Image us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 aus Artifact Registry ab und verwendet zur Authentifizierung ein Kubernetes-Dienstkonto.

Beispielanwendungsfall: CI/CD-Pipeline-Einbindung

Angenommen, 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 eingebunden werden und das Image per Push an Artifact Registry übertragen wird. Config Sync würde dann die neue Version des Images automatisch 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 in Helm-Diagrammen definierte Ressourcen abrufen, rendern und synchronisieren.

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

Wenn Sie mit Helm noch nicht vertraut sind, können die Vorlagen- und Releaseprozesse Ihre Konfigurationsverwaltungspipeline zusätzlich verkomplizieren.

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. Anschließend wird das Diagramm gerendert, 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 eine RootSync-Konfiguration

Das folgende Beispiel zeigt ein RootSync-Manifest, das von 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.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 die 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 Releasenamen my-chart-release bereitgestellt.

Anwendungsbeispiel: Drittanbieteranwendung 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 ein vordefiniertes Helm-Diagramm abgerufen wird, 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 hält das Deployment dann mit der angegebenen Diagrammversion und den angegebenen Konfigurationen synchron.

Quelltyp auswählen

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

Funktion Git-Repository OCI-Image Helm-Diagramm
Optimal für Konfigurationsverwaltung für allgemeine Zwecke; Flexibilität; menschenlesbar Unveränderliche, versionierte Konfigurationen; Nutzung der Containerinfrastruktur Paketierung und Bereitstellung komplexer Anwendungen
Veränderlichkeit Veränderbar Nicht veränderbar Veränderlich (Diagrammversionen sind unveränderlich, aber Werte können sich ändern)
Rollbacks Commits rückgängig machen 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 großen Datenmengen 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 Quelltypen für unterschiedliche Zwecke im selben Cluster zu verwenden. Ein Cluster kann beispielsweise Folgendes enthalten:

  • 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, der von einem Helm-Diagramm synchronisiert wird, um eine von einem Anwendungsteam verwaltete Redis-Instanz bereitzustellen.
  • Ein weiteres RepoSync-Objekt in einem anderen Namespace, das aus einem OCI-Image synchronisiert wird, das eine Reihe anwendungsspezifischer Konfigurationen enthält, die von einem separaten CI/CD-Prozess erstellt wurden.

Nächste Schritte