L'utilizzo di un repository non strutturato consente di organizzare il repository
nel modo più pratico per te. Questa flessibilità 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
ed eseguire il commit del manifest visualizzato nel tuo repository. Per ulteriori informazioni, consulta il tutorial Utilizzo di Config Sync con Helm.
I repository non strutturati sono consigliati per la maggior parte degli utenti. Tuttavia, puoi anche creare un repository gerarchico per separare le configurazioni in categorie distinte. Se vuoi creare criteri gerarchici senza aderire alle regole del repository gerarchico, valuta l'utilizzo di Hierarchy Controller.
Limitazioni
I repository non strutturati hanno le seguenti limitazioni:
Non puoi utilizzare gli oggetti
Repo
oHierarchyConfig
Kubernetes 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 a livello di spazio dei nomi
Puoi dichiarare gli spazi dei nomi 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 dello spazio dei nomi non dichiarano metadata.namespace
o l'annotazione NamespaceSelector
, Config Sync utilizza lo spazio dei nomi "predefinito" del cluster.
Per scoprire di più, consulta Limitare gli spazi dei nomi interessati da una configurazione.
Oggetti con ambito cluster
In un repository non strutturato, ClusterSelectors
funziona normalmente.
Configura un repository non strutturato
Per configurare un repository non strutturato, imposta il valore di spec.sourceFormat
su
unstructured
nel tuo 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 contenere non più di 26 caratteri.SECRET_NAME
con il nome del secret.
Converti un repository gerarchico in un repository non strutturato
Se utilizzi un repository gerarchico e vuoi convertirlo in un repository non strutturato, nel tuo 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, segui queste istruzioni:
Rimuovi le configurazioni
Repo
nella directorysystem/
dal repository Git. La risorsaRepo
non è necessaria per un repository non strutturato.La directory dello spazio dei nomi astratta 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.L'ereditarietà dello spazio dei nomi non è supportata nel repository non strutturato. Pertanto, devi dichiarare tutte le risorse che sono originariamente ereditate negli spazi dei nomi discendenti, ovvero quelle originariamente nella directory
namespaces/
.
Formato di esempio per un repository non strutturato
L'esempio seguente mostra come 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
. Puoi 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, devi configurarlo per la sincronizzazione dalla directory manifests
.
Passaggi successivi
- Creare oggetti con ambito cluster
- Creare oggetti con ambito di spazio dei nomi
- Installa Config Sync
- Configurare la sincronizzazione da più repository