Best practice per architettura multi-tenancy aziendale

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

  • Un team responsabile dello sviluppo e della gestione 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.

La multi-tenancy dei cluster viene spesso implementata per ridurre i costi o per applicare in modo coerente i criteri di amministrazione tra i tenant. Tuttavia, la configurazione errata di un cluster GKE o delle relative risorse GKE associate può comportare risparmi sui costi non necessari, errori di applicazione dei criteri o interazioni distruttive tra carichi di lavoro di tenant diversi.

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 in questa guida si basano su un caso d'uso multi-tenant per un ambiente aziendale, che prevede le ipotesi e i requisiti seguenti:

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

Questa configurazione fungerà da modello a partire dal quale possiamo dimostrare le best practice per più tenant. Questa configurazione potrebbe non descrivere perfettamente tutte le organizzazioni aziendali, ma può essere facilmente estesa per coprire scenari simili.

Configurazione di cartelle, progetti e cluster

Best practice:

Stabilisci una gerarchia di cartelle e progetti.
Assegna i ruoli utilizzando IAM.
Centralizza il controllo di rete con i VPC condivisi.
Crea un progetto amministratore di cluster per cluster.
Rendi i cluster privati.
Assicurati che il piano di controllo per il cluster sia a livello di regione.
Assicurati che i nodi nel tuo cluster comprendano almeno tre zone.
Scala automaticamente i nodi e le risorse del cluster.
Pianifica i periodi di manutenzione per le ore al di fuori delle ore di punta.
Configura un bilanciatore del carico delle applicazioni esterno con Ingress.

Per le organizzazioni aziendali che eseguono il deployment di cluster multi-tenant in GKE, è necessaria un'ulteriore configurazione in altri sistemi Google Cloud per gestire la complessità che non esiste nei più semplici deployment Kubernetes con un'applicazione singola e un team. Ciò include la configurazione dei progetti per isolare i problemi amministrativi, nonché la mappatura della struttura organizzativa su identità e account cloud e la gestione di risorse Google Cloud aggiuntive, come database, logging e monitoraggio, archiviazione e networking.

Stabilisci una gerarchia di cartelle e progetti

Per capire in che modo la tua organizzazione gestisce le risorse Google Cloud e per applicare una separazione dei problemi, utilizza cartelle e progetti. Le cartelle consentono a team diversi di impostare criteri che si estendono su più progetti, mentre i progetti possono essere utilizzati per separare gli ambienti (ad esempio produzione e gestione temporanea) e i team gli uni dagli altri. Ad esempio, la maggior parte delle organizzazioni ha un team per gestire l'infrastruttura di rete e un team diverso per gestire i cluster. Ogni tecnologia è considerata una componente distinta dello stack e 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 non superare il limite. Per ulteriori informazioni sulle cartelle, consulta Creazione e gestione delle cartelle.

Assegna ruoli utilizzando IAM

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

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

Centralizza 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 posseduta da un progetto host centralizzato e può essere utilizzata da uno o più progetti di servizio.

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

Quando imposti un VPC condiviso, devi configurare le subnet e i relativi intervalli IP secondari nel VPC. Per determinare la dimensione della subnet, devi conoscere il numero previsto di tenant, il numero di pod e servizi che si prevede verranno eseguiti e la dimensione massima e media del pod. Il calcolo della capacità totale necessaria del cluster ti consentirà di comprendere la dimensione dell'istanza desiderata e fornirà il numero totale dei nodi. Con il numero totale di nodi, è possibile calcolare lo spazio IP totale utilizzato e questo può fornire le dimensioni desiderate per la subnet.

Di seguito sono riportati alcuni fattori che dovresti prendere in considerazione durante la configurazione della rete:

  • Il numero massimo di progetti di servizio che possono essere collegati 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 dalla dimensione degli intervalli secondari del cluster.
  • Il numero massimo di nodi nel cluster è limitato dalla dimensione dell'intervallo di indirizzi IP principali della subnet del cluster e dall'intervallo di indirizzi dei 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 un numero inferiore di indirizzi IP.

Per calcolare le subnet per i tuoi cluster, puoi utilizzare lo strumento open source Calcolatrice IPAM di GKE. La gestione degli indirizzi IP (IPAM) consente un uso efficiente dello spazio IP/delle subnet ed evita sovrapposizioni negli intervalli, impedendo così le opzioni di connettività lungo la strada. Per informazioni sugli intervalli di rete in un cluster VPC, consulta Creazione di un cluster nativo di VPC.

