Utilizzare un repository non strutturato

L'utilizzo di un repository non strutturato ti consente di organizzare il repository nel modo più comodo per te. Questa flessibilità ti consente di sincronizzare la configurazione Kubernetes esistente con il repository Config Sync. Ad esempio, se vuoi sincronizzare un grafico Helm con il tuo cluster, puoi eseguire il comando helm template e inviare il manifest sottoposto a rendering al tuo repository. Per ulteriori informazioni, consulta l'esercitazione Utilizzare Config Sync con Helm.

Consigliamo i repository non strutturati per la maggior parte dei casi d'uso. Tuttavia, puoi anche creare un repository gerarchico per separare le configurazioni in categorie distinte.

Limitazioni

I repository non strutturati presentano le seguenti limitazioni:

  • Non puoi utilizzare l'oggetto Kubernetes HierarchyConfig in un repository non strutturato.

  • Gli spazi dei nomi astratti non sono supportati nei repository non strutturati.

  • Se utilizzi il comando nomos vet, aggiungi il flag --source-format=unstructured. Ad esempio:

    nomos vet --source-format=unstructured

Oggetti con ambito di spazio dei nomi

Puoi dichiarare NamespaceSelector in un repository non strutturato. Per dichiarare un NamespaceSelector, aggiungi l'annotazione metadata.namespace o NamespaceSelector. La dichiarazione di entrambe le annotazioni non è valida. Se le risorse con ambito spazio dei nomi non dichiarano metadata.namespace o l'annotazione NamespaceSelector, Config Sync utilizza lo spazio dei nomi "default" del cluster. Per saperne di più, vedi Limitare gli spazi dei nomi interessati da una configurazione.

Oggetti con ambito cluster

In un repository non strutturato, la funzione ClusterSelectors funziona normalmente.

Configurare un repository non strutturato

Per configurare un repository non strutturato, imposta il valore di spec.sourceFormat su unstructured nell'oggetto RootSync:

  # 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

Sostituisci quanto segue:

  • ROOT_SYNC_NAME: aggiungi il nome dell'oggetto RootSync. Il nome deve essere univoco nel cluster e non deve contenere più di 26 caratteri.
  • SECRET_NAME con il nome del secret.

Convertire un repository gerarchico in un repository non strutturato

Se utilizzi un repository gerarchico e vuoi convertirlo in un repository non strutturato, nel repository esegui:

nomos hydrate PATH

Sostituisci PATH con il percorso della directory.

Questo comando crea una directory compiled/ nella directory di lavoro corrente. All'interno di questa directory viene creata una sottodirectory per ogni cluster registrato, con le configurazioni completamente risolte, e ogni sottodirectory può essere utilizzata in un repository non strutturato.

Per maggiori dettagli, vedi Comandi nomos.

Se preferisci convertire manualmente il repository, completa le seguenti istruzioni:

  1. Rimuovi le configurazioni Repo nella directory system/ dal repository Git. La risorsa Repo non è necessaria per un repository non strutturato.

  2. La directory dello spazio dei nomi astratto non è supportata in un repository non strutturato. Pertanto, devi dichiarare lo spazio dei nomi di tutte le risorse originariamente incluse nella directory namespaces/ e nelle relative sottodirectory.

  3. L'ereditarietà dello spazio dei nomi non è supportata nel repository non strutturato. Pertanto, devi dichiarare tutte le risorse originariamente ereditate negli spazi dei nomi discendenti, ovvero quelle originariamente presenti nella directory namespaces/.

Esempio di formato per un repository non strutturato

Il seguente esempio mostra come potresti organizzare le configurazioni (incluse le risorse Google Cloud ) in un repository non strutturato:

├── 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 questo esempio, le configurazioni non elaborate si trovano in una directory raw-configs. Potresti quindi utilizzare uno script o una pipeline automatizzata per eseguire il rendering delle configurazioni non elaborate e archiviare l'output nella directory manifests. Quando configuri Config Sync, lo configuri in modo che si sincronizzi dalla directory manifests.

Passaggi successivi