Konfigurationen zu Git-Repositories hinzufügen

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.

Wenn Config Sync diese Ressourcen verwaltet, werden Ihre registrierten Cluster mithilfe von Konfigurationen synchron gehalten. Eine Konfiguration ist eine YAML- oder JSON-Datei, die in einem Git-Repository gespeichert ist. Konfigurationen enthalten dieselben Konfigurationsdetails, die Sie mit dem Befehl kubectl apply manuell auf einen Cluster anwenden können. Sie können eine Konfiguration für jedes Kubernetes-Objekt erstellen, das in einem Cluster vorhanden sein kann. Warnung: Einige Kubernetes-Objekte, z. B. Secrets, enthalten vertrauliche Informationen, die möglicherweise nicht in einem Git-Repository gespeichert werden sollten. Sie sich gut überlegen, ob Sie diese Objekttypen mit Config Sync verwalten möchten.

Sie können Config Sync auch mit Config Connector verwenden, um Konfigurationen für Google Cloud-Ressourcen zu synchronisieren. Weitere Informationen zur Arbeit mit Config Connector finden Sie unter Google Cloud-Ressourcen mit Config Connector verwalten. Sie können die Installation von Config Sync und Config Connector vereinfachen, indem Sie Config Controller einrichten.

Auf dieser Seite erfahren Sie, wie Sie Konfigurationen zu Ihren Repositories hinzufügen. Informationen zum Erstellen einer Konfiguration finden Sie unter Konfigurationen erstellen.

Organisation von Konfigurationen auswählen

Config Sync verwendet ein Git-Repository zur Konfigurationsspeicherung und -versionsverwaltung. Es gibt zwei verschiedene Formate für ein Repository: unstrukturiert und hierarchisch.

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 oder generieren. Ein Beispiel für die Organisation Ihrer Konfigurationen finden Sie unter Beispielformat für ein unstrukturiertes Repository.

Das hierarchische oder strukturierte Quellformat unterteilt Konfigurationen in verschiedene Kategorien, damit Sie die Konfigurationen organisieren können. Die Kategorien sind Systemkonfiguration, Clustermetadaten, Clusterebene und Namespace-Konfiguration. Weitere Informationen zur Struktur des hierarchischen Repositorys finden Sie unter Struktur des hierarchischen Repositorys.

Für die meisten Nutzer ist das unstrukturierte Format empfehlenswert. Außerdem müssen Namespace-Repositories das unstrukturierte Repository-Format verwenden.

Unterstützte Features für unstrukturierte und hierarchische Repositories

In der folgenden Tabelle werden die Unterschiede zwischen den unstrukturierten und hierarchischen Formaten hervorgehoben:

Features Unstrukturiertes Format (empfohlen) Hierarchisches Format
Wird als Format für ein Stamm-Repository verwendet Unterstützt Unterstützt
Wird als Format für ein Namespace-Repository verwendet Unterstützt Nicht unterstützt
Wird zusammen mit dem Hierarchy Controller verwendet Unterstützt Nicht empfohlen
Cluster selectors Unterstützt Unterstützt
Namespace selectors Unterstützt Unterstützt
Befehl nomos hydrate Unterstützt mit dem Flag --source-format=unstructured Unterstützt
Befehl nomos init Nicht unterstützt Unterstützt
Befehl nomos vet Unterstützt mit dem Flag --source-format=unstructured Unterstützt
Alle anderen nomos-Befehle Unterstützt Unterstützt
Abstrakte Namespaces Nicht unterstützt Unterstützt
Repo objects Nicht unterstützt Unterstützt
HierarchyConfig-Objekte Nicht unterstützt Unterstützt
Hierarchische Namespaces im Hierarchy Controller Unterstützt Nicht unterstützt

Konfigurationen zu Ihrem Repository hinzufügen

Wenn Sie ein unstrukturiertes Repository erstellen, können Sie sofort Konfigurationen hinzufügen. Wenn Sie ein hierarchisches Repository erstellen, verwenden Sie den Befehl nomos init, um das Repository zu initialisieren, oder erstellen Sie die Verzeichnisstruktur manuell.

Leere Verzeichnisse können nicht an ein Git-Repository übergeben werden. Erstellen Sie daher vor der Konfiguration von Config Sync Konfigurationen und fügen Sie sie Ihrem Repository hinzu.

Nachdem Sie das Repository erstellt und Konfigurationen hinzugefügt haben, prüfen Sie mit dem Befehl nomos vet die Struktur Ihres Repositorys und die Syntax und Gültigkeit Ihrer Konfigurationen.

Config Sync zum Lesen aus dem Repository konfigurieren

Nachdem Sie ein Repository erstellt und Ihre Konfigurationen darin gespeichert haben, können Sie Config Sync für das Lesen aus dem Repository konfigurieren. Wenn Sie diesen Schritt abgeschlossen haben, synchronisiert Config Sync Konfigurationen aus Ihrem Repository mit Ihren Clustern.

Sie konfigurieren den Speicherort des Repositorys bei der Installation von Config Sync und können die Konfiguration von Config Sync später bearbeiten. Zusätzlich zum Speicherort des Repositorys können Sie einen Git-Zweig und ein Unterverzeichnis angeben, die überwacht werden sollen, wenn das Git-Repository andere Inhalte als Konfigurationen enthält.

Wenn Sie ein hierarchisches Repository verwenden und Config Sync manuell mit kubectl installieren, legen Sie die Konfiguration des Operators nicht im Verzeichnis system/ fest oder in einem der anderen reservierten Verzeichnisse wie cluster/ oder namespaces/. Wenn Sie die Konfiguration in einem der reservierten Verzeichnisse platzieren, schlägt nomos vet fehl und protokolliert einen Fehler wie KNV1033: IllegalSystemResourcePlacementError, KNV1038: IllegalKindInNamespacesError oder KNV1039: IllegalKindInClusterError.

Sie können Nutzern Zugriff auf das Deployment-Repository eines bestimmten Produktteams gewähren. Wenn Sie einer Person jedoch Zugriff auf ein Deployment-Repository gewähren, erhält diese Person auch dieselbe RBAC wie der Abgleicher, der für dieses Repository ausgeführt wird.

Informationen zum Konfigurieren der Authentifizierung und Autorisierung zwischen Config Sync und dem Repository finden Sie im Installationsschritt zum Konfigurieren des git-creds-Secrets.

Objektmutationen ignorieren

Wenn Sie nicht möchten, dass Config Sync den Status des Objekts in einem Cluster behält, nachdem es vorhanden ist, können Sie dem Objekt die Annotation client.lifecycle.config.k8s.io/mutation: ignore hinzufügen, dass Config Sync Mutationen ignorieren soll. Um die Annotation zu verwenden, müssen Sie die Synchronisierung aus mehreren Repositories aktivieren und eine Version von 1.7.0 oder höher verwenden. Die Synchronisierung aus mehreren Repositories ist standardmäßig aktiviert, wenn Sie Config Sync mit der Version 1.7.0 oder höher mit der Google Cloud Console oder mit dem Google Cloud CLI installiert haben. Wenn Sie Config Sync mit kubectl installiert haben, legen Sie spec.enableMultiRepo in Ihrem ConfigManagement-Objekt auf true fest.

Das folgende Beispiel zeigt, wie Sie die Annotation einem Objekt hinzufügen:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore 

Sie können diese Annotation nicht manuell für verwaltete Objekte im Cluster ändern.

Nächste Schritte