I tenant che richiedono un ulteriore isolamento per le risorse eseguite all'esterno dei cluster condivisi (ad esempio le VM di Compute Engine dedicate) possono utilizzare il proprio VPC, connesso in peering al VPC condiviso eseguito dal team di rete. Ciò fornisce maggiore sicurezza, a scapito di una maggiore complessità e di numerose altre limitazioni. Per maggiori informazioni sul peering, consulta Utilizzo del peering di rete VPC. Nell'esempio in basso, tutti i tenant hanno scelto di condividere un singolo VPC tenant (per ambiente).

Creazione di cluster affidabili e ad alta disponibilità

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

  • Crea un progetto di amministrazione del cluster per cluster in modo da ridurre il rischio che le configurazioni a livello di progetto (ad esempio le associazioni IAM) influiscano negativamente su molti cluster e per facilitare la separazione di quota e fatturazione. I progetti di amministrazione del cluster sono separati dai progetti tenant, che vengono utilizzati dai singoli tenant per gestire, ad esempio, le risorse Google Cloud.
  • Imposta il cluster di produzione come privato per disabilitare l'accesso ai nodi e gestire l'accesso al piano di controllo. Consigliamo inoltre di utilizzare cluster privati per ambienti di sviluppo e gestione temporanea.
  • Assicurati che il piano di controllo per il cluster sia a livello di regione per fornire alta disponibilità per la multitenancy. Eventuali interruzioni del piano di controllo avranno un impatto sui tenant. Tieni presente che l'esecuzione di cluster a livello di regione comporta implicazioni sui costi. I cluster Autopilot sono preconfigurati come cluster a livello di regione.
  • Assicurati che i nodi nel tuo cluster comprendano almeno tre zone per ottenere l'affidabilità a livello di zona. Per informazioni sul costo del traffico in uscita tra zone nella stessa regione, consulta la documentazione sui prezzi di rete.
Un cluster privato a livello di regione con un piano di controllo a livello di regione in esecuzione in tre zone
Figura 3: un cluster privato a livello di regione con un piano di controllo a livello di regione in esecuzione in tre zone.

Scala automaticamente i nodi e le risorse del cluster

Per soddisfare le esigenze dei tenant, scala automaticamente i nodi nel tuo cluster abilitando la scalabilità automatica.

La scalabilità automatica consente ai sistemi di apparire reattivi e integri quando viene eseguito il deployment di carichi di lavoro intensivi da parte di vari tenant nei loro spazi dei nomi o per rispondere a interruzioni a livello di zona.

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

Quando abiliti la scalabilità automatica, specifichi il numero minimo e massimo di nodi in un cluster in base alle dimensioni previste per i carichi di lavoro. Specificando il numero massimo di nodi, puoi assicurarti che ci sia spazio sufficiente per tutti i pod nel cluster, indipendentemente dallo spazio dei nomi in cui vengono eseguiti. La scalabilità automatica dei 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 evita che i pod passino in stato di attesa quando le risorse cluster disponibili non sono sufficienti. Per determinare il numero massimo di nodi, identifica la quantità massima di CPU e memoria richiesta da ogni tenant e aggiungi queste quantità per ottenere la capacità totale che il cluster dovrebbe essere in grado di gestire se tutti i tenant avessero raggiunto il limite. Utilizzando il numero massimo di nodi, puoi scegliere le dimensioni e il numero di istanze, prendendo in considerazione lo spazio della subnet IP reso disponibile per il cluster.

Usa la scalabilità automatica dei pod per scalare automaticamente i pod in base alle esigenze delle risorse. Horizontal Pod Autoscaler (HPA) scala il numero di repliche dei pod in base all'utilizzo di CPU/memoria o a metriche personalizzate. Scalabilità automatica pod verticale (VPA) può essere utilizzata per scalare automaticamente le richieste di risorse dei pod. Non deve essere utilizzato con HPA a meno che non siano disponibili metriche personalizzate, in quanto i due gestori della scalabilità automatica possono competere tra loro. Per questo motivo, inizia con HPA e solo successivamente con VPA quando necessario.

Determina le dimensioni del tuo cluster.

