Konfigurationen – Übersicht

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.

Beispielhafter Entscheidungsbaum zur Veranschaulichung von Aktionen und Ergebnissen mit Config Sync

  • 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 Namen pod-accountant, die nicht mit der Annotation configmanagement.gke.io/managed: enabled versehen ist. Im Repository ist keine Konfiguration für das ClusterRole-Objekt vorhanden. Config Sync konfiguriert die ClusterRole pod-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 Namen quota-viewer. Da die Konfiguration im Verzeichnis cluster/ erstellt wird, sind alle registrierten Cluster betroffen. Config Sync erkennt die neu gespeicherte Konfiguration und wendet sie an. Die ClusterRole quota-viewer ist jetzt im Cluster vorhanden, hat die Annotation configmanagement.gke.io/managed: enabled und ist mit dem Inhalt von quota-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 ClusterRole quota-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 Namen shipping-dev. In diesem Namespace-Verzeichnis ist eine Konfiguration für eine Rolle mit dem Namen job-creator vorhanden, die die Annotation configmanagement.gke.io/managed: enabled enthält. Ein Nutzer aktualisiert die Datei namespaces/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 Namen pod-creator und eine entsprechende /namespaces/pod-creator/pod-creator.yaml-Datei im Repository. Das Diagramm zeigt, dass shipping-prod, shipping-staging und shipping-dev Namespaces sind (sie haben jeweils eine namespace.yaml-Datei, die einen Namespace definiert), die sich im abstrakten Namespace-Verzeichnis shipping-dev-backend befinden. Jeder dieser Namespaces übernimmt die RoleBinding pod-creator.

    Einige Zeit später ändert ein Nutzer die RoleBinding pod-creator im Namespace-Verzeichnis shipping-prod. Der Operator erkennt die Änderung und aktualisiert pod-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 RoleBinding pod-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 Namespace shipping-prod. Im Repository ist keine Konfiguration für die Rolle secret-admin vorhanden. Die Rolle secret-admin hat nicht die Annotation configmanagement.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 zur secret-admin-Rolle hinzu. Im Repository ist noch keine entsprechende Konfiguration vorhanden. Daher löscht Config Sync die Rolle secret-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 den audit-Namespace im Cluster und wendet die Annotation configmanagement.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 Annotation configmanagement.gke.io/managed: enabled. Das Namespace-Verzeichnis shipping-dev im Repository verfügt jedoch über eine RoleBinding mit dem Namen job-creators, die die Annotation configmanagement.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 RoleBinding job-creators. Da für die RoleBinding keine Konfiguration vorhanden ist, die RoleBinding jedoch die Annotation configmanagement.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 RoleBinding job-creators wird mit den in der Konfiguration definierten Attributen neu erstellt.

Nächste Schritte