Config Sync im Überblick

Mit Config Sync können Clusterbetreiber und Plattformadministratoren konsistente Konfigurationen und Richtlinien bereitstellen. Sie können diese Konfigurationen und Richtlinien in einzelnen Kubernetes-Clustern, mehreren Clustern, die Hybrid- und Multi-Cloud-Umgebungen umfassen können, und mehreren Namespaces in Clustern bereitstellen. Dieser Prozess vereinfacht und automatisiert die umfangreiche Konfigurations- und Richtlinienverwaltung. Mit Config Sync können Entwicklerteams außerdem ihre Namespaces in Clustern unabhängig verwalten und gleichzeitig die von Administratoren festgelegten Richtlinienmaßnahmen berücksichtigen.

Mithilfe derselben Prinzipien wie Kubernetes selbst vergleicht Config Sync den Status registrierter Cluster kontinuierlich mit einem zentralen Satz von deklarativen Kubernetes-Konfigurationsdateien, die als Konfigurationen bezeichnet werden. Konfigurationen werden in einem oder mehreren Git-Repositories gespeichert. Mit Config Sync bleiben sie mit den konfigurierten Kubernetes-Objekten konsistent. Mit diesem GitOps-Ansatz (manchmal auch als Konfiguration als Code bezeichnet) können Sie gängige Konfigurationen mit einem Prozess verwalten und bereitstellen, der überprüfbar, transaktional und versionsverwaltet ist.

Im folgenden Diagramm erstellt ein Plattformadministrator konsistente Konfigurationen für drei verschiedene Cluster. Dazu wendet er Konfigurationen auf die Cluster und Namespaces im Cluster an:

Ein Plattformadministrator stellt mehrere Konfigurationen für seine Cluster bereit

Vorteile von Config Sync

Die folgenden Beispiele zeigen einige der Vorteile von Config Sync:

  • Reduzieren des Risikos von "Shadow Ops": Wenn ungeprüfte Änderungen auf Live-Cluster übertragen werden kann es schwierig sein, die Unterschiede zwischen der dokumentierten Konfiguration und Ihrer Live-Umgebung zu verstehen. Sie können festlegen, dass alle Änderungen an der Clusterkonfiguration mit Config Sync übernommen werden müssen, der direkte Zugriff auf die Kubernetes API gesperrt ist und Änderungen in Git zu ihren wahren Quellen zurückverfolgbar sein müssen.
  • Best Practices für GitOps verwenden: Bevor Änderungen auf die Live-Umgebung übertragen werden, können Sie Codeprüfungen mit Ihren bevorzugten Verwaltungstools für Repositories erzwingen. Verwenden Sie Config Sync, um genau zu prüfen, welcher Commit-Vorgang eine Konfigurationsänderung verursacht hat.
  • Weniger Ausfallzeiten aufgrund konfigurationsbedingter Ausfälle: Mit Config Sync können Sie eine "Zurücksetzen, dann untersuchen"-Strategie nutzen, um Änderungen rückgängig zu machen und Ihre Live-Cluster wieder in einen funktionsfähigen Zustand versetzen, bevor Sie die problematische Änderung korrigieren und sie als neuen Commit anwenden.
  • CI/CD-Pipelines (Continuous Integration/Continuous Deployment) verwenden: Sie können einen CI/CD-Workflow verwenden, um Konfigurationen mit beliebigen Tools und Formaten zu erzwingen, Ihre Änderungen zu testen und zu prüfen und nach erfolgreichen Tests automatisch zu übergeben. Config Sync wendet dann die Änderungen an und überwacht und behebt den Konfigurations-Drift.

Config Sync verstehen

Vorbereitung

Config Sync verwendet Namespaces, Labels und Annotationen als Kernelemente seiner Implementierung. Es ist hilfreich, diese Konzepte gut zu verstehen, bevor Sie mit der Verwendung des Produkts beginnen.

Cluster konfigurieren

Mit Config Sync können Sie gemeinsame Richtlinien auf Konfigurations- und Clusterebene erstellen, z. B. Einschränkungen für Policy Controller, und diese einheitlich auf registrierte und verbundene Cluster aus einer Single Source Of Truth in Git anwenden. Bevor Sie einen Cluster konfigurieren können, müssen Sie eine Konfiguration und ein Repository erstellen.