Nel determinare le dimensioni del tuo cluster, ci sono alcuni fattori importanti da considerare:

  • Le dimensioni del cluster dipendono dal tipo di carichi di lavoro che prevedi di eseguire. Se i carichi di lavoro hanno una densità maggiore, l'efficienza in termini di costi è maggiore, ma c'è anche una maggiore probabilità di conflitti delle risorse.
  • La dimensione minima di un cluster è definita dal numero di zone che occupa: un nodo per un cluster di zona e tre nodi per un cluster a livello di regione.
  • Per progetto sono previsti un massimo di 50 cluster per zona, più 50 cluster a livello di regione per area geografica.
  • Per cluster è previsto un massimo di 15.000 nodi per cluster (5000 per le versioni GKE fino alla 1.17), 1000 nodi per pool di nodi, 1000 nodi per cluster (se utilizzi il controller GKE Ingress), 256 pod per nodo (110 per versioni GKE precedenti a 1.23.5-gke.0, container per cluster e 0 per cluster gke.130), Per ulteriori informazioni, consulta la pagina Quote e limiti.

Pianifica periodi di manutenzione

Per ridurre i tempi di inattività durante gli upgrade e la manutenzione dei cluster/nodi, pianifica periodi di manutenzione in modo che si verifichino al di fuori delle 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 al di fuori delle 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 agevolare la gestione dei servizi pubblicati dei tenant e la gestione del traffico in entrata verso questi servizi, crea un bilanciatore del carico HTTP(S) in modo da consentire un unico traffico in entrata per cluster, in cui i servizi di ogni tenant sono registrati con la risorsa in entrata 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 servizi e in che modo viene instradato all'applicazione del tenant. Registrando i servizi con la risorsa Ingress, la convenzione di denominazione dei servizi diventa coerente, mostrando un singolo traffico in entrata, ad esempio tenanta.example.com e tenantb.example.com.

Protezione del cluster per la multitenancy

Best practice:

Controlla la comunicazione dei pod con i criteri di rete.
Esegui i carichi di lavoro con GKE Sandbox.
Configurare controlli di ammissione basati su criteri.
Utilizza la federazione di Workload Identity per 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 spazio dei nomi del tuo cluster, crea criteri di rete in base ai requisiti dei tenant. Come suggerimento iniziale, dovresti bloccare il traffico tra spazi dei nomi che ospitano le applicazioni di tenant diversi. L'amministratore del cluster può applicare un criterio di rete deny-all per negare tutto il traffico in entrata in modo da evitare che i pod di uno spazio dei nomi inviino accidentalmente traffico a servizi o database in altri spazi dei nomi.

Ad esempio, ecco un criterio di rete che limita il traffico in entrata 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 i carichi di lavoro con GKE Sandbox

I cluster che eseguono carichi di lavoro non attendibili sono più esposti a vulnerabilità di sicurezza rispetto ad altri cluster. Con GKE Sandbox, puoi rafforzare i limiti 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, quindi utilizzare 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 ulteriore isolamento per i carichi di lavoro multi-tenant aggiungendo un ulteriore livello tra i container e il sistema operativo host. I runtime dei container spesso vengono eseguiti come utenti con privilegi sul nodo e hanno accesso alla maggior parte delle chiamate di sistema nel kernel host. In un cluster multi-tenant, un tenant dannoso può accedere al kernel dell'host e ai dati di un altro tenant. GKE Sandbox attenua queste minacce riducendo la necessità che i container interagiscano con l'host, riducendo la superficie di attacco dell'host e limitando il movimento degli utenti malintenzionati.

GKE Sandbox fornisce due limiti di isolamento tra il container e il sistema operativo host:

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

Configura controlli di ammissione basati su criteri

Per impedire l'esecuzione nel cluster dei pod che violano i limiti di sicurezza, utilizza un controller di ammissione. I controller di ammissione possono controllare le specifiche dei pod in base ai criteri da te definiti e possono impedire l'esecuzione nel tuo cluster dei pod che violano questi criteri.

GKE supporta i seguenti tipi di controlli di ammissione:

  • Policy Controller: Dichiara criteri predefiniti o personalizzati e applicali nei cluster su larga scala utilizzando i parchi risorse. Policy Controller è un'implementazione dell'agente open source Gatekeeper open source ed è una funzionalità di GKE Enterprise.

Utilizza la federazione di Workload Identity per 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 Workload Identity Federation per GKE nel cluster. La federazione di Workload Identity per GKE aiuta gli amministratori a gestire gli account di servizio Kubernetes che i carichi di lavoro Kubernetes usano per accedere ai servizi Google Cloud. Quando crei un cluster in cui è abilitata la federazione di Workload Identity per GKE, viene stabilito uno spazio dei nomi delle identità per il progetto in cui è ospitato il cluster. Lo spazio dei nomi delle identità consente al cluster di autenticare automaticamente gli account di servizio per le applicazioni GKE mappando il nome dell'account di servizio Kubernetes all'handle dell'account di servizio Google virtuale, che viene utilizzato per l'associazione IAM degli account di servizio Kubernetes del tenant.

