Best practice per architettura multi-tenancy aziendale

La multitenancy in Google Kubernetes Engine (GKE) si riferisce a uno o più cluster condivisi tra i tenant. In Kubernetes, un tenant può essere definito come uno dei seguenti elementi:

  • Un team responsabile dello sviluppo e del funzionamento di uno o più carichi di lavoro.
  • Un insieme di carichi di lavoro correlati, gestiti da uno o più team.
  • Un singolo carico di lavoro, ad esempio un deployment.

L'architettura multi-tenancy del cluster viene spesso implementata per ridurre i costi o per applicare in modo coerente le norme di amministrazione ai vari tenant. Tuttavia, la configurazione errata di un cluster GKE o delle risorse GKE associate può comportare risparmi sui costi non raggiunti, applicazione errata dei criteri o interazioni dannose tra i carichi di lavoro di diversi tenant.

Questa guida fornisce best practice per configurare in modo sicuro ed efficiente più cluster multi-tenant per un'organizzazione aziendale.

Presupposti e requisiti

Le best practice riportate in questa guida si basano su un caso d'uso multi-tenant per un ambiente aziendale, che presenta le seguenti ipotesi e requisiti:

  • L'organizzazione è una singola azienda con molti tenant (due o più team di applicazioni/servizi) che utilizzano Kubernetes e vogliono condividere risorse di calcolo e amministrative.
  • Ogni tenant è un singolo team che sviluppa un singolo carico di lavoro.
  • Oltre ai team di applicazioni/servizi, esistono altri team che utilizzano e gestiscono i cluster, tra cui membri del team della piattaforma, amministratori dei cluster, revisori e così via.
  • Il team della piattaforma è proprietario dei cluster e definisce la quantità di risorse che ogni team del tenant può utilizzare. Ogni tenant può richiederne di più.
  • Ogni team del tenant deve essere in grado di eseguire il deployment della propria applicazione tramite l'API Kubernetes senza dover comunicare con il team della piattaforma.
  • Ogni tenant non deve essere in grado di influire su altri tenant nel cluster condiviso, tranne tramite decisioni di progettazione esplicite come chiamate API, origini dati condivise e così via.

Questa configurazione fungerà da modello da cui potremo dimostrare le best practice per il multi-tenant. Sebbene questa configurazione potrebbe non descrivere perfettamente tutte le organizzazioni aziendali, può essere facilmente estesa per coprire scenari simili.

Configurazione di cartelle, progetti e cluster

Best practice:

Stabilire una gerarchia di cartelle e progetti.
Assegna i ruoli utilizzando IAM.
Centralizza il controllo della rete con le VPC condivise.
Crea un progetto di amministrazione del cluster per cluster.
Imposta i cluster come privati.
Assicurati che il piano di controllo del cluster sia a livello di regione.
Assicurati che i nodi del cluster siano distribuiti su almeno tre zone.
Scalabilità automatica dei nodi e delle risorse del cluster.
Pianifica i periodi di manutenzione per le ore di punta.
Configura un bilanciatore del carico delle applicazioni esterno con Ingress.

Per le organizzazioni enterprise che eseguono il deployment di cluster multi-tenant in GKE, è necessaria una configurazione aggiuntiva in altri sistemi Google Cloud per gestire la complessità che non esiste nei deployment Kubernetes più semplici con una sola applicazione e un solo team. Sono inclusi la configurazione del progetto per isolare i problemi amministrativi, la mappatura della struttura dell'organizzazione alle identità e agli account cloud e la gestione di risorse Google Cloud aggiuntive, come database, logging e monitoraggio, archiviazione e networking.

Stabilire una gerarchia di cartelle e progetti

Per capire in che modo la tua organizzazione gestisce le risorse di Google Cloud e per applicare una separazione dei problemi, utilizza le cartelle e i progetti. Le cartelle consentono a team diversi di impostare criteri che si applicano in modo gerarchico a più progetti, mentre i progetti possono essere utilizzati per separare gli ambienti (ad esempio, produzione e gestione temporanea) e i team. Ad esempio, la maggior parte delle organizzazioni ha un team per gestire l'infrastruttura di rete e un altro team per gestire i cluster. Ogni tecnologia è considerata un componente separato dello stack che richiede un proprio livello di competenza, risoluzione dei problemi e accesso.