Konfigurationen

Eine Konfiguration ist eine in YAML oder JSON geschriebene Deklaration einer Kubernetes-Konfiguration. Config Sync liest und wendet die Konfiguration auf einen oder mehrere Cluster an, um ein Kubernetes-Objekt oder eine Kubernetes-Ressource in diesen Clustern zu erstellen oder zu konfigurieren oder um von Config Sync selbst benötigte Informationen bereitzustellen. Eine Konfiguration kann alle Konfigurationsdetails enthalten, die Sie mit kubectl edit oder kubectl apply auf einen Kubernetes-Cluster anwenden können. Sie können auch mehrere Konfigurationen in einer einzigen Datei deklarieren. Config Sync liest drei Dateitypen: .yaml, .yml und .json. Dateien mit anderen Suffixen werden ignoriert.

Bevor Sie eine Konfiguration schreiben, sollten Sie sich mit dem Kubernetes-Objekt vertraut machen, für das Sie die Konfiguration schreiben.

Weitere Informationen finden Sie in der Konfigurationsübersicht und unter Kubernetes-Objekte konfigurieren. Hier erfahren Sie, wie Sie eine Konfiguration erstellen.

Repositories

Das Repository (oder Repo) ist das Git-Repository, in dem Konfigurationen gespeichert werden, einschließlich der Konfiguration für Config Sync selbst. Bei der Konfiguration von Config Sync konfigurieren Sie das Repository, den Zweig und das Unterverzeichnis, das von Config Sync auf Änderungen überwacht wird.

Mit Config Sync können Sie Konfigurationen aus mehreren Repositories mit demselben Clustersatz synchronisieren. Wenn Sie die Synchronisierung von mehreren Repositories aktivieren, erhalten Sie Zugriff auf zusätzliche Funktionen (z. B. Drift-Prävention und Ignorieren von Objektmutationen). Sie können diese Funktion aktivieren, auch wenn Sie nur ein Root-Repository und keine Namespace-Repositories nutzen möchten. Weitere Informationen finden Sie unter Aus mehreren Repositories synchronisieren.

Sie können ein Root-Repository und Namespace-Repositories erstellen:

  • Root-Repository: Mit diesem Repository können Sie clusterbezogene Namespace-Konfigurationen synchronisieren. Das Root-Repository setzt Anmeldedaten auf Administratorebene ein, um Richtlinien für Anwendungs-Namespaces zu erzwingen und lokale Änderungen zu überschreiben, die von dem in Ihren Konfigurationen angegebenen Status abweichen. Jeder Cluster kann nur ein Root-Repository haben, das in der Regel von einem zentralen Administrator gesteuert wird.

    Sie können zwei verschiedene Strukturen für Ihr Root-Repository verwenden:

    • Unstrukturiert: Mit dem unstrukturierten Quellformat können Sie die Konfigurationen in Ihrem Repository auf beliebige Weise organisieren. Dieses Format kann besonders nützlich sein, wenn Sie Konfigurationen mit einem Tool wie kustomize, kpt oder helm organisieren und/oder generieren. Für die meisten Nutzer ist das unstrukturierte Format empfehlenswert. Weitere Informationen finden Sie unter Unstrukturiertes Repository verwenden.

    • Hierarchisch: Bei dem hierarchischen oder strukturierten Quellformat werden Konfigurationen in verschiedene Kategorien wie Systemkonfiguration, Clustermetadaten, Konfiguration auf Clusterebene und Namespace-Konfiguration unterteilt, um Sie bei der Organisation der Konfigurationen zu unterstützen. Außerdem wird die hierarchische Übernahme der Konfiguration über mehrere Namespaces basierend auf der Verzeichnisstruktur unterstützt. Dies wird im Abschnitt Namespaces konfigurieren näher erläutert. Das hierarchische Format ist das Standard-Repository-Format für Config Sync. Weitere Informationen finden Sie unter Hierarchisches Repository – Übersicht.

  • Namespace-Repositories: Namespace-Repositories sind optional und können namespace-bezogene Konfigurationen enthalten, die mit einem bestimmten Namespace in mehreren Clustern synchronisiert werden. Sie können die Einrichtung und Kontrolle eines Namespace-Repositories an Nutzer ohne Administratorberechtigung delegieren. Namespace-Repositories müssen das unstrukturierte Repository-Format verwenden. Weitere Informationen finden Sie unter Synchronisierung von Namespace-Repositories konfigurieren.

