Panoramica di Hierarchy Controller

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 è integrato in Config Sync versione 1.4.1 e successive, ma non richiede l'utilizzo di un repository Config Sync. Ciò significa che puoi utilizzare Hierarchy Controller interamente nel cluster, senza utilizzare GitOps.

Hierarchy Controller si basa sul Hierarchical Namespace Controller (HNC), un progetto open source. Viene implementato 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à di base dell'isolamento e della 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 dei tuoi cluster scegliendo come ambito ogni spazio dei nomi in modo che contenga il minor numero di risorse, ad esempio un singolo microservizio, oltre alle relative risorse e criteri. Tuttavia, ciò può portare a un numero elevato di spazi dei nomi nei tuoi cluster, il che può essere difficile da gestire.

Per risolvere il 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à coerenti. Sono particolarmente utili nei cluster condivisi da più team, ma non è necessario che i proprietari siano persone. Ad esempio, potresti voler fare in modo che uno strumento automatico diventi proprietario di una serie di spazi dei nomi, soprattutto se richiede autorizzazioni molto ampie, ma necessita solo dell'accesso a un piccolo insieme di spazi dei nomi correlati.

Per supportare casi d'uso multi-tenant, gli spazi dei nomi gerarchici supportano numerose funzionalità oltre a quelle degli spazi dei nomi Kubernetes standard:

  • Applicazione delle norme. Gli spazi dei nomi gerarchici possono ereditare determinati criteri dai rispettivi antenati utilizzando l'propagazione. Ad esempio, ciò ti permette di concedere autorizzazioni RBAC in uno spazio dei nomi "root" e Hierarchy Controller garantisce che tali autorizzazioni siano anche in tutti gli spazi dei nomi discendenti copiando (propagando) gli oggetti RBAC a questi discendenti. La propagazione può essere controllata anche 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 delle etichette per i criteri come la convalida delle configurazioni webhook o dei criteri di rete.
  • Quota gerarchica. Puoi definire una singola quota gerarchica in uno spazio dei nomi predecessori e i limiti vengono applicati automaticamente all'utilizzo aggregato di tale spazio dei nomi, nonché 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 di spazi dei nomi delegati. Hierarchy Controller introduce il concetto di subnamespace, che può essere creato da utenti con uno spazio dei nomi esistente anche se quell'utente non dispone di privilegi per lo 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 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, hanno diverse differenze concettuali:

  • Gli spazi dei nomi astratti possono essere definiti solo in un repository gerarchico, il che applica una determinata struttura 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 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.
  • Gli spazi dei nomi gerarchici non richiedono autorizzazioni a livello di cluster per la creazione. 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 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.

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 sono propagati ai suoi discendenti. Al contrario, gli oggetti negli spazi dei nomi gerarchici vengono propagati solo se Hierarchy Controller è stato configurato per propagare tale tipo di oggetto.

Per impostazione predefinita, si propagano solo ruoli RBAC e associazioni di ruoli, ma è possibile propagare qualsiasi oggetto con spazio dei nomi. Ti consigliamo di propagare solo oggetti oggetto (come i ruoli) e oggetti risorsa (come le mappe di configurazione). Hierarchy Controller non è progettato per propagare oggetti del carico di lavoro come pod, deployment o job e potrebbe causare conseguenze impreviste se utilizzato in questo modo. Consigliamo di inserire i carichi di lavoro negli spazi dei nomi delle foglie.

Utilizzo di Hierarchy Controller con Config Sync

Hierarchy Controller ti consente di definire e applicare criteri utilizzando concetti gerarchici, adatti a molte applicazioni, tra cui cluster utilizzati da più team. Config Sync consente di archiviare questi criteri in un repository Git e di applicarli a gruppi di cluster. Sebbene diverse, queste due funzionalità sono gratuite e offrono un modo efficace per applicare GitOps in ambienti multi-team.

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 di utilizzare Hierarchy Controller per definire le gerarchie e propagare i criteri. Per gli spazi dei nomi che vuoi fare il check-in nel tuo repository, ti consigliamo di controllare solo le configurazioni per gli spazi dei nomi completi, non gli spazi dei sottodomini, perché puoi aggiornare le loro relazioni gerarchiche modificando l'oggetto HierarchicalConfiguration.

È possibile utilizzare Hierarchy Controller insieme a Config Sync come spazi dei nomi in un repository gerarchico, ma solo in modo limitato. Ad esempio, Hierarchy Controller non consente di creare una relazione gerarchica tra due spazi dei nomi definiti in un repository gerarchico, poiché ciò potrebbe entrare in conflitto con gli spazi dei nomi astratti in tale repository. Tuttavia, puoi utilizzare spazi dei nomi gerarchici con un repository gerarchico nelle modalità seguenti:

  • Puoi creare spazi dei nomi self-service sul cluster, sotto uno spazio dei nomi creato da un repository gerarchico. Tuttavia, non è consigliabile controllare le configurazioni per questi spazi dei nomi secondari.
  • Se utilizzi più repository, puoi creare ancoraggi spazio dei nomi nei repository degli spazi dei nomi, che istruiranno il controller della gerarchia per creare spazi dei nomi sotto lo spazio dei nomi specificato. Questi spazi secondari erediteranno tutte le risorse configurate dai suoi antenati e saranno vincolati da eventuali quote delle risorse gerarchiche. Tuttavia, non puoi definire le risorse che dovrebbero 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.

Passaggi successivi