Panoramica di Hierarchy Controller
Gerarchia del controller aggiunge funzionalità gerarchiche agli spazi dei nomi Kubernetes, che ti consentono di scrivere criteri più espressivi, migliorare l'osservabilità e delegare l'amministrazione dei cluster.
Hierarchy Controller è integrato in Config Sync versione 1.4.1 e successive, ma non richiede l'utilizzo di un repository Config Sync. Vale a dire che puoi utilizzare il controller della gerarchia interamente sul cluster, senza utilizzare GitOps.
Hierarchy Controller si basa su Hierarchical Namespace Controller (HNC), un progetto open source. Si implementa utilizzando i controller e i controller di ammissione dinamici di Kubernetes eseguiti nel cluster.
Spazi dei nomi gerarchici
In Kubernetes, gli spazi dei nomi sono l'unità fondamentale dell'organizzazione della maggior parte degli oggetti. Inoltre, costituiscono l'unità fondamentale di isolamento e sicurezza in Kubernetes. La maggior parte dei criteri e degli oggetti di isolamento opera a livello di spazio dei nomi, come 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 applicando l'ambito a ogni spazio dei nomi per contenere il minor numero di risorse, ad esempio un singolo microservizio, oltre alle relative risorse e criteri. Tuttavia, questo può portare a un numero elevato di spazi dei nomi nei tuoi 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à coesive. Sono particolarmente utili nei cluster condivisi da più team, ma i proprietari non devono essere necessariamente persone. Ad esempio, potresti voler rendere uno strumento automatico il proprietario di un insieme di spazi dei nomi, soprattutto se quest'ultimo richiede autorizzazioni molto ampie ma ha bisogno solo dell'accesso a un piccolo insieme di spazi dei nomi correlati.
Per supportare i 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 dagli antenati utilizzando la propagazione. Ad esempio, ciò ti consente di concedere le autorizzazioni RBAC in uno spazio dei nomi "root" e il controller della gerarchia garantisce che tali autorizzazioni si trovino anche in tutti gli spazi dei nomi discendenti copiando (propagando) gli oggetti RBAC in questi discendenti. La propagazione può anche essere controllata a livello granulare utilizzando le eccezioni.
- Applicazione delle norme. Tutti gli spazi dei nomi gerarchici includono etichette attendibili e note che riflettono i loro antenati. Queste etichette possono essere utilizzate nei selettori di etichette per criteri come la convalida di configurazioni di webhook o di rete.
- Quota gerarchica. Puoi definire una singola quota gerarchica in uno spazio dei nomi predecessore e i limiti vengono applicati automaticamente all'utilizzo aggregato di tale spazio dei nomi e a 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 di spazi dei nomi delegati. Gerarchia Controller introduce il concetto di spazio dei nomi secondario, che può essere creato dagli utenti con uno spazio dei nomi esistente anche se non dispongono di privilegi per lo spazio dei nomi a livello di cluster.
Gli spazi dei nomi gerarchici supportano anche ampie funzionalità di amministrazione, inclusa la delega.
Spazi dei nomi gerarchici rispetto a spazi dei nomi astratti
Gli spazi dei nomi gerarchici forniti da Hierarchy Controller sono simili agli spazi dei nomi astratti che puoi utilizzare se utilizzi un repository gerarchico di Config Sync. Tuttavia, presentano diverse differenze concettuali:
- Gli spazi dei nomi astratti possono essere definiti solo in un repository gerarchico, il che applica una particolare struttura alle configurazioni. Puoi utilizzare gli spazi dei nomi gerarchici nei repository non strutturati, così puoi 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 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.
- Gli spazi dei nomi gerarchici non richiedono autorizzazioni a livello di cluster. Puoi invece utilizzare spazi dei nomi secondari per la creazione di spazi dei nomi eliminati.
- Le quote gerarchiche delle risorse sono supportate solo negli spazi dei nomi gerarchici, non negli spazi dei nomi astratti.
- Gli spazi dei nomi astratti sono disponibili solo per Config Sync, mentre gli spazi dei nomi gerarchici si basano su concetti open source.
Anche gli spazi dei nomi astratti e gerarchici hanno alcuni comportamenti predefiniti diversi. Per impostazione predefinita, tutti gli oggetti creati in uno spazio dei nomi astratto vengono propagati ai discendenti. Al contrario, gli oggetti negli spazi dei nomi gerarchici vengono propagati solo se il controller della gerarchia è stato configurato per propagare il tipo di oggetto.
Per impostazione predefinita, vengono propagati solo i ruoli RBAC e le associazioni di ruoli, ma è possibile propagare qualsiasi oggetto con spazio dei nomi. Ti consigliamo di propagare solo gli oggetti criterio (come i ruoli) e gli oggetti delle risorse (come le mappe di configurazione). Gerarchia Controller non è progettato per propagare oggetti del carico di lavoro come pod, deployment o job e può produrre conseguenze indesiderate se utilizzati in questo modo. Ti consigliamo di inserire i carichi di lavoro in spazi dei nomi foglia.
Utilizzo di Gerarchia controller con Config Sync
Gerarchia del controller consente di definire e applicare criteri utilizzando concetti gerarchici, che sono adatti a molte applicazioni, inclusi i cluster utilizzati da più team. Config Sync consente di archiviare i criteri in un repository Git e di applicarli a gruppi di cluster. Pur essendo diverse, queste due funzionalità sono gratuite e ti offrono un modo efficace per applicare GitOps in ambienti multi-team e multi-cluster.
Quando usi Gerarchia 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 Gerarchia Controller per definire le gerarchie e propagare i criteri. Per gli spazi dei nomi che vuoi controllare nel tuo repository, ti consigliamo di controllare solo le configurazioni degli spazi dei nomi completi, non degli spazi dei nomi secondari, perché puoi aggiornare le loro relazioni gerarchiche modificando l'oggetto HierarchicalConfiguration.
È possibile utilizzare Gerarchia Controller insieme agli spazi dei nomi astratti Config Sync in un repository gerarchico, ma solo in modi limitati. Ad esempio, Gerarchia controller non ti consentirà di creare una relazione gerarchica tra due spazi dei nomi definiti in un repository gerarchico, in quanto questo potrebbe entrare in conflitto con gli spazi dei nomi astratti nel repository. Tuttavia, puoi utilizzare gli spazi dei nomi gerarchici con un repository gerarchico nei modi seguenti:
- Puoi creare spazi dei nomi self-service nel cluster, sotto uno spazio dei nomi creato da un repository gerarchico. Tuttavia, sconsigliamo di controllare le configurazioni degli spazi dei nomi secondari.
- Se utilizzi più repository, puoi creare ancoraggi di spazi secondari nei repository di spazi dei nomi, che spiegheranno al controller della gerarchia di creare spazi di nomi secondari sotto lo spazio dei nomi specificato. Questi spazi dei nomi erediteranno tutte le risorse configurate dai loro antenati e saranno vincolati da eventuali quote di risorse gerarchiche. Tuttavia, non puoi definire risorse che dovrebbero esistere solo in questi spazi dei nomi secondari; Config Sync sincronizzerà tutti gli oggetti del repository dello spazio dei nomi con lo spazio dei nomi specificato.