Hierarchisches Repository verwenden

Auf dieser Seite wird beschrieben, wie Config Sync Konfigurationen aus einer hierarchischen Source of Truth liest und die resultierende Konfiguration automatisch auf Ihre Cluster anwendet.

Wenn Sie mehr strukturelle Flexibilität wünschen (z. B. Unterordner von Ressourcen erstellen möchten), können Sie eine unstrukturierte Source of Truth erstellen. Für die meisten Anwendungsfälle werden unstrukturierte Informationsquellen empfohlen. Wenn Sie bereits eine hierarchische „Source of Truth“ verwenden, können Sie sie in eine unstrukturierte Source of Truth umwandeln.

Wenn Sie verstehen möchten, wie Config Sync ein hierarchisches Repository verwendet, ist es hilfreich, wenn Sie mit Git-Repositories und der git-Befehlszeile vertraut sind.

Struktur des Verzeichnisses

Bei hierarchischen Quellen nutzt Config Sync dateisystemähnliche Strukturen und verwendet das Verzeichnis, um zu bestimmen, für welche Cluster oder Namespaces eine Konfiguration relevant ist.

namespaces/

Das Verzeichnis namespaces/ enthält Konfigurationsdateien für Namespaces und Namespace-bezogene Objekte. Die Struktur in namespaces/ ist der Mechanismus, der die Namespace-Übernahme fördert. Mithilfe eines NamespaceSelector können Sie einschränken, welche Namespaces eine Konfiguration erben dürfen.

cluster/

Das Verzeichnis cluster/ enthält Konfigurationsdateien, die für ganze Cluster gelten, statt für einzelne Namespaces. Standardmäßig gilt jede Konfiguration im Verzeichnis cluster/ für jeden in Config Sync registrierten Cluster. Mit einem ClusterSelector können Sie festlegen, auf welche Cluster sich eine Konfiguration auswirken soll.

clusterregistry/

Das Verzeichnis clusterregistry/ ist optional und enthält Konfigurationen für ClusterSelectors. ClusterSelectors schränken ein, auf welche Cluster eine Konfiguration angewendet wird. Sie werden in Konfigurationen in den Verzeichnissen cluster/ und namespaces/ referenziert.

system/

Das Verzeichnis system/ enthält Konfigurationen für den Operator.

Beispiel für eine hierarchische Informationsquelle

Die folgende Verzeichnisstruktur zeigt, wie Sie mit einer hierarchischen Datenquelle von Config Sync einen Kubernetes-Cluster konfigurieren, der von zwei verschiedenen Teams, team-1 und team-2, gemeinsam genutzt wird.

  • Jedes Team hat einen eigenen Kubernetes-Namespace, ein Kubernetes-Dienstkonto, Ressourcenkontingente, Netzwerkrichtlinien und Rollenbindungen.
  • Der Clusteradministrator richtet in namespaces/limit-range.yaml eine Richtlinie ein, um Ressourcenzuweisungen (auf Pods oder Container) in beiden Namespaces einzuschränken.
  • Der Clusteradministrator richtet auch ClusterRoles und ClusterRoleBindings ein.

Eine gültige hierarchische Config Sync-Quelle muss drei Unterverzeichnisse enthalten: cluster/, namespaces/ und system/.

Das Verzeichnis cluster/ enthält Konfigurationsdateien, die für ganze Cluster (z. B. ClusterRole, ClusterRoleBinding) aber nicht für Namespaces gelten.

Das Verzeichnis namespaces/ enthält Konfigurationen für die Namespace-Objekte und die Namespace-bezogenen Objekte. Jedes Unterverzeichnis unter namespaces/ enthält die Konfigurationen für ein Namespace-Objekt und alle Namespace-bezogenen Objekte im Namespace. Der Name eines Unterverzeichnisses muss mit dem Namen des Namespace-Objekts übereinstimmen. Namespace-bezogene Objekte, die in jedem Namespace erstellt werden müssen, können direkt unter namespaces/ platziert werden (z. B. namespaces/limit-range.yaml).

Das Verzeichnis system/ enthält Konfigurationen für den ConfigManagement Operator.

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   └── clusterrole-secret-reader.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

Namespace-Übernahme und abstrakte Namespaces verwenden

Bei einer hierarchischen „Source of Truth“ können Sie das Konzept der Namespace-Übernahme verwenden, um Konfigurationen automatisch auf Namespace-Gruppen in allen Clustern anzuwenden, in denen diese Namespaces vorhanden sind (oder vorhanden sein sollten).