Una cartella principale può contenere fino a 300 cartelle e puoi nidificare le cartelle fino a 10 livelli. Se hai più di 300 tenant, puoi organizzarli in gerarchie nidificate per rispettare il limite. Per saperne di più sulle cartelle, consulta Creare e gestire le cartelle.

Assegnare i ruoli utilizzando IAM

Puoi controllare l'accesso alle risorse Google Cloud tramite i criteri IAM. Per iniziare, identifica i gruppi necessari per la tua organizzazione e il loro ambito di operazioni, quindi assegna al gruppo il ruolo IAM appropriato.

Utilizza Google Gruppi per assegnare e gestire in modo efficiente IAM per gli utenti.

Centralizzare il controllo della rete

Per mantenere il controllo centralizzato sulle risorse di rete, come subnet, route e firewall, utilizza le reti VPC condivise. Le risorse in un VPC condiviso possono comunicare tra loro in modo sicuro ed efficiente oltre i confini dei progetti utilizzando IP interni. Ogni rete VPC condiviso è definita e di proprietà di un progetto host centralizzato e può essere utilizzata da uno o più progetti di servizio.

Con VPC condiviso e IAM, puoi separare l'amministrazione della rete dall'amministrazione del progetto. Questa separazione ti aiuta a implementare il principio del privilegio minimo. Ad esempio, un team di rete centralizzato può gestire la rete senza disporre di autorizzazioni per i progetti partecipanti. Analogamente, gli amministratori del progetto possono gestire le risorse del progetto senza autorizzazioni per manipolare la rete condivisa.

Quando configuri una VPC condiviso, devi configurare le subnet e i relativi intervalli IP secondari nella VPC. Per determinare le dimensioni della subnet, devi conoscere il numero previsto di tenant, il numero di pod e servizi che dovrebbero essere eseguiti e le dimensioni massime e medie dei pod. Il calcolo della capacità totale del cluster necessaria consente di comprendere le dimensioni dell'istanza auspicate e fornisce il numero totale di nodi. Con il numero totale di nodi, è possibile calcolare lo spazio IP totale consumato e fornire la dimensione della subnet desiderata.

Ecco alcuni fattori che dovresti prendere in considerazione anche quando configuri la tua rete:

  • Il numero massimo di progetti di servizio che possono essere associati a un progetto host è 1000 e il numero massimo di progetti host VPC condiviso in una singola organizzazione è 100.
  • Gli intervalli IP di nodi, pod e servizi devono essere tutti univoci. Non puoi creare una subnet i cui intervalli di indirizzi IP principali e secondari si sovrappongono.
  • Il numero massimo di pod e servizi per un determinato cluster GKE è limitato dalle dimensioni degli intervalli secondari del cluster.
  • Il numero massimo di nodi nel cluster è limitato dalle dimensioni dell'intervallo di indirizzi IP primario della subnet e dell'intervallo di indirizzi pod del cluster.
  • Per flessibilità e maggiore controllo sulla gestione degli indirizzi IP, puoi configurare il numero massimo di pod che possono essere eseguiti su un nodo. Riducendo il numero di pod per nodo, riduci anche l'intervallo CIDR allocato per nodo, richiedendo meno indirizzi IP.

Per calcolare le sottoreti per i tuoi cluster, puoi utilizzare lo strumento open source Calcolatore IPAM GKE. La gestione degli indirizzi IP (IPAM) consente un uso efficiente dello spazio IP/delle subnet ed evita sovrapposizioni negli intervalli, il che impedisce le opzioni di connettività in futuro. Per informazioni sugli intervalli di rete in un cluster VPC, consulta Creazione di un cluster nativo di VPC.

