Eredità 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 a gruppi di spazi dei nomi in tutti i cluster in cui esistono (o dovrebbero esistere) tali 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 funzionalità simili, usa il controller della 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 del repository, ad esempio cluster/
, non sono soggette a ereditarietà.
In un repository gerarchico, la directory namespaces/
può contenere due diversi tipi di sottodirectory:
Una directory degli spazi 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. La directory di uno spazio dei nomi non può contenere sottodirectory. La configurazione di uno 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ò contenere anche configurazioni per altri oggetti Kubernetes, ma non può contenere direttamente una configurazione per uno spazio dei nomi. La directory di uno spazio dei nomi astratta non rappresenta un oggetto in un cluster Kubernetes, a differenza delle directory dello spazio dei nomi discendenti.
Per garantire che il tuo spazio dei nomi e i repository dello spazio dei nomi astratti abbiano il tipo corretto di configurazioni e strutture, l'errore KNV1003: lawNamespaceSubdirectoryError segnala un problema.
Le configurazioni in una directory dello spazio dei nomi si applicano solo a tale 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 dello spazio dei nomi astratto (o a quelli discendenti che corrispondono a uno NamespaceSelector di configurazione, se presente).
Esempio di ereditarietà dello spazio dei nomi
L'ereditarietà di una configurazione nella directory namespaces/
si basa principalmente sulla sua posizione all'interno della struttura di directory nel repository. Per capire 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 dell'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, esplora innanzitutto
viewers-rolebinding.yaml
:
Poiché questo RoleBinding si trova nella directory principale di namespaces/
, concede a chiunque nel Gruppo system:serviceaccounts:foo
il ClusterRole view
in ogni spazio dei nomi gestito da Config Sync.
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, ciascuna delle quali contiene 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 astratta 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 quel RoleBinding
(a meno che non venga creato manualmente).
Il repository di eredità 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 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 dello spazio 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
principale di essere ereditato da ogni spazio dei nomi ad eccezione di quelli
con etichetta 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 pagina
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 all'interno della directory namespaces/
potrebbero causare effetti diversi rispetto a quanto previsto inizialmente.
Le interazioni delle sezioni successive riguardano queste interazioni.
Creazione di una directory in namespaces/
in corso...
Quando una gerarchia namespaces/
valida è impegnata nel repository, Config Sync crea gli spazi dei nomi, quindi crea oggetti Kubernetes in questi 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 distruttiva. Lo spazio dei nomi viene eliminato, insieme a tutti i suoi contenuti, su ogni cluster gestito da Config Sync in cui è presente.
Se elimini una directory degli spazi dei nomi astratta contenente directory degli spazi dei nomi discendenti, tutti questi spazi dei nomi e i relativi 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 perciò è 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/
in corso...
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 nella gerarchia.
Integrazione con Controller di gerarchia
Il controller della 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. Gerarchia Controller supporta questa funzionalità utilizzando un concetto noto come etichette di albero. Le etichette ad albero sono supportate anche da spazi dei nomi astratti, anche se il controller 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 spazio 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, namespace.yaml
nella directory dello spazio dei nomi astratta 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 esaminare queste relazioni direttamente nel 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'
Gerarchia Controller propaga anche qualsiasi etichetta ad albero dagli spazi dei nomi astratti in qualsiasi spazio dei nomi discendente. Ad esempio, se crei uno spazio dei nomi secondario di gamestore
nel seguente modo:
kubectl hns create gamestore-v1 -n gamestore
In questo caso, lo spazio dei nomi gamestore-v1
includerà tutte le etichette dell'elemento padre, oltre al proprio, 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 gli spazi dei nomi e gli oggetti con ambito di spazio dei nomi
- Segui il tutorial sull'ereditarietà dello spazio dei nomi nel repository degli esempi di Anthos Config Management.