Unstrukturiertes Repository verwenden

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 Anwendungsfälle empfehlen wir unstrukturierte Repositories. Sie können aber auch ein hierarchisches Repository erstellen, um Konfigurationen in unterschiedliche Kategorien zu trennen.

Beschränkungen

Unstrukturierte Repositories unterliegen den folgenden Einschränkungen:

  • Sie können das Kubernetes-Objekt HierarchyConfig in einem unstrukturierten Repository nicht 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 dabei 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:

  1. Entfernen Sie Repo-Konfigurationen im Verzeichnis system/ aus Ihrem Git-Repository. Die Repo-Ressource wird für ein unstrukturiertes Repository nicht benötigt.

  2. 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.

  3. 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