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:

spazi-ereditari/config/namespaces/viewers-rolebinding.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: viewers
subjects:
- kind: Group
  name: system:serviceaccounts:foo
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

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