Die Namespace-Übernahme gilt für das Verzeichnis namespaces/ des hierarchischen Repositorys und alle seine Unterverzeichnisse. Für Konfigurationen in anderen Verzeichnissen des Repository, z. B. cluster/, gelten die Übernahmeregeln nicht.

In einer hierarchischen Informationsquelle kann das Verzeichnis namespaces/ zwei verschiedene Arten von Unterverzeichnissen enthalten:

  • Ein Namespace-Verzeichnis enthält eine Konfiguration für einen Namespace. Der Name der Datei mit der Konfiguration ist beliebig, die Konfiguration muss aber kind: Namespace beinhalten. Ein Namespace-Verzeichnis kann auch Konfigurationen für andere Arten von Kubernetes-Objekten enthalten. Ein Namespace-Verzeichnis darf keine Unterverzeichnisse haben. Eine Namespace-Konfiguration steht für einen tatsächlichen Namespace in einem Cluster.

  • Ein abstraktes Namespace-Verzeichnis enthält Namespace-Verzeichnisse. Es können darin auch Konfigurationsdateien für andere Kubernetes-Objekte vorhanden sein, aber keine direkten Konfigurationen für einen Namespace. Ein abstraktes Namespace-Verzeichnis stellt kein Objekt in einem Kubernetes-Cluster dar, die untergeordneten Namespace-Verzeichnisse jedoch schon.

Damit Ihre Namespace- und abstrakten Namespace-Quellen den richtigen Konfigurations- und Strukturtyp haben, wird bei Problemen der Fehler KNV1003: IllegalNamespaceSubdirectoryError ausgegeben.

Konfigurationen in einem Namespace-Verzeichnis gelten nur für diesen Namespace. Konfigurationen in einem abstrakten Namespace-Verzeichnis werden jedoch auf alle untergeordneten Namespace-Verzeichnisse des abstrakten Namespace angewendet oder auf die untergeordneten Namespaces, die dem NamespaceSelector einer Konfiguration entsprechen, sofern vorhanden.

Die Übernahme einer Konfiguration aus dem Verzeichnis namespaces/ basiert hauptsächlich auf ihrer Position innerhalb der Verzeichnisstruktur in der „Source of Truth“. Wenn Sie wissen möchten, welche Konfigurationen auf einen bestimmten Namespace in einem bestimmten Cluster angewendet werden, können Sie das Beispiel-Repository für die Namespace-Übernahme durchsuchen.

Eingeschränkte Namespaces

config-management-system ist ein eingeschränkter Namespace. Sie können ihn nicht als abstraktes Namespace-Verzeichnis verwenden. Sie können einen config-management-system-Namespace definieren, aber der einzige zulässige Ressourcentyp für den config-management-system-Namespace ist RootSync.

Änderungen an Ihrer Datenquellen vornehmen

Wenn Sie eine Änderung an der „Source of Truth“ vornehmen, durch die Namespace-Verzeichnisse im Verzeichnis namespaces/ erstellt oder gelöscht werden, kann es je nach Aktion zu unerwarteten Ergebnissen kommen:

  • Verzeichnis erstellen: Wenn für eine gültige namespaces/-Hierarchie ein Commit für die „Source of Truth“ festgelegt wird, erstellt Config Sync Namespaces und in diesen Namespaces Kubernetes-Objekte für jede Konfiguration, die das Namespace-Verzeichnis enthält oder übernimmt.
  • Verzeichnis löschen: Das Löschen eines Namespace-Verzeichnisses ist ein destruktiver Vorgang. Der Namespace und sein Inhalt werden auf jedem von Config Sync verwalteten Cluster gelöscht, in dem sich der Namespace befindet. Wenn Sie ein abstraktes Namespace-Verzeichnis mit untergeordneten Namespace-Verzeichnissen löschen, werden alle diese Namespaces und ihre Inhalte aus jedem von Config Sync verwalteten Cluster gelöscht.
  • Verzeichnis umbenennen: Beim Umbenennen eines Namespace-Verzeichnisses werden zuerst Daten gelöscht, die anschließend neu erstellt werden. Dies gilt als destruktiver Vorgang. Das Umbenennen eines abstrakten Namespace-Verzeichnisses hat keine extern sichtbaren Auswirkungen.

  • Verzeichnis verschieben: Durch das Verschieben eines Namespace oder eines abstrakten Namespace-Verzeichnisses innerhalb von namespaces/ werden der Namespace oder die darin enthaltenen Objekte nicht gelöscht, es sei denn, der Namespace übernimmt aufgrund einer Änderung in der Hierarchie die Übernahme einer Konfiguration von einem abstrakten Namespace-Verzeichnis.

Nächste Schritte