Utilizzare un repository gerarchico

Questa pagina descrive come Config Sync legge le configurazioni da una fonte attendibile gerarchica e applica automaticamente la configurazione risultante ai tuoi cluster.

Ti consigliamo di utilizzare un'origine non strutturata della verità anziché una gerarchica, perché offre le stesse funzionalità di base, ma ti offre maggiore flessibilità nell'organizzazione delle risorse. Se utilizzi già una fonte attendibile gerarchica, puoi convertirla in una fonte attendibile non strutturata.

Per capire come Config Sync utilizza un repository gerarchico, è utile avere familiarità con i repository Git e con l'interfaccia a riga di comando git.

Puoi visualizzare un esempio di come organizzare e configurare una fonte attendibile gerarchica nel repository di esempi di Config Sync.

Struttura della directory

Per le origini gerarchiche, Config Sync sfrutta strutture simili a quelle del file system e utilizza la directory per determinare a quali cluster o spazi dei nomi è pertinente una configurazione.

namespaces/

La directory namespaces/ contiene configurazioni per spazi dei nomi e oggetti con ambito di spazio dei nomi. La struttura all'interno di namespaces/ è il meccanismo che determina l'ereditarietà dello spazio dei nomi. Puoi limitare gli spazi dei nomi che possono ereditare una configurazione utilizzando un NamespaceSelector.

cluster/

La directory cluster/ contiene configurazioni che si applicano a interi cluster, anziché a spazi dei nomi. Per impostazione predefinita, qualsiasi configurazione nella directory cluster/ si applica a ogni cluster registrato in Config Sync. Puoi limitare i cluster che una configurazione può interessare utilizzando un ClusterSelector.

clusterregistry/

La directory clusterregistry/ è facoltativa e contiene le configurazioni per ClusterSelectors. ClusterSelector limita i cluster a cui si applica una configurazione e viene fatto riferimento nelle configurazioni trovate nelle directory cluster/ e namespaces/.

system/

La directory system/ contiene le configurazioni per l'operatore.

Esempio di fonte attendibile gerarchica

La seguente struttura di directory mostra come utilizzare una fonte attendibile gerarchica di Config Sync per configurare un cluster Kubernetes condiviso da due team diversi, team-1 e team-2.

  • Ogni team ha il proprio spazio dei nomi Kubernetes, il proprio account di servizio Kubernetes, le proprie quote di risorse, i propri criteri di rete e i propri rolebinding.
  • L'amministratore del cluster configura un criterio in namespaces/limit-range.yaml per vincolare le allocazioni di risorse (a pod o container) in entrambi gli spazi dei nomi.
  • L'amministratore del cluster configura anche ClusterRole e ClusterRoleBinding.

Una fonte gerarchica Config Sync valida deve includere tre sottodirectory: cluster/, namespaces/ e system/.

La directory cluster/ contiene configurazioni che si applicano a interi cluster (come ClusterRole, ClusterRoleBinding), anziché agli spazi dei nomi.

La directory namespaces/ contiene le configurazioni per gli oggetti dello spazio dei nomi e gli oggetti con ambito di spazio dei nomi. Ogni sottodirectory in namespaces/ include le configurazioni per un oggetto spazio dei nomi e tutti gli oggetti con ambito di spazio dei nomi nello spazio dei nomi. Il nome di una sottodirectory deve essere uguale a quello dell'oggetto spazio dei nomi. Gli oggetti con ambito di spazio dei nomi che devono essere creati in ogni spazio dei nomi possono essere inseriti direttamente in namespaces/ (ad esempio, namespaces/limit-range.yaml).

La directory system/ contiene le configurazioni per l'operatore ConfigManagement.

├── cluster
│   ├── clusterrolebinding-namespace-reader.yaml
│   ├── clusterrole-namespace-reader.yaml
│   ├── clusterrole-secret-admin.yaml
│   └── clusterrole-secret-reader.yaml
├── namespaces
│   ├── limit-range.yaml
│   ├── team-1
│   │   ├── namespace.yaml
│   │   ├── network-policy-default-deny-egress.yaml
│   │   ├── resource-quota-pvc.yaml
│   │   ├── rolebinding-secret-reader.yaml
│   │   └── sa.yaml
│   └── team-2
│       ├── namespace.yaml
│       ├── network-policy-default-deny-all.yaml
│       ├── resource-quota-pvc.yaml
│       ├── rolebinding-secret-admin.yaml
│       └── sa.yaml
├── README.md
└── system
    └── repo.yaml

