Ereditarietà dello spazio dei nomi e spazi dei nomi astratti
Questa pagina descrive come utilizzare il concetto di ereditarietà dello spazio dei nomi in un repository gerarchico di Config Sync.
In base alla struttura del repository, Config Sync può applicare automaticamente le configurazioni ai gruppi di spazi dei nomi in tutti i cluster in cui esistono o esistono spazi dei nomi. Questi gruppi di spazi dei nomi sono chiamati spazi dei nomi astratti.
L'ereditarietà dello spazio dei nomi e gli spazi dei nomi astratti non sono supportati nei repository non strutturati. Se utilizzi un repository non strutturato e vuoi avere funzionalità simili, usa Controller di gerarchia.
Come funziona l'ereditarietà dello spazio dei nomi
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 nel repository, come cluster/
, non sono soggette a ereditarietà.
In un repository gerarchico, 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 astratta contiene directory dello spazio dei nomi. Può anche contenere configurazioni per altri oggetti Kubernetes, ma non può contenere direttamente una configurazione per uno spazio dei nomi. Una directory dello spazio dei nomi astratta non rappresenta un oggetto in un cluster Kubernetes, al contrario delle directory dello spazio dei nomi discendenti.
Per garantire che lo spazio dei nomi e i repository di spazi dei nomi astratti abbiano il tipo di configurazione e la struttura corretti, viene segnalato l'errore KNV1003: InvalidNamespaceSubdirectoryError segnala un problema.
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 astratta vengono applicate a tutte le directory dello spazio dei nomi discendenti (o a quelli dello spazio discendente) che corrispondono a uno spazio dei nomi discendente di configurazione, se presente.
Esempio di ereditarietà dello spazio dei nomi
L'ereditarietà di una configurazione nella directory namespaces/
si basa in gran parte sulla sua posizione all'interno della struttura di directory nel repository. Per comprendere quali configurazioni vengono applicate a un determinato spazio dei nomi in un determinato cluster, puoi sfogliare il repository di esempio dell'ereditarietà dello spazio dei nomi.
La directory namespaces/
nel repository di esempio di ereditarietà dello spazio dei nomi ha la seguente architettura:
├── namespaces # Namespace directory
│ ├── eng # Namespace directory
│ │ ├── analytics # Abstract namespace directory
│ │ └── gamestore # Abstract namespace directory
│ ├── rnd # Namespace directory
│ │ ├── incubator-1 # Abstract namespace directory
│ │ └── incubator-2 # Abstract namespace directory
| |── network-policy-default-deny-all.yaml
| |── viewers-rolebinding.yaml
Per comprendere meglio come funziona questo repository di esempio, devi prima esplorare
viewers-rolebinding.yaml
:
Poiché questo RoleBinding si trova nella directory principale della directory namespaces/
, concede a tutti gli utenti del gruppo system:serviceaccounts:foo
il ClusterRole view
in ogni spazio dei nomi gestito da Config Sync.
Successivamente, apri la directory namespaces/eng/
nel browser. La directory eng
è una directory dello spazio dei nomi astratta, perché non ha una configurazione per uno spazio dei nomi. La directory eng
contiene le seguenti configurazioni:
eng-role.yaml
eng-rolebinding.yaml
network-policy-allow-gamestore-ingress.yaml
quota.yaml
selectors.yaml
La directory eng
ha anche due sottodirectory: analytics
e gamestore
. Queste sottodirectory sono directory degli spazi dei nomi, perché contengono ciascuna una configurazione per uno spazio dei nomi. In questo esempio, le configurazioni degli spazi dei nomi sono chiamate namespace.yaml
,
ma puoi chiamarle come preferisci. Ciascuno degli spazi dei nomi in
analytics
e gamestore
eredita le configurazioni eng-role.yaml
, eng-rolebinding.yaml
e network-policy-allow-gamestore-ingress.yaml
nella directory dello spazio dei nomi astratto
eng
.
L'oggetto ResourceQuota definito in quota.yaml
utilizza un
NamespaceSelector,
quindi questo oggetto ResourceQuota viene creato solo negli spazi dei nomi analytics
e gamestore
.
La directory dello spazio dei nomi gamestore
ha una configurazione aggiuntiva per il RoleBinding bob-rolebinding
, ma la directory dello spazio dei nomi analytics
non ha questa configurazione, quindi lo spazio dei nomi analytics
non ha questa associazione dei ruoli (a meno che qualcuno non la crei manualmente).
Il repository di ereditarietà dello spazio dei nomi contiene anche un file README.md
che contiene ulteriori esempi di come funziona l'ereditarietà dello spazio dei nomi.
Spazi dei nomi limitati
config-management-system
è uno spazio dei nomi limitato. Non puoi utilizzarlo come una directory dello spazio dei nomi astratta. A partire dalla versione 1.11.0, puoi definire uno spazio dei nomi per config-management-system
. Tuttavia, l'unico tipo di risorsa consentito per lo spazio dei nomi config-management-system
è RootSync
.
Escludi spazi dei nomi dall'ereditarietà
Puoi utilizzare i selettori di spazi dei nomi per escludere determinati spazi dei nomi dall'ereditarietà di una risorsa nell'albero.
L'esempio seguente consente a un oggetto ResourceQuota
annotato correttamente nella directory
/namespaces
di essere ereditato da ogni spazio dei nomi tranne quelli
etichettati con quota-exempt: exempt
:
kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
name: excludes-exempt-namespaces
spec:
selector:
matchExpressions:
- key: quota-exempt
operator: NotIn
values:
- exempt
Per saperne di più su NamespaceSelectors
in Config Sync, consulta la sezione Limitare gli spazi dei nomi interessati da una configurazione.
Effetti delle operazioni Git sugli spazi dei nomi
Le operazioni Git che creano o eliminano directory dello spazio dei nomi dalla directory namespaces/
possono causare effetti diversi rispetto a quelli previsti.
Le interazioni che seguono riguardano queste interazioni.
Creazione di una directory in namespaces/
Quando una gerarchia namespaces/
è valida per il repository, Config Sync crea spazi dei nomi e quindi crea oggetti Kubernetes in tali spazi dei nomi per ogni configurazione che la directory dello spazio dei nomi contiene o eredita.
Eliminazione di una directory da namespaces/
L'eliminazione di una directory dello spazio dei nomi è un'operazione irreversibile. Lo spazio dei nomi, insieme a tutti i suoi contenuti, viene eliminato in ogni cluster gestito da Config Sync in cui esiste lo spazio dei nomi.
Se elimini una directory dello spazio dei nomi astratta contenente directory degli spazi dei nomi discendenti, tutti questi spazi dei nomi e i loro contenuti vengono eliminati da ogni cluster gestito da Config Sync.
Rinominare una directory in namespaces/
La ridenominazione di una directory dello spazio dei nomi è un'eliminazione seguita da una creazione e pertanto è anche un'operazione distruttiva.
La ridenominazione di una directory dello spazio dei nomi astratta non ha effetti visibili esternamente.
Spostamento di una directory in namespaces/
Lo spostamento di uno spazio dei nomi o di una directory dello spazio dei nomi astratta 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 inizia o smette di ereditare una configurazione da una directory dello spazio dei nomi astratta, a causa di una modifica alla sua gerarchia.
Integrazione con il controller della gerarchia
Controller di gerarchia ti consente di utilizzare spazi dei nomi gerarchici, simili a spazi dei nomi astratti. Gerarchia Controller supporta anche funzionalità aggiuntive come le quote delle risorse gerarchiche e gli spazi dei nomi self-service.
Seleziona spazi dei nomi correlati
A volte potresti voler applicare criteri a insiemi di spazi dei nomi correlati a un predecessore comune. Il controller della gerarchia supporta questa funzionalità tramite un concetto noto come etichette di albero. Le etichette ad albero sono supportate anche da spazi dei nomi astratti, anche se il controller di gerarchia non è abilitato.
Le etichette ad albero sono etichette Kubernetes che hanno il formato seguente:
NAMESPACE_NAME.tree.hnc.x-k8s.io/depth: DEPTH
Queste etichette consentono di scrivere selettori di spazi dei nomi che, ad esempio, possono essere utilizzati come parte di un criterio di rete per consentire il traffico all'interno di un sottoalbero degli spazi dei nomi correlati, ma non consentire il traffico al di fuori di tale sottoalbero.
Possiamo illustrare questo concetto tornando al repository di esempio.
├── namespaces # Namespace directory
│ ├── eng # Namespace directory
│ │ ├── analytics # Abstract namespace directory
│ │ └── gamestore # Abstract namespace directory
│ ├── rnd # Namespace directory
│ │ ├── incubator-1 # Abstract namespace directory
│ │ └── incubator-2 # Abstract namespace directory
| |── network-policy-default-deny-all.yaml
| |── viewers-rolebinding.yaml
Immagina che in questo esempio la namespace.yaml
nella directory dello spazio dei nomi astratto gamestore
abbia le seguenti etichette ad albero:
eng.tree.hnc.x-k8s.io/depth: "1"
gamestore.tree.hnc.x-k8s.io/depth: "0"
Puoi utilizzare i comandi kubectl
per ispezionare queste relazioni direttamente sul cluster, senza avere accesso al repository Git:
# View all descendants of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth'
# View any immediate children of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth=1'
Controller di gerarchia propaga anche tutte le etichette ad albero dagli spazi dei nomi astratti a qualsiasi spazio dei nomi discendente. Ad esempio, se crei uno spazio dei nomi secondario di gamestore
come segue:
kubectl hns create gamestore-v1 -n gamestore
In questo caso, lo spazio dei nomi gamestore-v1
includerebbe tutte le etichette dell'elemento principale, oltre alle proprie, con la profondità opportunamente regolata:
eng.tree.hnc.x-k8s.io/depth: 2
gamestore-v1.tree.hnc.x-k8s.io/depth: 0
gamestore.tree.hnc.x-k8s.io/depth: 1
Passaggi successivi
- Scopri come gestire spazi dei nomi e oggetti con ambito di spazio dei nomi
- Segui il tutorial sull'ereditarietà dello spazio dei nomi nel repository degli esempi di Anthos Config Management.