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:

namespace-Inheritance/config/namespaces/viewers-rolebinding.yaml

Visualizza su GitHub

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 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.

Nota: ResourceQuotes si applica solo a un singolo spazio dei nomi. Al contrario, HierarchicalResourceQuotes può limitare l'utilizzo delle risorse in una struttura di spazi dei nomi gerarchici, ma non è supportato dagli spazi dei nomi astratti. L'inserimento di una quota gerarchica in uno spazio dei nomi astratto fa sì che le copie indipendenti di tale quota vengano posizionate in tutti gli elementi secondari. Per utilizzare le quote delle risorse gerarchiche, utilizza gli spazi dei nomi gerarchici forniti da Controller gerarchia.

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.

Attenzione: per impostazione predefinita, i repository Git non forniscono un controllo granulare dell'accesso. Se l'insieme di persone con diritti di commit nel tuo repository non è esattamente uguale all'insieme di utenti autorizzati a creare, modificare o eliminare oggetti Kubernetes nei tuoi cluster, valuta la possibilità di utilizzare un meccanismo di controllo dell'accesso come i file OWNERS o CODEOWNERS nel tuo repository.

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.

Nota: se rinomini una directory dello spazio dei nomi, ricordati di aggiornarne il nome anche nella configurazione dello spazio dei nomi.

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

beta

Questo prodotto è coperto dai Termini delle offerte pre-GA dei Termini di servizio di Google Cloud. I prodotti pre-GA potrebbero avere un supporto limitato e le modifiche ai prodotti pre-GA potrebbero non essere compatibili con altre versioni pre-GA. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Importante: Gerarchia Controller e le relative funzionalità richiedono Config Sync versione 1.4.1 o successiva.

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.