L'utilizzo di un repository non strutturato ti consente di organizzare il repository nel modo più appropriato
per te. Questa flessibilità ti consente di sincronizzare il tuo cluster Kubernetes esistente
configurazione nel repository Config Sync. Ad esempio, se vuoi sincronizzare
Helm al tuo cluster, puoi eseguire
Comando helm template
ed eseguire il commit del manifest sottoposto a rendering nel repository. Per ulteriori informazioni,
consulta Utilizzare Config Sync con Helm
tutorial di Google Cloud.
I repository non strutturati sono consigliati per la maggior parte degli utenti. Tuttavia, puoi anche creare un repository gerarchico configurazioni separate in categorie distinte. Se vuoi creare un modello gerarchico i criteri senza rispettare le regole del repository gerarchico, valuta la possibilità di Controller gerarchia.
Limitazioni
I repository non strutturati hanno le seguenti limitazioni:
Non puoi utilizzare
Repo
oHierarchyConfig
Oggetti Kubernetes in un repository non strutturato.Gli spazi dei nomi astratti non sono supportate nei repository non strutturati.
Se utilizzi 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 NamespaceSelectors in un repository non strutturato. Per dichiarare un
NamespaceSelector, aggiungi metadata.namespace
o NamespaceSelector
annotazione. La dichiarazione di entrambe le annotazioni non è valida. Se con ambito dello spazio dei nomi
risorse non dichiarano metadata.namespace
o NamespaceSelector
l'annotazione, Config Sync utilizza il modello del cluster.
Per saperne 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
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 del tuo sistema RootSync . Il nome deve essere univoco nel cluster e avere 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 repository, esegui:
nomos hydrate PATH
Sostituisci PATH
con il percorso della directory.
Questo comando crea una directory compiled/
nella directory di lavoro attuale. Entro
viene creata una sottodirectory per ogni cluster registrato,
completamente risolte e ogni sottodirectory può essere utilizzata in un
repository Git.
Per maggiori dettagli, vedi Comandi nomos
.
Se preferisci convertire manualmente il repository, completa quanto segue istruzioni:
Rimuovi le configurazioni
Repo
nella directorysystem/
dal tuo 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 di tutte le risorse originariamente incluse nella directory
namespaces/
e relative alle sue sottodirectory.Eredità dello spazio dei nomi non è supportata nel repository non strutturato. Di conseguenza, devi dichiarare che sono originariamente ereditate negli spazi dei nomi discendenti, ovvero quelli originariamente contenuti nella directory
namespaces/
.
Formato di esempio per un repository non strutturato
L'esempio seguente mostra come potresti organizzare le tue 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
e poi usa uno script o una pipeline automatizzata per eseguire il rendering delle configurazioni non elaborate e
l'output nella directory manifests
. Quando
configurare Config Sync,
dovresti configurare il dispositivo in modo che venga sincronizzato dalla directory manifests
.
Passaggi successivi
- Creare oggetti con ambito cluster
- Creare oggetti con ambito a livello di spazio dei nomi
- Installa Config Sync
- Configura la sincronizzazione da più repository