Gli utenti che richiedono un'ulteriore isolamento per le risorse in esecuzione al di fuori dei cluster condivisi (ad esempio VM Compute Engine dedicate) possono utilizzare il proprio VPC, accoppiato al VPC condiviso gestito dal team di networking. Ciò garantisce una maggiore sicurezza a fronte di una maggiore complessità e di numerosi altri limiti. Per ulteriori informazioni sul peering, consulta Utilizzare il peering di rete VPC. Nell'esempio riportato di seguito, tutti i tenant hanno scelto di condividere un'unica VPC per tenant (per ambiente).

Creazione di cluster affidabili e ad alta disponibilità

Progetta l'architettura del cluster per l'alta disponibilità e l'affidabilità implementando i seguenti consigli:

  • Crea un progetto di amministrazione del cluster per ogni cluster per ridurre il rischio che le configurazioni a livello di progetto (ad esempio le associazioni IAM) influiscano negativamente su molti cluster e per contribuire a garantire la separazione per quota e fatturazione. I progetti di amministrazione dei cluster sono separati dai progetti tenant, che i singoli tenant utilizzano per gestire, ad esempio, le proprie risorse Google Cloud.
  • Configura l'isolamento della rete per disattivare l'accesso ai nodi e gestire l'accesso al piano di controllo. Inoltre, consigliamo di configurare l'isolamento della rete per gli ambienti di sviluppo e di staging.
  • Assicurati che il piano di controllo del cluster sia regionale per garantire un'alta disponibilità per il multi-tenancy. Eventuali interruzioni del piano di controllo influiranno sugli utenti. Tieni presente che l'esecuzione di cluster regionali comporta implicazioni a livello di costi. I cluster Autopilot sono preconfigurati come cluster regionali.
  • Assicurati che i nodi del cluster siano distribuiti su almeno tre zone per ottenere l'affidabilità zonale. Per informazioni sul costo del traffico in uscita tra zone nella stessa regione, consulta la documentazione relativa ai prezzi di rete.
Un cluster regionale privato con un piano di controllo regionale in esecuzione in tre zone
Figura 3: un cluster regionale privato con un piano di controllo regionale in esecuzione in tre zone.

Scalabilità automatica dei nodi e delle risorse del cluster

Per soddisfare le esigenze dei tuoi tenant, scala automaticamente i nodi del cluster attivando la scalabilità automatica.

La scalabilità automatica consente ai sistemi di apparire reattivi e funzionanti quando carichi di lavoro elevati vengono eseguiti da vari tenant nei loro spazi dei nomi o per rispondere a interruzioni zonali.

Con i cluster Autopilot, i pool di nodi vengono scalati automaticamente per soddisfare i requisiti dei tuoi carichi di lavoro.

Quando attivi la scalabilità automatica, specifichi il numero minimo e massimo di nodi in un cluster in base alle dimensioni del workload previste. Specificando il numero massimo di nodi, puoi assicurarti che sia disponibile spazio sufficiente per tutti i pod nel cluster, indipendentemente dallo spazio dei nomi in cui vengono eseguiti. La scalabilità automatica del cluster ridimensiona i pool di nodi in base al limite minimo/massimo, contribuendo a ridurre i costi operativi quando il carico del sistema diminuisce ed evitando che i pod entrino in uno stato di attesa quando non sono disponibili risorse del cluster sufficienti. Per determinare il numero massimo di nodi, identifica la quantità massima di CPU e memoria richiesta da ciascun tenant e somma queste quantità per ottenere la capacità totale che il cluster dovrebbe essere in grado di gestire se tutti i tenant fossero al limite. Utilizzando il numero massimo di nodi, puoi scegliere le dimensioni e i conteggi delle istanze, tenendo conto dello spazio della subnet IP reso disponibile al cluster.

Utilizza la scalabilità automatica dei pod per scalare automaticamente i pod in base alle richieste di risorse. Horizontal Pod Autoscaler (HPA) scala il numero di repliche del pod in base all'utilizzo della CPU/memoria o a metriche personalizzate. Vertical Pod Autoscaler (VPA) può essere utilizzato per scalare automaticamente le richieste di risorse dei pod. Non deve essere utilizzato con HPA, a meno che non siano disponibili metriche personalizzate, poiché i due regolatori della scalabilità possono competere tra loro. Per questo motivo, inizia con l'HPA e solo in un secondo momento con l'VPA, se necessario.

