Hierarchy Controller aggiunge funzionalità gerarchiche agli spazi dei nomi Kubernetes, che consentono di scrivere criteri più espressivi, migliorare l'osservabilità e delegare l'amministrazione dei cluster.
Hierarchy Controller si basa su Hierarchical Namespace Controller (HNC), un progetto open source. Viene implementata utilizzando controller Kubernetes e controller di ammissione dinamici in esecuzione nel cluster.
Spazi dei nomi gerarchici
In Kubernetes, gli spazi dei nomi sono l'unità fondamentale dell'organizzazione della maggior parte degli oggetti. Costituiscono inoltre 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 cluster definendo l'ambito di ogni spazio dei nomi in modo che contenga il numero più basso di risorse, ad esempio un singolo microservizio, insieme alle relative risorse e ai relativi criteri. Tuttavia, questo può portare a un numero elevato di spazi dei nomi nei cluster, che può essere difficile 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 relativi proprietari e di manipolare questi gruppi come unità coese. 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 la proprietà di un insieme di spazi dei nomi, soprattutto se richiede autorizzazioni molto ampie, ma deve 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 predecessori mediante l'uso della propagazione. Ad esempio, questo ti consente di concedere autorizzazioni RBAC in uno spazio dei nomi "root" e Hierarchy Controller garantisce che queste autorizzazioni siano presenti 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 tramite eccezioni.
- Applicazione dei criteri. Tutti gli spazi dei nomi gerarchici includono etichette attendibili e note che riflettono i predecessori. Queste etichette possono essere usate nei selettori delle etichette per criteri come la convalida delle configurazioni dei webhook o dei criteri di rete.
- Quota gerarchica. Puoi definire una singola quota gerarchica in uno spazio dei nomi predecessore e i limiti vengono applicati automaticamente sull'utilizzo aggregato di questo spazio dei nomi e di tutti i relativi 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 secondari, che può essere creato dagli utenti all'interno di 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 numerose funzionalità di amministrazione, inclusa la delega.
Spazi dei nomi gerarchici e astratti
Gli spazi dei nomi gerarchici forniti da Hierarchy Controller sono simili a quelli astratti che puoi utilizzare se utilizzi un repository gerarchico di Config Sync. Tuttavia, esistono diverse differenze concettuali:
- Gli spazi dei nomi astratti possono essere definiti solo in un repository gerarchico, il che applica una struttura particolare alle tue configurazioni. Gli spazi dei nomi gerarchici possono essere utilizzati nei repository non strutturati, consentendoti di organizzare i file di configurazione come preferisci.
- Gli spazi dei nomi astratti esistono solo nei repository Git, mentre gli spazi dei nomi gerarchici sono anch'essi normali spazi dei nomi Kubernetes e 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 creare uno spazio dei nomi eliminato.
- Le quote di 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 quelli gerarchici si basano su concetti open source.
Anche gli spazi dei nomi astratti e gerarchici presentano 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 propagare quel tipo di oggetto.
Per impostazione predefinita vengono propagati solo i ruoli e le associazioni di ruoli RBAC, ma è possibile propagare qualsiasi oggetto con spazi dei nomi. Ti consigliamo di propagare solo gli oggetti dei criteri (come i ruoli) e gli oggetti di risorse (come le mappe di configurazione). Hierarchy Controller non è progettato per propagare gli oggetti dei carichi di lavoro come pod, deployment o job e può produrre conseguenze indesiderate se utilizzato in questo modo. Consigliamo di inserire i carichi di lavoro negli 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 questi criteri in un repository Git e di applicarli a gruppi di cluster. Anche se diverse, queste due funzionalità sono complementari e offrono un modo potente per applicare GitOps in ambienti multi-team e multi-cluster.
Se 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 utilizzare Hierarchy Controller per definire le gerarchie e propagare i criteri. Per gli
spazi dei nomi che vuoi archiviare nel repository, ti consigliamo di controllare
nelle configurazioni solo gli
spazi dei nomi completi,
non quelli dei sottonomi, poiché puoi aggiornare le 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, poiché ciò potrebbe essere in conflitto con gli spazi dei nomi astratti del repository. Tuttavia, puoi utilizzare gli spazi dei nomi gerarchici con un repository gerarchico nei seguenti modi:
- Puoi creare spazi dei sottonomi 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 ancoraggi dello spazio dei nomi secondari nei repository degli spazi dei nomi, in modo da indicare a Gerarchia di creare spazi dei sottonomi sotto lo spazio dei nomi specificato. Questi spazi dei nomi erediteranno tutte le risorse configurate dai rispettivi predecessori e saranno vincolati da eventuali quote delle risorse gerarchiche. 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.