Mehrere Cluster konfigurieren

Mit Config Sync können Sie konsistente Konfigurationen und Richtlinien über mehrere Cluster hinweg bereitstellen, die Hybrid- und Multi-Cloud-Umgebungen umfassen können.

Config Sync bietet Ihnen die folgenden Optionen, um mehrere Cluster zu konfigurieren:

  • Anstatt den kubectl apply-Befehl wiederholt auszuführen, können Sie die Bereitstellung von Konfigurationsänderungen auf Clustern über Git organisieren. Weitere Informationen finden Sie unter Sichere Rollouts mit Anthos Config Management.
  • Anhand von Metadaten, die Sie auf einzelne Cluster anwenden, können Sie dafür sorgen, dass eine Änderung nur auf die relevanten Cluster übertragen wird. Weitere Informationen finden Sie unter Nur eine Cluster-Teilmenge konfigurieren. Clustermetadaten werden für nicht strukturierte und hierarchische Repository-Formate etwas anders verwaltet.

Wir empfehlen dringend, Cluster zu registrieren. Das Registrieren Ihrer Cluster ermöglicht die Beobachtung des aktuellen Status aller Cluster über die Google Cloud Console und ermöglicht die zentralisierte Konfiguration und Verwaltung von Config Sync für registrierte Cluster. Weitere Informationen finden Sie unter Cluster registrieren ,Config Sync konfigurieren und Config Sync-Versionen aktualisieren.

Namespaces konfigurieren

Das Konfigurieren von Namespaces mit Config Sync bietet folgende Funktionen:

  • Sie können Kubernetes-Namespaces kontinuierlich mit Namespace-bezogenen Richtlinien wie RBAC-Rollen über registrierte und verbundene Cluster hinweg bereitstellen. Namespace-bezogene Richtlinien vereinfachen die Implementierung und Verwaltung der Mehrmandantenfähigkeit in Ihren Clustern.
  • Sie können Richtlinien auf mehrere verwandte Namespaces anwenden, ohne Konfigurationen duplizieren zu müssen. Außerdem können Sie eine Konfiguration für einen bestimmten Namespace oder eine Gruppe von Namespaces überschreiben oder erweitern, was die Durchsetzung einheitlicher Richtlinien für alle Mandanten erleichtert.

Diese Funktionen funktionieren in nicht strukturierten und hierarchischen Repository-Formaten unterschiedlich.

Mit unstrukturierten Repositories können Sie mit dem Hierarchie-Controller Richtlinien auf Namespace-Hierarchien verteilen, die Sie für Ihre Cluster definieren. Weitere Informationen finden Sie unter Hierarchy Controller – Übersicht.

Bei hierarchischen Repositories können Sie Gruppen von Namespaces verwenden, die als abstrakte Namespaces bezeichnet werden, um zu steuern, an welche Namespaces Richtlinien weitergegeben werden sollen. Für abstrakte Namespaces müssen Namespaces hierarchisch in der Verzeichnisstruktur des Repositorys organisiert werden. Weitere Informationen finden Sie unter Namespaces und Namespace-bezogene Objekte konfigurieren und Namespace-Übernahme – Übersicht.

Sowohl unstrukturierte als auch hierarchische Formate unterstützen auch die Verwendung nicht-hierarchischer Sätze von Namespaces mit Labelselektoren.

Der nomos-Befehl

Config Sync bietet eine API. Der Befehl nomos (nomos.exe unter Windows) nutzt die API, prüft den Status der Installation und validiert Konfigurationen.

Weitere Informationen finden Sie unter Den Nomos-Befehl verwenden.

Nächste Schritte