Determina la dimensione del cluster

Quando determini le dimensioni del cluster, tieni conto di alcuni fattori importanti:

  • Le dimensioni del cluster dipendono dal tipo di carichi di lavoro che prevedi di eseguire. Se i tuoi carichi di lavoro hanno una maggiore densità, l'efficienza in termini di costi è superiore, ma è anche maggiore la probabilità di contesa delle risorse.
  • La dimensione minima di un cluster è definita dal numero di zone che copre: un nodo per un cluster zonale e tre nodi per un cluster regionale.
  • Per progetto, è possibile avere un massimo di 50 cluster per zona, più 50 cluster regionali per regione.

  • Per ogni cluster, ai nodi si applicano i seguenti valori massimi:

    • 1000 nodi per pool di nodi
    • 1000 nodi per cluster (se utilizzi il controller in entrata GKE)
    • 5000 nodi per cluster per impostazione predefinita. Puoi aumentare questo limite fino a 15.000 o 65.000 nodi. Per saperne di più, consulta Cluster con più di 5000 nodi.
    • 256 pod per nodo
    • 150.000 pod per cluster e 300.000 container per cluster

    Per ulteriori informazioni, consulta la pagina Quote e limiti.

Pianificare i periodi di manutenzione

Per ridurre i tempi di inattività durante gli upgrade e la manutenzione del cluster/del nodo, pianifica periodi di manutenzione durante le ore di punta. Durante gli upgrade, possono verificarsi interruzioni temporanee quando i carichi di lavoro vengono spostati per ricreare i nodi. Per garantire un impatto minimo di queste interruzioni, pianifica gli upgrade per le ore di punta e progetta i deployment delle applicazioni in modo da gestire senza problemi le interruzioni parziali, se possibile.

Configura un bilanciatore del carico delle applicazioni esterno con Ingress

Per facilitare la gestione dei servizi pubblicati dei tuoi tenant e del traffico in entrata verso questi servizi, crea un bilanciatore del carico HTTP(S) per consentire un singolo accesso per cluster, in cui i servizi di ciascun tenant sono registrati con la risorsa Ingress del cluster. Puoi creare e configurare un bilanciatore del carico HTTP(S) creando una risorsa Kubernetes Ingress, che definisce in che modo il traffico raggiunge i tuoi servizi e come viene instradato all'applicazione del tuo tenant. Registrando i servizi con la risorsa Ingress, la convenzione di denominazione dei servizi diventa coerente, mostrando un singolo ingresso, ad esempio tenanta.example.com e tenantb.example.com.

Protezione del cluster per il multitenancy

Best practice:

Controlla la comunicazione dei pod con i criteri di rete.
Esegui i carichi di lavoro con GKE Sandbox.
Configura i controlli di ammissione basati su criteri.
Utilizza Workload Identity Federation for GKE per concedere l'accesso ai servizi Google Cloud.
Limita l'accesso di rete al piano di controllo.

Controlla la comunicazione dei pod con i criteri di rete

Per controllare la comunicazione di rete tra i pod in ciascuno degli spazi dei nomi del cluster, crea criteri di rete in base ai requisiti dei tuoi tenant. Come consiglio iniziale, dovresti bloccare il traffico tra gli spazi dei nomi che ospitano le applicazioni di diversi tenant. L'amministratore del cluster può applicare un deny-all criterio di rete per negare tutto il traffico in entrata per evitare che i pod di uno spazio dei nomi inviano accidentalmente traffico a servizi o database in altri spazi dei nomi.

Ad esempio, di seguito è riportato un criterio di rete che limita l'ingresso da tutti gli altri spazi dei nomi allo spazio dei nomi tenant-a:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: tenant-a
spec:
  podSelector:
    matchLabels:

  ingress:
  - from:
    - podSelector: {}

Esegui carichi di lavoro con GKE Sandbox

