Auf dieser Seite werden Konfigurationen (configs) beschrieben. Das sind die Dateien, die Config Sync aus Git liest und automatisch auf Ihre Cluster anwendet. Sie können eine Konfiguration erstellen und per Commit an Ihr Repository übertragen.
Config Sync synchronisiert Ihre registrierten Cluster mithilfe von Konfigurationen. Eine Konfiguration ist eine YAML- oder JSON-Datei, die in Ihrem Repository gespeichert ist und dieselben Konfigurationsdetails enthält, die Sie mit dem Befehl kubectl apply
manuell auf einen Cluster anwenden können. In diesem Thema wird erläutert, wie Konfigurationen funktionieren, wie sie geschrieben werden und wie sie mit Config Sync auf Ihre registrierten Cluster angewendet werden.
Config Sync wurde für Clusteroperatoren entwickelt, die viele Cluster verwalten. Wenn Sie Config Sync für die Verwaltung von Namespaces, Roles, RoleBindings, ResourceQuotas und anderen wichtigen Kubernetes-Objekten in Ihrer gesamten Flotte verwenden, können Sie gewährleisten, dass Ihre Cluster die geltenden Unternehmens- und Compliancestandards erfüllen. Sie können eine Konfiguration für jedes Kubernetes-Objekt erstellen, das in einem Cluster vorhanden sein kann.
Mit Konfigurationen arbeiten
Im folgenden Entscheidungsbaum werden die Ergebnisse verschiedener Konfigurationsänderungen in einer hypothetischen Gruppe von Clustern veranschaulicht, die von Config Sync verwaltet werden. Unter dem Diagramm werden einige hypothetische Aktionen von Clusteroperatoren und die Ergebnisse dieser Aktionen erläutert. Anhand dieser Beispiele wird die Funktionsweise von Config Sync beschrieben.
Dieser Cluster verwendet das Beispiel-Repository Der Cluster ist bereits beim Operator registriert.
Config Sync wendet Konfigurationen nur an, wenn mindestens eine der folgenden Bedingungen zutrifft:
- Im Repository ist eine relevante Konfiguration vorhanden.
- Die Annotation
configmanagement.gke.io/managed: enabled
wird auf das Kubernetes-Objekt angewendet.
Der Cluster
foo-corp
hat eine ClusterRole mit dem Namenpod-accountant
, die nicht mit der Annotationconfigmanagement.gke.io/managed: enabled
versehen ist. Im Repository ist keine Konfiguration für das ClusterRole-Objekt vorhanden. Config Sync konfiguriert die ClusterRolepod-accountant
nicht.Config Sync wendet eine relevante Änderung automatisch an, wenn sie dem Repository zugewiesen wird.
Ein Clusteradministrator weist der Datei
cluster/quota-viewer-clusterrole.yaml
im Repository eine Konfiguration zu. Diese Konfiguration definiert eine ClusterRole mit dem Namenquota-viewer
. Da die Konfiguration im Verzeichniscluster/
erstellt wird, sind alle registrierten Cluster betroffen. Config Sync erkennt die neu gespeicherte Konfiguration und wendet sie an. Die ClusterRolequota-viewer
ist jetzt im Cluster vorhanden, hat die Annotationconfigmanagement.gke.io/managed: enabled
und ist mit dem Inhalt vonquota-viewer-clusterrole.yaml
synchronisiert.Einige Zeit später wird die Datei
cluster/quota-viewer-clusterrole.yaml
aus dem Repository gelöscht. Config Sync erkennt diese Änderung und entfernt die ClusterRolequota-viewer
aus dem Cluster.Sie können mit dem Verwalten eines vorhandenen Objekts in einem Cluster beginnen, indem Sie die Annotation
configmanagement.gke.io/managed: enabled
hinzufügen.Der
foo-corp
-Cluster hat ein Namespace-Verzeichnis mit dem Namenshipping-dev
. In diesem Namespace-Verzeichnis ist eine Konfiguration für eine Rolle mit dem Namenjob-creator
vorhanden, die die Annotationconfigmanagement.gke.io/managed: enabled
enthält. Ein Nutzer aktualisiert die Dateinamespaces/dev/shipping-dev/job-creator-role.yaml
. Der Operator erkennt die Änderung und wendet sie an.Mit Config Sync können Sie Konfigurationsänderungen auf gruppierte hierarchische Weise auf Namespaces anwenden.
Der
foo-corp
-Cluster hat eine RoleBinding mit dem Namenpod-creator
und eine entsprechende/namespaces/pod-creator/pod-creator.yaml
-Datei im Repository. Das Diagramm zeigt, dassshipping-prod
,shipping-staging
undshipping-dev
Namespaces sind (sie haben jeweils einenamespace.yaml
-Datei, die einen Namespace definiert), die sich im abstrakten Namespace-Verzeichnisshipping-dev-backend
befinden. Jeder dieser Namespaces übernimmt die RoleBindingpod-creator
.Einige Zeit später ändert ein Nutzer die RoleBinding
pod-creator
im Namespace-Verzeichnisshipping-prod
. Der Operator erkennt die Änderung und aktualisiertpod-creator
entsprechend der Konfiguration im Repository.Irgendwann entfernt ein Nutzer die
pod-creator
-Konfiguration aus dem Repository. Config Sync erkennt die Änderung und entfernt die RoleBindingpod-creator
aus jedem der drei Namespaces.Mit Config Sync können Sie Änderungen manuell anwenden. Objekte werden nur dann verwaltet, wenn sie die Annotation
configmanagement.gke.io/managed: enabled
haben.Ein Nutzer erstellt manuell eine neue Rolle mit dem Namen
secret-admin
im Namespaceshipping-prod
. Im Repository ist keine Konfiguration für die Rollesecret-admin
vorhanden. Die Rollesecret-admin
hat nicht die Annotationconfigmanagement.gke.io/managed: enabled
. Config Sync führt keine Aktion aus.Einige Zeit später fügt ein Nutzer die
configmanagement.gke.io/managed:enabled
-Annotation manuell zursecret-admin
-Rolle hinzu. Im Repository ist noch keine entsprechende Konfiguration vorhanden. Daher löscht Config Sync die Rollesecret-admin
aus dem Namespace.Config Sync erstellt fehlende Namespaces, wenn für sie Konfigurationen vorhanden sind.
Ein Nutzer übergibt eine neue Konfiguration für den Namespace
audit
, der im Cluster nicht vorhanden ist. Config Sync erstellt denaudit
-Namespace im Cluster und wendet die Annotationconfigmanagement.gke.io/managed: enabled
darauf an.Config Sync kann Konfigurationen für einen Namespace verwalten, der die Annotation
configmanagement.gke.io/managed: enabled
nicht enthält.Der Namespace
shipping-dev
ist im Cluster vorhanden, enthält jedoch nicht die Annotationconfigmanagement.gke.io/managed: enabled
. Das Namespace-Verzeichnisshipping-dev
im Repository verfügt jedoch über eine RoleBinding mit dem Namenjob-creators
, die die Annotationconfigmanagement.gke.io/managed: enabled
enthält.Ein Nutzer fügt dem Repository eine Konfiguration für den Namespace
shipping-dev
hinzu, aber es gibt keine Konfiguration für die RoleBindingjob-creators
. Da für die RoleBinding keine Konfiguration vorhanden ist, die RoleBinding jedoch die Annotationconfigmanagement.gke.io/managed: enabled
hat, löscht Config Sync die RoleBinding.Später fügt ein Nutzer eine Konfiguration für die RoleBinding
job-creators
hinzu. Die RoleBindingjob-creators
wird mit den in der Konfiguration definierten Attributen neu erstellt.