Limita l'accesso di rete al piano di controllo

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

Provisioning dei tenant

Best practice:

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

Crea progetti tenant

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

Usa RBAC per perfezionare l'accesso ai tenant

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

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

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

Concede l'accesso per elencare e controllare i deployment nel loro spazio dei nomi.

Concede l'accesso per aggiungere e rimuovere utenti nel gruppo di tenant.
Sviluppatore inquilino editor dello spazio dei nomi,
visualizzatore 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 ai gruppi Google Workspace o Cloud Identity varie autorizzazioni all'interno del loro spazio dei nomi, gli amministratori tenant spesso richiedono la possibilità di gestire gli utenti in ciascuno di questi gruppi. In base ai requisiti della tua organizzazione, puoi delegare le autorizzazioni di Google Workspace o Cloud Identity all'amministratore di tenant in modo che gestisca la propria appartenenza ai gruppi oppure in modo che l'amministratore di tenant entri in contatto con un team della tua organizzazione che disponga 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 sulla console Google Cloud. Per maggiori informazioni, consulta Abilitare 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 tenant in un cluster, puoi associare le autorizzazioni RBAC a Google Gruppi. L'appartenenza a questi gruppi è gestita dagli amministratori di Google Workspace, pertanto gli amministratori dei cluster non hanno bisogno di informazioni dettagliate sugli utenti.

Ad esempio, abbiamo un gruppo Google denominato tenant-admins@mydomain.com e un utente di nome admin1@mydomain.com fa parte di questo 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"

Crea 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 Kubernetes RBAC, l'amministratore del cluster crea spazi dei nomi per ogni gruppo di tenant. L'amministratore tenant gestisce gli utenti (sviluppatori tenant) all'interno del rispettivo spazio dei nomi tenant. Gli sviluppatori tenant possono quindi utilizzare risorse specifiche per cluster e tenant per eseguire il deployment delle loro applicazioni.

Evita 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 ci sono molti fattori che potrebbero impedirti di raggiungere questo limite. Ad esempio, potresti raggiungere il numero massimo di pod (150.000) e 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 iniziale è cercare di avvicinarsi solo al limite teorico di un vincolo alla volta e di allontanarsi 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 quelle che possono essere supportate da un singolo cluster, devi creare più cluster. Per informazioni sulla scalabilità di Kubernetes, consulta l'articolo Soglie della scalabilità di Kubernetes.

Standardizza la denominazione dello spazio dei nomi

Per semplificare i deployment in più ambienti ospitati in cluster diversi, standardizza la convenzione di denominazione degli spazi 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 invece lo stesso nome in tutti gli ambienti. Se utilizzi lo stesso nome, eviterai di dover modificare i file di configurazione tra gli ambienti.

Crea account di servizio per i carichi di lavoro del tenant

Creare un account di servizio Google specifico per il tenant per ogni carico di lavoro distinto in uno spazio dei nomi tenant. Questo fornisce una forma di sicurezza, garantendo che i tenant possano gestire gli account di servizio per i carichi di lavoro di cui sono proprietari o di cui eseguono il deployment nei rispettivi spazi dei nomi. L'account di servizio Kubernetes per ogni spazio dei nomi è mappato a un account di servizio Google utilizzando Workload Identity Federation 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. Creare una quota di risorse per ogni spazio dei nomi in base al numero di pod di cui è stato eseguito il deployment da ogni tenant e alla quantità di memoria e CPU necessarie per ogni pod.

L'esempio seguente definisce una quota delle risorse in cui i pod nello spazio dei nomi tenant-a possono richiedere fino a 16 CPU e 64 GB di memoria, mentre la CPU massima è di 32 CPU e la memoria massima è di 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:

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

Monitorare le metriche di utilizzo

Per ottenere la suddivisione dei costi per singoli spazi dei nomi ed etichette in un cluster, puoi abilitare 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 per spazi dei nomi ed etichette. Con l'allocazione dei costi di GKE, puoi avvicinare la suddivisione dei costi per i reparti/team che condividono un cluster, comprendere i pattern di utilizzo di singole applicazioni (o anche componenti di una singola applicazione), aiutare gli amministratori dei cluster a ridurre i picchi di utilizzo e migliorare la pianificazione della capacità e il budget.

Quando abiliti l'allocazione dei costi di GKE, il nome del cluster e lo spazio dei nomi 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 carichi di lavoro del progetto, utilizza il router dei 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 maggiori dettagli su come configurare questi tipi di log, consulta Logging multi-tenant su GKE.

Riepilogo elenco di controllo

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

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

Passaggi successivi