I cluster che eseguono carichi di lavoro non attendibili sono più esposti alle vulnerabilità di sicurezza rispetto ad altri cluster. Con GKE Sandbox, puoi rafforzare i confini di isolamento tra i carichi di lavoro per il tuo ambiente multi-tenant. Per la gestione della sicurezza, ti consigliamo di iniziare con GKE Sandbox e poi di utilizzare i controlli di ammissione basati su criteri per colmare eventuali lacune.

GKE Sandbox si basa su gVisor, un progetto di sandboxing di container open source, e fornisce un isolamento aggiuntivo per i carichi di lavoro multi-tenant aggiungendo un livello aggiuntivo tra i container e il sistema operativo dell'host. I runtime dei container vengono spesso eseguiti come utente con privilegi sul nodo e hanno accesso alla maggior parte delle chiamate di sistema nel kernel dell'host. In un cluster multi-tenant, un tenant malintenzionato può accedere al kernel dell'host e ai dati di altri tenant. GKE Sandbox riduce queste minacce riducendo la necessità che i container interagiscano con l'host, diminuendo la superficie di attacco dell'host e limitando il movimento degli utenti malintenzionati.

GKE Sandbox fornisce due confini di isolamento tra il container e il sistema operativo dell'host:

  • Un kernel dello spazio utente, scritto in Go, che gestisce le chiamate di sistema e limita l'interazione con il kernel dell'host. Ogni pod ha il proprio kernel nello spazio utente isolato.
  • Il kernel nello spazio utente viene eseguito anche all'interno di spazi dei nomi e chiamate di sistema con filtri seccomp.

Configura i controlli di ammissione basati su criteri

Per impedire l'esecuzione nel tuo cluster di pod che violano i tuoi confini di sicurezza, utilizza un controller di ammissione. I controller di ammissione possono verificare le specifiche dei pod rispetto ai criteri che definisci e possono impedire l'esecuzione dei pod che violano questi criteri nel cluster.

GKE supporta i seguenti tipi di controllo dell'accesso:

Utilizzare Workload Identity Federation for GKE per concedere l'accesso ai servizi Google Cloud

Per concedere in modo sicuro ai carichi di lavoro l'accesso ai servizi Google Cloud, abilita la federazione delle identità per i carichi di lavoro per GKE nel cluster. La federazione delle identità per i carichi di lavoro per GKE aiuta gli amministratori a gestire gli account di servizio Kubernetes utilizzati dai carichi di lavoro Kubernetes per accedere ai servizi Google Cloud. Quando crei un cluster con la federazione delle identità per i carichi di lavoro per GKE abilitata, viene stabilito uno spazio dei nomi delle identità per il progetto in cui si trova il cluster. Lo spazio dei nomi dell'identità consente al cluster di autenticare automaticamente gli account di servizio per le applicazioni GKE mappando il nome dell'account di servizio Kubernetes a un handle dell'account di servizio Google virtuale, utilizzato per il binding IAM degli account di servizio Kubernetes del tenant.

Limita l'accesso di rete al piano di controllo

Per proteggere il control plane, limita l'accesso alle reti autorizzate. In GKE, quando attivi le reti autorizzate, puoi autorizzare fino a 50 intervalli CIDR e consentire agli indirizzi IP solo in questi intervalli di accedere al tuo piano di controllo. GKE utilizza già Transport Layer Security (TLS) e l'autenticazione per fornire accesso sicuro all'endpoint del piano di controllo dall'internet pubblico. Utilizzando le reti autorizzate, puoi limitare ulteriormente l'accesso a insiemi specifici di indirizzi IP.

Provisioning degli utenti

Best practice:

Crea progetti tenant.
Utilizza RBAC per perfezionare l'accesso del tenant.
Crea spazi dei nomi per l'isolamento tra i tenant.

Creare progetti tenant

Per ospitare le risorse non del cluster di un tenant, crea un progetto di servizio per ogni tenant. Questi progetti di servizi contengono risorse logiche specifiche per le applicazioni del tenant (ad esempio log, monitoraggio, bucket di archiviazione, account di servizio e così via). Tutti i progetti di servizio del tenant sono collegati al VPC condiviso nel progetto host del tenant.

