Hierarchy Controller aggiunge funzionalità gerarchiche agli spazi dei nomi Kubernetes, consentendoti di scrivere criteri più espressivi, migliorare l'osservabilità e delegare l'amministrazione dei cluster.
Hierarchical Namespace Controller (HNC) è basato su un progetto open source Hierarchical Namespace Controller (HNC). Viene implementato utilizzando i controller e i controller di ammissione dinamici di Kubernetes in esecuzione nel cluster.
Spazi dei nomi gerarchici
In Kubernetes, gli spazi dei nomi sono l'unità organizzativa fondamentale della maggior parte degli oggetti. Inoltre, costituiscono l'unità fondamentale dell'isolamento e della sicurezza in Kubernetes. La maggior parte dei criteri e degli oggetti di isolamento opera a livello di spazio dei nomi, ad esempio ruoli RBAC, secret, account di servizio, quote delle risorse e criteri di rete.
In genere, puoi migliorare la sicurezza e l'isolamento del tuo cluster definendo l'ambito di ogni spazio dei nomi in modo che contenga il numero minimo di risorse, ad esempio un singolo microservizio, insieme alle relative risorse e criteri. Tuttavia, questo può portare a un numero elevato di spazi dei nomi nei tuoi cluster, che possono essere difficili da gestire.
Per risolvere questo problema, Hierarchy Controller introduce il concetto di spazi dei nomi gerarchici, che consentono di raggruppare gli spazi dei nomi Kubernetes in base ai proprietari e di manipolare questi gruppi come unità coesive. Sono particolarmente utili nei cluster condivisi da più team, ma i proprietari non devono necessariamente essere persone. Ad esempio, potresti voler rendere uno strumento automatizzato proprietario di un insieme di spazi dei nomi, soprattutto se richiede autorizzazioni molto ampie, ma ha bisogno di accedere solo a un piccolo insieme di spazi dei nomi correlati.
Per supportare casi d'uso multi-tenant, gli spazi dei nomi gerarchici supportano diverse funzionalità oltre a quelle dei normali spazi dei nomi Kubernetes:
- Applicazione delle norme. Gli spazi dei nomi gerarchici possono ereditare determinati criteri dai loro predecessori tramite l'uso della propagazione. Ad esempio, ciò consente di concedere autorizzazioni RBAC in uno spazio dei nomi "root" e Hierarchy Controller garantisce che queste autorizzazioni siano anche in tutti gli spazi dei nomi discendenti copiando (propagando) gli oggetti RBAC in questi discendenti. La propagazione può anche essere controllata a un livello granulare utilizzando le eccezioni.
- Applicazione delle norme. Tutti gli spazi dei nomi gerarchici includono etichette attendibili e note che riflettono i predecessori. Queste etichette possono essere usate nei selettori di etichette per criteri come la convalida delle configurazioni webhook o dei criteri di rete.
- Quota gerarchica. È possibile definire un'unica quota gerarchica in uno spazio dei nomi dei predecessori e i limiti vengono applicati automaticamente all'utilizzo aggregato di quello spazio dei nomi e di tutti i suoi discendenti.
- Osservabilità gerarchica. Le etichette attendibili utilizzate per l'applicazione dei criteri possono essere utilizzate anche per osservare i carichi di lavoro gerarchici, ad esempio per filtrare i log o l'utilizzo.
- Creazione dello spazio dei nomi delegato. Hierarchy Controller introduce il concetto di spazio dei nomi secondario, che può essere creato dagli utenti in uno spazio dei nomi esistente anche se l'utente non dispone di privilegi dello spazio dei nomi a livello di cluster.
Gli spazi dei nomi gerarchici supportano anche funzionalità di amministrazione estese, inclusa la delega.
Spazi dei nomi gerarchici e spazi dei nomi astratti
Gli spazi dei nomi gerarchici forniti da Hierarchy Controller sono simili a quelli astratti che puoi utilizzare se utilizzi un repository di Config Sync. Tuttavia, presentano diverse differenze concettuali:
- Gli spazi dei nomi astratti possono essere definiti solo in un repository gerarchico, che applica una particolare struttura alle tue configurazioni. Gli spazi dei nomi gerarchici possono essere utilizzati in repository non strutturati, consentendoti di organizzare i file di configurazione come preferisci.
- Gli spazi dei nomi astratti esistono solo nei repository Git, mentre quelli gerarchici sono anche spazi dei nomi Kubernetes normali ed esistono nel cluster. Di conseguenza, gli spazi dei nomi gerarchici possono essere definiti in un repository o direttamente nel cluster.
- La creazione degli spazi dei nomi gerarchici non richiede autorizzazioni a livello di cluster. Puoi invece utilizzare gli spazi dei nomi secondari per la creazione dello spazio dei nomi eliminato.
- Le quote delle risorse gerarchiche sono supportate solo negli spazi dei nomi gerarchici, non in quelli astratti.
- Gli spazi dei nomi astratti sono disponibili solo per Config Sync, mentre gli spazi dei nomi gerarchici sono basati su concetti open source.
Gli spazi dei nomi astratti e gerarchici hanno anche alcuni comportamenti predefiniti diversi. Per impostazione predefinita, tutti gli oggetti creati in uno spazio dei nomi astratto vengono propagati ai relativi discendenti. Al contrario, gli oggetti negli spazi dei nomi gerarchici vengono propagati solo se Hierarchy Controller è stato configurato per la propagazione di quel tipo di oggetto.
Per impostazione predefinita, vengono propagati solo i ruoli e le associazioni di ruoli RBAC, ma è possibile propagare qualsiasi oggetto con spazio dei nomi. Ti consigliamo di propagare solo gli oggetti dei criteri (come i ruoli) e gli oggetti delle risorse (come le mappe di configurazione). Hierarchy Controller non è progettato per propagare oggetti dei carichi di lavoro come pod, deployment o job e può produrre conseguenze impreviste se utilizzato in questo modo. Ti consigliamo di inserire i carichi di lavoro in spazi dei nomi foglia.
Utilizzo di Hierarchy Controller con Config Sync
Hierarchy Controller consente di definire e applicare criteri utilizzando concetti gerarchici, adatti a molte applicazioni, inclusi i cluster utilizzati da più team. Config Sync consente di archiviare i criteri in un repository Git e applicarli a gruppi di cluster. Sebbene siano diverse, queste due funzionalità sono gratuite e offrono un modo efficace per applicare GitOps in ambienti multi-team e multi-cluster.
Quando utilizzi Hierarchy Controller con Config Sync, ti consigliamo di utilizzare un repository non strutturato per disabilitare gli spazi dei nomi astratti di Config Sync e di utilizzare Hierarchy Controller per definire le gerarchie e propagare i criteri. Per gli spazi dei nomi di cui vuoi eseguire il check-in nel repository, ti consigliamo di controllare nelle configurazioni solo gli spazi dei nomi completi, non gli spazi dei nomi secondari, poiché puoi aggiornare le relative relazioni gerarchiche modificando l'oggetto HierarchicalConfiguration.
È possibile utilizzare Hierarchy Controller insieme agli spazi dei nomi astratti di Config Sync in un repository gerarchico, ma solo in modi limitati. Ad esempio, Hierarchy Controller non ti consente di creare una relazione gerarchica tra due spazi dei nomi definiti in un repository gerarchico, in quanto ciò potrebbe entrare in conflitto con gli spazi dei nomi astratti in quel repository. Tuttavia, puoi utilizzare spazi dei nomi gerarchici con un repository gerarchico nei seguenti modi:
- Puoi creare spazi dei nomi self-service nel cluster, sotto uno spazio dei nomi creato da un repository gerarchico. Tuttavia, ti sconsigliamo di controllare le configurazioni di questi spazi dei nomi secondari.
- Se utilizzi più repository, puoi creare ancoraggio dei sottonomi nei repository degli spazi dei nomi, che indicano a Hierarchy Controller di creare spazi dei nomi secondari sotto lo spazio dei nomi specificato. Questi spazi dei nomi erediteranno tutte le risorse configurate dai rispettivi predecessori e saranno vincolati da eventuali quote gerarchiche delle risorse. Tuttavia, non puoi definire risorse che devono esistere solo in questi spazi dei nomi secondari; Config Sync sincronizzerà tutti gli oggetti nel repository dello spazio dei nomi con lo spazio dei nomi specificato.