Hierarchy Controller aggiunge funzionalità gerarchiche agli spazi dei nomi Kubernetes, che ti consentono di scrivere criteri più espressivi, migliorare l'osservabilità e delegare l'amministrazione del cluster.
Hierarchy Controller si basa su Hierarchical Namespace Controller (HNC), un progetto open source. È implementato utilizzando Kubernetes controller e controller di ammissione dinamici che vengono eseguiti nel tuo cluster.
Spazi dei nomi gerarchici
In Kubernetes, spazi dei nomi sono l'unità fondamentale di organizzazione della maggior parte degli oggetti. Inoltre, costituiscono l'unità di isolamento e sicurezza di base di Kubernetes. La maggior parte dei criteri e gli oggetti di isolamento operano a livello dello 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 per contenere il numero più basso di risorse, come una singola microservizio, oltre alle relative risorse e criteri. Tuttavia, questo può portare a un gran numero di spazi dei nomi nei cluster, che possono essere difficili da gestire.
Per risolvere il problema, Hierarchy Controller introduce il concetto di spazi dei nomi gerarchici, che ti consente di raggruppare gli spazi dei nomi Kubernetes in base ai relativi proprietari e di manipolare questi gruppi come unità coese. Sono particolarmente utili per condivisi da più team, ma non è necessario che i proprietari siano persone. Ad esempio, potresti voler assegnare a uno strumento automatizzato il ruolo di proprietario di un insieme di spazi dei nomi, soprattutto se richiede autorizzazioni molto ampie, ma ha bisogno solo di accedere a un piccolo insieme di spazi dei nomi correlati.
Per supportare casi d'uso multi-tenant, gli spazi dei nomi gerarchici supportano diversi funzioni aggiuntive oltre a quelle dei normali spazi dei nomi Kubernetes:
- Applicazione delle norme. Gli spazi dei nomi gerarchici possono ereditare determinati criteri dai loro antenati tramite l'uso della propagazione. Ad esempio, questo ti consente di concedere autorizzazioni RBAC in una directory "root" spazio dei nomi Hierarchy Controller assicura che tali autorizzazioni siano presenti anche in tutti discendenti copiando (propagando) gli oggetti RBAC in questi discendenti. La propagazione può anche essere controllata a un livello granulare utilizzando eccezioni.
- Applicazione dei criteri. Tutti gli spazi dei nomi gerarchici includono etichette note e attendibili che riflettono i loro antenati. Queste etichette possono essere utilizzate nei selettori di etichette per i criteri, ad esempio per convalidare le configurazioni degli webhook o i criteri di rete.
- Quota gerarchica. Puoi definire una singola quota gerarchica in uno spazio dei nomi principale e i limiti vengono applicati automaticamente all' utilizzo aggregato di questo spazio dei nomi, nonché a tutti i suoi discendenti.
- Osservabilità gerarchica. Le etichette attendibili utilizzate per l'applicazione dei criteri può essere utilizzato anche osservare 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 sottospazio dei nomi, che può essere creato dagli utenti in uno spazio dei nomi esistente anche se non dispongono dei privilegi di spazio dei nomi a livello di cluster.
Gli spazi dei nomi gerarchici supportano anche ampie funzionalità di amministrazione, tra cui la delega.
Spazi dei nomi gerarchici e spazi dei nomi astratti
Gli spazi dei nomi gerarchici forniti da Hierarchy Controller sono simili gli spazi dei nomi astratti che puoi utilizzare se usi Config Sync repository gerarchico. Tuttavia, esistono diverse differenze concettuali:
- Gli spazi dei nomi astratti possono essere definiti solo in un repository gerarchico, che impone una determinata struttura alle configurazioni. Gli spazi dei nomi gerarchici possono essere utilizzato in 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 anche spazi dei nomi Kubernetes regolari ed esistono nel cluster. Come Ne consegue che gli spazi dei nomi gerarchici possono essere definiti in un repository direttamente sul cluster.
- La creazione degli spazi dei nomi gerarchici non richiede autorizzazioni a livello di cluster. In alternativa, puoi utilizzare gli spazi dei nomi secondari per la creazione di spazi dei nomi eliminati.
- Quote gerarchiche delle risorse sono supportati solo negli spazi dei nomi gerarchici, non astratti.
- Gli spazi dei nomi astratti sono disponibili solo per Config Sync, mentre quelli gerarchici gli spazi dei nomi si basano 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 propagare quel tipo di oggetto.
Per impostazione predefinita, vengono propagati solo i ruoli e le associazioni di ruoli RBAC, ma qualsiasi con spazio dei nomi può essere propagato. Ti consigliamo di propagare solo il criterio oggetti (come ruoli) e oggetti risorsa (come le mappe di configurazione). Hierarchy Controller non è progettato per propagare oggetti di carico di lavoro come pod, implementazioni o job e potrebbe produrre conseguenze indesiderate se utilizzato in questo modo. Ti consigliamo di inserire i carichi di lavoro in spazi dei nomi fogli.
Utilizzo di Hierarchy Controller con Config Sync
Hierarchy Controller consente di definire e applicare criteri utilizzando adatti a molte applicazioni, compresi i cluster utilizzati più team. Config Sync ti consente di archiviare questi criteri in un repository Git e di applicarli a gruppi di cluster. Sebbene diversi, questi due sono inclusi nel prezzo e rappresentano un modo efficace per applicare GitOps ambienti multi-team e multi-cluster.
Quando utilizzi Hierarchy Controller con Config Sync, ti consigliamo di utilizzare un repository non strutturato per disattivare gli spazi dei nomi astratti di Config Sync e di utilizzare Hierarchy Controller per definire le gerarchie e propagare i criteri. Per
di spazio dei nomi che vuoi controllare nel repository, ti consigliamo di controllare
per
spazi dei nomi completi,
non in spazi dei nomi secondari, perché puoi aggiornarne le relazioni gerarchiche
Modifica dell'oggetto HierarchicalConfiguration
.
È possibile utilizzare Hierarchy Controller insieme a Config Sync per astrarre gli spazi dei nomi 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 potrebbe essere in conflitto con gli spazi dei nomi astratti in quel repository. Tuttavia, puoi utilizzare spazi dei nomi gerarchici con un repository gerarchico in nei seguenti modi:
- Puoi creare spazi dei sottonomi self-service sul cluster, sotto un creato da un repository gerarchico. Tuttavia, non ti consigliamo di controllare le configurazioni di questi spazi dei nomi secondari.
- Se utilizzi più repository, puoi creare ancore di sottospazio dei nomi nei repository degli spazi dei nomi, che indicheranno a Hierarchy Controller di creare sottospazi dei nomi sotto lo spazio dei nomi specificato. Questi subnamespaces erediteranno tutte le risorse configurate dai relativi antenati e saranno vincolati da eventuali quote di risorse gerarchiche. Tuttavia, non puoi definire risorse che debbano esistere solo in questi sottospazi dei nomi. Config Sync sincronizzerà tutti gli oggetti nel repository dello spazio dei nomi con lo spazio dei nomi specificato.