Utilizzare RBAC per perfezionare l'accesso del tenant

Definisci un accesso più granulare alle risorse del cluster per i tuoi tenant utilizzando Kubernetes RBAC. Oltre all'accesso di sola lettura inizialmente concesso con IAM ai gruppi di tenant, definisci i ruoli e le associazioni RBAC di Kubernetes a livello di spazio dei nomi per ogni gruppo di tenant.

In precedenza abbiamo identificato due gruppi di tenant: amministratori e sviluppatori del tenant. Per questi gruppi, definiamo i seguenti ruoli e accessi RBAC:

Gruppo Ruolo
RBAC Kubernetes		 Descrizione
Amministratore del tenant amministratore dello spazio dei nomi

Concede l'accesso per elencare e guardare i deployment nel proprio spazio dei nomi.

Concede l'accesso per aggiungere e rimuovere utenti nel gruppo di tenant.
Sviluppatore tenant editor dello spazio dei nomi,
visualizzatore dello spazio dei nomi		 Concede l'accesso per creare/modificare/eliminare pod, deployment, servizi e configmap nel proprio spazio dei nomi.

Oltre a creare ruoli e associazioni RBAC che assegnano a Google Workspace o Cloud Identity gruppi di varie autorizzazioni all'interno del proprio spazio dei nomi, gli amministratori del tenant spesso richiedono la possibilità di gestire gli utenti in ciascuno di questi gruppi. In base ai requisiti della tua organizzazione, puoi gestire questa operazione delegando le autorizzazioni di Google Workspace o Cloud Identity all'amministratore del tenant per gestire la propria appartenenza al gruppo oppure l'amministratore del tenant può collaborare con un team della tua organizzazione che dispone delle autorizzazioni di Google Workspace o Cloud Identity per gestire queste modifiche.

Puoi utilizzare le autorizzazioni IAM e RBAC insieme agli spazi dei nomi per limitare le interazioni degli utenti con le risorse del cluster nella console Google Cloud. Per ulteriori informazioni, consulta Attivare l'accesso e visualizzare le risorse del cluster per spazio dei nomi.

Utilizzare Google Gruppi per associare le autorizzazioni

Per gestire in modo efficiente le autorizzazioni del tenant in un cluster, puoi associare le autorizzazioni RBAC ai tuoi gruppi Google. L'appartenenza a questi gruppi è gestita dagli amministratori di Google Workspace, pertanto gli amministratori del cluster non hanno bisogno di informazioni dettagliate sugli utenti.

Ad esempio, abbiamo un Gruppo Google denominato tenant-admins@mydomain.com e un utente denominato admin1@mydomain.com è membro di quel gruppo. La seguente associazione fornisce all'utente l'accesso amministrativo allo spazio dei nomi tenant-a:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant-a
  name: tenant-admin-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tenant-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: "tenant-admins@mydomain.com"

Creare spazi dei nomi

Per fornire un isolamento logico tra i tenant che si trovano sullo stesso cluster, implementa gli spazi dei nomi. Nell'ambito del processo RBAC di Kubernetes, l'amministratore del cluster crea spazi dei nomi per ogni gruppo di tenant. L'amministratore del tenant gestisce gli utenti (sviluppatori del tenant) all'interno del rispettivo spazio dei nomi del tenant. Gli sviluppatori del tenant possono quindi utilizzare risorse specifiche per i cluster e i tenant per eseguire il deployment delle loro applicazioni.

Evitare di raggiungere i limiti dello spazio dei nomi

Il numero massimo teorico di spazi dei nomi in un cluster è 10.000, anche se in pratica esistono molti fattori che potrebbero impedirti di raggiungere questo limite. Ad esempio, potresti raggiungere il numero massimo di pod (150.000) e di nodi (5000) a livello di cluster prima di raggiungere il numero massimo di spazi dei nomi. Altri fattori,come il numero di secret,possono ridurre ulteriormente i limiti effettivi. Di conseguenza, una buona regola empirica iniziale è tentare di avvicinarsi solo al limite teorico di un vincolo alla volta e rimanere a circa un ordine di grandezza dagli altri limiti, a meno che la sperimentazione non dimostri che i casi d'uso funzionano bene. Se hai bisogno di più risorse di quante può supportare un singolo cluster, devi creare più cluster. Per informazioni sulla scalabilità di Kubernetes, consulta l'articolo Soglie di scalabilità di Kubernetes.