Utilizzare l'eredità dello spazio dei nomi e gli spazi dei nomi astratti

Con una fonte di verità gerarchica, puoi utilizzare il concetto di ereditarietà dello spazio dei nomi per applicare automaticamente le configurazioni a gruppi di spazi dei nomi in tutti i cluster in cui questi spazi dei nomi esistono (o dovrebbero esistere).

L'ereditarietà dello spazio dei nomi si applica alla directory namespaces/ del repository gerarchico e a tutte le relative sottodirectory. Le configurazioni in altre directory del repository, ad esempio cluster/, non sono soggette all'ereditarietà.

In un'origine attendibile gerarchica, la directory namespaces/ può contenere due diversi tipi di sottodirectory:

  • Una directory dello spazio dei nomi contiene una configurazione per uno spazio dei nomi. Il nome del file contenente la configurazione non è importante, ma la configurazione deve avere kind: Namespace. Una directory dello spazio dei nomi può contenere anche configurazioni per altri tipi di oggetti Kubernetes. Una directory dello spazio dei nomi non può contenere sottodirectory. Una configurazione dello spazio dei nomi rappresenta uno spazio dei nomi effettivo in un cluster.

  • Una directory dello spazio dei nomi astratto contiene directory dello spazio dei nomi. Può contenere anche configurazioni per altri oggetti Kubernetes, ma non può contenere direttamente una configurazione per uno spazio dei nomi. Una directory dello spazio dei nomi astratto non rappresenta un oggetto in un cluster Kubernetes, ma le relative directory dello spazio dei nomi discendenti sì.

Per garantire che le origini dello spazio dei nomi e dello spazio dei nomi astratto abbiano il tipo e la struttura corretti di configurazioni, l'errore KNV1003: IllegalNamespaceSubdirectoryError viene segnalato in caso di problemi.

Le configurazioni in una directory dello spazio dei nomi si applicano solo a quello spazio dei nomi. Tuttavia, le configurazioni in una directory dello spazio dei nomi astratto vengono applicate a tutte le directory dello spazio dei nomi discendenti dello spazio dei nomi astratto (o a quegli spazi dei nomi discendenti che corrispondono a un NamespaceSelector di una configurazione, se presente).

L'ereditarietà di una configurazione nella directory namespaces/ si basa in gran parte sulla sua posizione all'interno della struttura ad albero delle directory nella fonte attendibile. Per capire quali configurazioni vengono applicate a un determinato spazio dei nomi in un determinato cluster, puoi sfogliare il repository di esempio di ereditarietà dello spazio dei nomi.

Spazi dei nomi con limitazioni

config-management-system è uno spazio dei nomi con limitazioni. Non puoi utilizzarlo come directory dello spazio dei nomi astratto. Puoi definire uno spazio dei nomi config-management-system, ma l'unico tipo di risorsa consentito per lo spazio dei nomi config-management-system è RootSync.

Apportare modifiche alla fonte attendibile

Quando apporti una modifica nella tua origine attendibile che crea o elimina directory di spazi dei nomi dalla directory namespaces/, potresti ottenere risultati imprevisti a seconda dell'azione:

  • Creazione di una directory: quando una gerarchia namespaces/ valida viene eseguita il commit nell'origine attendibile, Config Sync crea spazi dei nomi, quindi crea oggetti Kubernetes in questi spazi dei nomi per ogni configurazione contenuta o ereditata dalla directory dello spazio dei nomi.
  • Eliminazione di una directory: l'eliminazione di una directory dello spazio dei nomi è un'operazione distruttiva. Lo spazio dei nomi e i relativi contenuti vengono eliminati in ogni cluster gestito da Config Sync in cui esiste lo spazio dei nomi. Se elimini una directory dello spazio dei nomi astratto contenente directory dello spazio dei nomi discendenti, tutti questi spazi dei nomi e i relativi contenuti vengono eliminati da ogni cluster gestito da Config Sync.

  • Rinomina una directory: rinominare una directory dello spazio dei nomi è un'eliminazione, seguita da una creazione ed è considerata un'operazione distruttiva. La ridenominazione di una directory dello spazio dei nomi astratto non ha alcun effetto visibile esternamente.

  • Spostamento di una directory: lo spostamento di uno spazio dei nomi o di una directory di spazi dei nomi astratti all'interno di namespaces/ non elimina lo spazio dei nomi o gli oggetti al suo interno, tranne nel caso in cui lo spazio dei nomi inizi o smetta di ereditare una configurazione da una directory di spazi dei nomi astratti, a causa di una modifica alla sua gerarchia.

Passaggi successivi