Config Sync im Überblick

Config Sync ist ein Open-Source-Tool, mit dem Clusteroperatoren und Plattformadministratoren konsistente Konfigurationen und Richtlinien bereitstellen können. Sie können diese Konfigurationen und Richtlinien in einzelnen Kubernetes-Clustern, in mehreren Clustern, die Hybrid- und Multi-Cloud-Umgebungen umfassen können, und in mehreren Namespaces in Clustern bereitstellen. Dieser Prozess vereinfacht und automatisiert eine 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 unter Konfigurationen zu einem Git-Repository hinzufügen und Konfigurationen 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. In Config Sync können Sie mithilfe seiner Git-Referenz (eine Git-URL, einen -Repository-Zweig, ein -Commit oder ein -Tag und ein Verzeichnis) auf jedes Repository verweisen. Diese Konfiguration entkoppelt den Lebenszyklus der Konfigurationsbereitstellung für verschiedene Teams. Es bietet Ihnen auch mehr Flexibilität bei der Auswahl, wo Sie das Repository speichern und wie Sie es strukturieren möchten.

Sie können zwei Arten von Repositorys erstellen: Stamm-Repositories und Namespace-Repositories:

  • Stamm-Repositories: Mit Root-Repositories können Sie clusterbezogene und Namespace-bezogene Konfigurationen synchronisieren. Stamm-Repositories verwenden Anmeldedaten auf Administratorebene, um Richtlinien für Anwendungs-Namespaces zu erzwingen und lokale Änderungen zu überschreiben, die von dem in Ihren Konfigurationen angegebenen Status abweichen. Stamm-Repositories werden normalerweise von einem zentralen Administrator gesteuert.

    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. Unstrukturiert ist das empfohlene Format für die meisten Nutzer und das Standardformat bei der Konfiguration von Config Sync über die Google Cloud Console. 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. Hierarchisch ist das Standard-Repository-Format für Config Sync, wenn Sie in Ihrem Manifest keine sourceFormat angeben. Weitere Informationen finden Sie unter Hierarchisches Repository – Übersicht.

    Informationen zum Konfigurieren von Stamm-Repositorys finden Sie unter Config Sync installieren.

  • 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.

Das folgende Diagramm bietet einen Überblick darüber, wie Teams ihre Cluster mit einem einzelnen Stamm-Repository (von einem Administrator verwaltet) und mehreren Namespace-Repositories (von Anwendungsoperatoren verwaltet) synchronisieren können:

Ein zentraler Administrator, der mehrere Konfigurationen steuert und Anwendungsoperatoren, die ihre eigenen Namespace-Konfigurationen steuern.

Im obigen Diagramm verwaltet ein zentraler Administrator die zentralisierte Infrastruktur für die Organisation und erzwingt Richtlinien auf dem Cluster und für alle Namespaces in der Organisation. Die Anwendungsoperatoren, die für die Verwaltung von Live-Bereitstellungen zuständig sind, wenden Konfigurationen auf die Anwendungen in den Namespaces an, mit denen sie arbeiten.

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 nomos-Befehlszeilentool verwenden.

Config Sync RBAC / Berechtigungen

In den folgenden Abschnitten werden die Berechtigungen für Config Sync und deren Komponenten für den korrekten Zugriff auf Clusterebene aufgeführt. Die aufgeführten Berechtigungen sind standardmäßig aktiviert und sollten nicht deaktiviert werden, während Config Sync arbeitet.

Komponenten Namespace Dienstkonto Berechtigungen Beschreibung
reconciler-manager config-management-system reconciler-manager Clusteradministrator Der Abgleichermanager muss Clusteradministrator sein, um die Root-Abgleicher bereitzustellen und die ClusterRoleBinding für die Root-Abgleicher zu erstellen.
root reconcilers config-management-system Name des Root-Abgleichers Clusteradministrator Die Root-Abgleicher müssen Clusteradministrator sein, um clusterbezogene und benutzerdefinierte Ressourcen anwenden zu können.
namespace reconcilers config-management-system Name des Namespace-Abgleichers configsync.gke.io:ns-Abgleicher Die Namespace-Abgleicher benötigen die Berechtigung zum Abrufen oder Aktualisieren der RepoSync- und ResourceGroup-Objekte und deren Status
resource-group-controller-manager config-management-system resource-group-sa resource-group-manager-role resource-group-leader-election-role Der Ressource Group Controller-Manager benötigt die Rollen, um den Objektstatus zu prüfen und die Leader-Auswahl zu aktivieren.
admission-webhook config-management-system admission-webhook Clusteradministrator Der Zulassungs-Webhook muss Clusteradministrator sein, um Anfragen an jedes Objekt im Cluster ablehnen zu können.
importer config-management-system Importeur Clusteradministrator Der Importeur muss Clusteradministrator sein, um RBAC-Berechtigungen festzulegen, da der Nutzer eine Berechtigung zum Festlegen haben muss.

RBAC für Namespace-Abgleicher

Die folgenden API-Definitionen zeigen Zugriffssteuerungsberechtigungen für Namespace-Abgleicher.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: configsync.gke.io:ns-reconciler
  labels:
    configmanagement.gke.io/system: "true"
    configmanagement.gke.io/arch: "csmr"
rules:
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs"]
  verbs: ["get"]
- apiGroups: ["configsync.gke.io"]
  resources: ["reposyncs/status"]
  verbs: ["get","list","update"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups"]
  verbs: ["*"]
- apiGroups: ["kpt.dev"]
  resources: ["resourcegroups/status"]
  verbs: ["*"]
- apiGroups:
  - policy
  resources:
  - podsecuritypolicies
  resourceNames:
  - acm-psp
  verbs:
  - use

RBAC für Resource Group Controller

Die folgenden API-Definitionen zeigen Zugriffssteuerungsberechtigungen für Ressource Group Controller.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-manager-role
rules:
# This permission is needed to get the status for managed resources
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch
# This permission is needed to watch/unwatch types as they are registered or removed.
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - list
  - watch
# This permission is needed so that the ResourceGroup controller can reconcile a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
# This permission is needed so that the ResourceGroup controller can update the status of a ResourceGroup CR
- apiGroups:
  - kpt.dev
  resources:
  - resourcegroups/status
  verbs:
  - get
  - patch
  - update
# This permission is needed so that the ResourceGroup controller can work on a cluster with PSP enabled
- apiGroups:
  - policy
  resourceNames:
  - acm-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    configmanagement.gke.io/arch: "csmr"
    configmanagement.gke.io/system: "true"
  name: resource-group-leader-election-role
  namespace: resource-group-system
rules:  // The following permissions are needed so that the leader election can work
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - configmaps/status
  verbs:
  - get
  - update
  - patch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - '*'

Nächste Schritte