Hierarchy Controller aggiunge funzionalità gerarchiche Spazi dei nomi Kubernetes, che ti consentono di scrivere più espressivi, migliorare l'osservabilità e delegare l'amministrazione dei cluster.
Hierarchy Controller si basa su HNC (Hierarchical Namespace Controller) 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à fondamentale dell'isolamento e della sicurezza in 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 di spazi dei nomi nei cluster, il che può essere difficile da gestire.
Per risolvere questo problema, Hierarchy Controller introduce il concetto di spazi dei nomi gerarchici, che ti consentono di raggruppare gli spazi dei nomi Kubernetes in base ai proprietari. e manipolarli 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 automatico la proprietà di un insieme di spazi dei nomi, soprattutto se richiede autorizzazioni molto ampie ma solo 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 attraverso l'uso 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 le etichette attendibili e note che riflettono i loro antenati. Queste etichette possono essere utilizzate nei selettori di etichette per criteri come la convalida delle configurazioni dei webhook o dei criteri di rete.
- Quota gerarchica. Puoi definire un singolo quota gerarchica in uno spazio dei nomi predecessore e i limiti vengono applicati automaticamente l'utilizzo aggregato di quello spazio dei nomi e di 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 la classe concetto di spazio dei nomi, che possono essere creati dagli utenti in uno spazio dei nomi esistente anche se non dispone di privilegi per lo spazio dei nomi a livello di cluster.
Gli spazi dei nomi gerarchici supportano anche funzionalità di amministrazione, inclusa la delega.
Spazi dei nomi gerarchici e 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, presentano diverse differenze concettuali:
- Gli spazi dei nomi astratti possono essere definiti solo in un repository gerarchico, applica una particolare struttura alle tue 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 quelli gerarchici sono normali spazi dei nomi Kubernetes 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. Puoi invece utilizzare gli spazi dei nomi secondari per creare uno spazio dei nomi eliminato.
- 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.
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 propagata ai suoi discendenti. Al contrario, gli oggetti negli spazi dei nomi gerarchici vengono propagati solo se è stato eseguito configurati 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 di risorse (come le mappe di configurazione). Hierarchy Controller non è progettato per propagare gli oggetti dei carichi di lavoro, a pod, deployment o job e possono generare conseguenze indesiderate se utilizzati in 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 adatti a molte applicazioni, compresi i cluster utilizzati più team. Config Sync ti consente di archiviare questi criteri in un repository e 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.
Se usi Hierarchy Controller con Config Sync, ti consigliamo
che utilizzi
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
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 spazi dei nomi astratti in un repository gerarchico, ma solo in modi limitati. Ad esempio, Hierarchy Controller non ti consente di creare un modello relazione tra due spazi dei nomi definiti in modo gerarchico poiché potrebbero entrare in conflitto con gli spazi dei nomi astratti del 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 ancoraggi nello spazio dei nomi secondari nei repository degli spazi dei nomi, che istruiscono il controllo di gerarchia per creare spazi dei nomi secondari sotto lo spazio dei nomi specificato. Questi che erediteranno tutte le risorse configurate dai suoi predecessori e sarà vincolata da qualsiasi quote gerarchiche delle risorse. Tuttavia, non puoi definire risorse che dovrebbero esistere solo in questi subnamespaces; Config Sync sincronizzerà tutti gli oggetti nello spazio dei nomi repository nello spazio dei nomi specificato.