Standardizzare la denominazione degli spazi dei nomi

Per semplificare i deployment in più ambienti ospitati in diversi cluster, standardizza la convenzione di denominazione dello spazio dei nomi che utilizzi. Ad esempio, evita di associare il nome dell'ambiente (sviluppo, gestione temporanea e produzione) al nome dello spazio dei nomi e utilizza lo stesso nome in tutti gli ambienti. Se utilizzi lo stesso nome, eviti di dover modificare i file di configurazione in tutti gli ambienti.

Creare account di servizio per i carichi di lavoro del tenant

Crea un account di servizio Google specifico per ogni carico di lavoro distinto in uno spazio dei nomi del tenant. Ciò fornisce una forma di sicurezza, garantendo che gli utenti possano gestire gli account di servizio per i carichi di lavoro di loro proprietà/implementati nei rispettivi spazi dei nomi. L'account di servizio Kubernetes per ogni spazio dei nomi viene mappato a un account di servizio Google utilizzando la federazione delle identità per i carichi di lavoro per GKE.

Applica le quote delle risorse

Per garantire che tutti i tenant che condividono un cluster abbiano un accesso equo alle risorse del cluster, applica le quote delle risorse. Crea una quota di risorse per ogni spazio dei nomi in base al numero di pod di cui è stato eseguito il deployment da ciascun tenant e alla quantità di memoria e CPU richiesta da ciascun pod.

L'esempio seguente definisce una quota di risorse in cui i pod nello spazio dei nomi tenant-a possono richiedere fino a 16 CPU e 64 GB di memoria, mentre il numero massimo di CPU è 32 e la memoria massima è 72 GB.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Monitoraggio, logging e utilizzo

Best practice:

Monitora le metriche di utilizzo.
Fornisci log specifici per il tenant.

Monitorare le metriche di utilizzo

Per ottenere una suddivisione dei costi per singoli spazi dei nomi ed etichette in un cluster, puoi attivare l'allocazione dei costi di GKE. L'allocazione dei costi di GKE tiene traccia delle informazioni sulle richieste di risorse e sull'utilizzo delle risorse da parte dei carichi di lavoro di un cluster, che puoi suddividere ulteriormente in base a spazi dei nomi ed etichette. Con l'allocazione dei costi di GKE, puoi approssimare la suddivisione dei costi per i reparti/i team che condividono un cluster, comprendere i pattern di utilizzo delle singole applicazioni (o anche dei componenti di una singola applicazione), aiutare gli amministratori del cluster a gestire gli picchi di utilizzo e fornire una migliore pianificazione della capacità e un migliore budgeting.

Quando attivi l'allocazione dei costi di GKE, il nome e lo spazio dei nomi del cluster dei tuoi carichi di lavoro GKE vengono visualizzati nel campo delle etichette dell'esportazione della fatturazione in BigQuery.

Fornisci log specifici per il tenant

Per fornire ai tenant dati di log specifici per i workload dei loro progetti, utilizza il router del log di Cloud Logging. Per creare log specifici per il tenant, l'amministratore del cluster crea un sink per esportare le voci di log in un bucket di log creato nel progetto Google Cloud del tenant.

Per informazioni dettagliate su come configurare questi tipi di log, consulta Logging multi-tenant su GKE.

Riepilogo elenco di controllo

La tabella seguente riassume le attività consigliate per la creazione di cluster multi-tenant in un'organizzazione aziendale:

Area Tasks
Configurazione dell'organizzazione
Gestione di identità e accessi
Networking
Alta disponibilità e affidabilità
Sicurezza
Logging e monitoraggio

Passaggi successivi