Hierarchisches Repository verwenden

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

Wenn Sie mehr Flexibilität bei der Struktur wünschen, z. B. wenn Sie Unterordner von Ressourcen erstellen möchten, können Sie eine unstrukturierte "Source of Truth" erstellen. Für die meisten Anwendungsfälle werden unstrukturierte "Source of Truth" empfohlen. Wenn Sie bereits eine hierarchische „Source of Truth“ verwenden, können Sie sie in eine unstrukturierte „Source of Truth“ konvertieren.

Wenn Sie wissen möchten, wie Config Sync ein hierarchisches Repository verwendet, sollten Sie mit Git-Repositories und der git-Befehlszeile vertraut sein.

Struktur des Verzeichnisses

Bei hierarchischen Quellen nutzt Config Sync dateisystemähnliche Strukturen und ermittelt anhand des Verzeichnisses, 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 "Source of Truth"

Die folgende Verzeichnisstruktur zeigt, wie Sie mit einer hierarchischen "Source of Truth" von Config Sync einen Kubernetes-Cluster konfigurieren, der von zwei verschiedenen Teams freigegeben wird: team-1 und team-2.

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

Eine gültige hierarchische Config Sync-Source 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 Config Sync 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

Mit 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 bzw. 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 "Source of Truth" 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.

Um sicherzustellen, dass Ihre Namespace- und abstrakten Namespace-Sources den richtigen Typ von Konfigurationen und die richtige Struktur haben, wird bei einem Problem der Fehler KNV1003: IllegalNamespaceSubdirectoryError gemeldet.

Konfigurationen in einem Namespace-Verzeichnis gelten nur für diesen Namespace. Konfigurationen in einem abstrakten Namespace-Verzeichnis werden hingegen auf alle untergeordneten Namespace-Verzeichnisse des abstrakten Namespace angewendet (oder auf untergeordnete Namespaces, die einem möglicherweise vorhandenen NamespaceSelector einer Konfiguration entsprechen).

Die Übernahme einer Konfiguration im namespaces/-Verzeichnis basiert hauptsächlich auf der Position in 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 "Source of Truth" vornehmen

Wenn Sie eine Änderung in 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 eine gültige namespaces/-Hierarchie der "Source of Truth" übergeben 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 in 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 in jedem von Config Sync verwalteten Cluster gelöscht.

  • Verzeichnis umbenennen: Das Umbenennen eines Namespace-Verzeichnisses besteht aus einem Löschvorgang, gefolgt von einem Erstellvorgang. Dieser Vorgang gilt als destruktiver Vorgang. Wenn Sie ein abstraktes Namespace-Verzeichnis umbenennen, hat dies keine extern sichtbaren Auswirkungen.

  • Ein Verzeichnis verschieben: Durch das Verschieben eines Namespace oder eines abstrakten Namespace-Verzeichnisses innerhalb von namespaces/ werden der Namespace bzw. die darin enthaltenen Objekte nicht gelöscht – es sei denn, der Vorgang wirkt sich durch eine Änderung in der Hierarchie auf die Übernahme einer Konfiguration von einem abstrakten Namespace-Verzeichnis aus.

Nächste Schritte