Mit einem unstrukturierten Repository können Sie Ihr Repository so organisieren, wie es für Sie am praktischsten ist. Dank dieser Flexibilität können Sie Ihre vorhandene Kubernetes-Konfiguration mit Ihrem Config Sync-Repository synchronisieren. Wenn Sie beispielsweise ein Helm-Diagramm mit Ihrem Cluster synchronisieren möchten, können Sie den helm template
-Befehl ausführen und einen Commit für das gerenderte Manifest zu Ihrem Repository durchführen. Weitere Informationen finden Sie in der Anleitung Config Sync mit Helm verwenden.
Für die meisten Nutzer werden unstrukturierte Repositories empfohlen. Sie können aber auch ein hierarchisches Repository erstellen, um Konfigurationen in unterschiedliche Kategorien zu trennen. Wenn Sie hierarchische Richtlinien erstellen möchten, ohne den Regeln des hierarchischen Repositorys zu entsprechen, können Sie Hierarchy Controller verwenden.
Beschränkungen
Unstrukturierte Repositories unterliegen den folgenden Einschränkungen:
Sie können in einem unstrukturierten Repository nicht die Kubernetes-Objekte
Repo
undHierarchyConfig
verwenden.Abstrakte Namespaces werden in unstrukturierten Repositories nicht unterstützt.
Wenn Sie den Befehl
nomos vet
verwenden, fügen Sie das Flag--source-format=unstructured
hinzu. Beispiel:nomos vet --source-format=unstructured
Namespace-bezogene Objekte
Sie können in einem unstrukturierten Repository NamespaceSelectors deklarieren. Um einen NamespaceSelector zu deklarieren, fügen Sie entweder die Annotation metadata.namespace
oder die Annotation NamespaceSelector
hinzu. Die Angabe beider Annotationen ist ungültig. Wenn in namespace-bezogenen Ressourcen metadata.namespace
oder die Annotation NamespaceSelector
nicht deklariert wird, verwendet Config Sync den „Standard“-Namespace des Clusters.
Weitere Informationen finden Sie unter Begrenzen, auf welche Namespaces sich eine Konfiguration auswirkt.
Clusterbezogene Objekte
In einem unstrukturierten Repository funktioniert die ClusterSelectors
-Funktion normal.
Unstrukturiertes Repository konfigurieren
Zum Konfigurieren eines unstrukturiertes Repositorys setzen Sie den Wert von spec.sourceFormat
in Ihrem RootSync-Objekt auf unstructured
:
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
name: ROOT_SYNC_NAME
namespace: config-management-system
spec:
sourceFormat: unstructured
git:
repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
branch: main
dir: config-sync-quickstart/multirepo/root
auth: ssh
secretRef:
name: SECRET_NAME
Ersetzen Sie Folgendes:
ROOT_SYNC_NAME
: Fügen Sie den Namen Ihres RootSync-Objekts hinzu. Der Name darf im Cluster nur einmal vorkommen und darf nicht mehr als 26 Zeichen haben.SECRET_NAME
durch den Namen des Secrets.
Hierarchisches Repository in unstrukturiertes Repository umwandeln
Wenn Sie ein hierarchisches Repository verwenden und es in ein unstrukturiertes Repository konvertieren möchten, führen Sie Folgendes in Ihrem Repository aus:
nomos hydrate PATH
Ersetzen Sie PATH
durch den Pfad zu Ihrem Arbeitsverzeichnis.
Mit diesem Befehl wird im aktuellen Arbeitsverzeichnis ein compiled/
-Verzeichnis erstellt. Innerhalb dieses Verzeichnisses wird für jeden registrierten Cluster ein Unterverzeichnis mit den vollständig aufgelösten Konfigurationen erstellt und jedes Unterverzeichnis kann in einem unstrukturierten Repository verwendet werden.
Weitere Informationen finden Sie unter nomos
-Befehle.
Wenn Sie Ihr Repository manuell konvertieren möchten, führen Sie die folgenden Schritte aus:
Entfernen Sie
Repo
-Konfigurationen im Verzeichnissystem/
aus Ihrem Git-Repository. DieRepo
-Ressource wird für ein unstrukturiertes Repository nicht benötigt.Das abstrakte Namespace-Verzeichnis wird in einem unstrukturierten Repository nicht unterstützt. Daher müssen Sie den Namespace aller Ressourcen deklarieren, die ursprünglich im Verzeichnis
namespaces/
und in dessen Unterverzeichnisse enthalten sind.Die Namespace-Übernahme wird in einem unstrukturierten Repository nicht unterstützt. Daher müssen Sie alle Ressourcen deklarieren, die ursprünglich in untergeordnete Namespaces übernommen wurden, also solche, die ursprünglich im Verzeichnis
namespaces/
enthalten sind.
Beispielformat für ein unstrukturiertes Repository
Das folgende Beispiel zeigt, wie Sie Ihre Konfigurationen (einschließlich Google Cloud-Ressourcen) in einem unstrukturierten Repository organisieren können:
├── manifests
│ ├── access-control
│ │ ├── ...
│ ├── change-control
│ │ ├── ...
│ ├── git-ops
│ │ └── ...
│ ├── logging-monitoring
│ │ └── ...
│ ├── networking
│ │ └── ...
│ ├── project-factory
│ │ └── ...
│ └── resource-hierarchy
│ │ └── ...
├── raw-configs
│ ├── access-control
│ │ └── ...
│ ├── change-control
│ │ └── ...
│ ├── git-ops
│ │ └── ...
│ ├── logging-monitoring
│ │ └── ...
│ ├── networking
│ │ └── ...
│ ├── project-factory
│ │ └── ...
│ └── resource-hierarchy
│ │ └── ...
└── scripts
└── render.sh
In diesem Beispiel befinden sich die Rohkonfigurationen im Verzeichnis raw-configs
. Sie können dann ein Skript oder eine automatisierte Pipeline verwenden, um die Rohkonfigurationen zu rendern und die Ausgabe im Verzeichnis manifests
zu speichern. Konfigurieren Sie Config Sync, um es aus dem Verzeichnis manifests
zu synchronisieren.
Nächste Schritte
- Clusterbezogene Objekte erstellen
- Namespace-bezogene Objekte erstellen
- Config Sync installieren
- Synchronisierung aus mehreren Repositories konfigurieren