L'architettura multi-tenancy in Google Kubernetes Engine (GKE) fa riferimento a uno o più cluster condivisi tra i tenant. In Kubernetes, un tenant può essere definito come:
- 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.
La multitenancy dei cluster viene spesso implementata per ridurre i costi o per applicare in modo coerente 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 imprevisti, applicazioni di criteri non corrette o interazioni distruttive tra i carichi di lavoro dei diversi tenant.
Questa guida fornisce le best practice per configurare in modo sicuro ed efficiente più cluster multi-tenant per un'organizzazione aziendale.
Presupposti e requisiti
Le best practice di 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 che ha molti tenant (due o più team di applicazioni/servizi) che utilizzano Kubernetes e vorrebbe 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, inclusi membri dei 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 tenant può utilizzare; ogni tenant può richiederne di più.
- Ogni team 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, se non tramite decisioni di progettazione esplicite come chiamate API, origini dati condivise e così via.
Questa configurazione fungerà da modello da cui possiamo dimostrare le best practice multi-tenant. Anche se questa configurazione potrebbe non descrivere perfettamente tutte le organizzazioni aziendali, può essere facilmente estesa per includere scenari simili.
Configurazione di cartelle, progetti e cluster
Best practice:
Stabilisci una gerarchia di cartelle e progetti.Assegnare i ruoli utilizzando IAM.
Centralizza il controllo della rete con i VPC condivisi.
Crea un progetto di amministrazione del cluster per cluster.
Rendi privati i cluster.
Assicurati che il piano di controllo per il cluster sia a livello di regione.
Assicurati che i nodi nel cluster includano almeno tre zone.
Scala automaticamente nodi e risorse del cluster.
Pianifica periodi di manutenzione 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 al fine di gestire la complessità che non esiste nei deployment Kubernetes più semplici con applicazione singola e a team singolo. Ciò include sia la configurazione dei progetti per isolare i problemi amministrativi, nonché la mappatura della struttura organizzativa a 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 diversi team di impostare criteri da applicare a cascata su più progetti, mentre i progetti possono essere utilizzati per separare gli ambienti (ad esempio, produzione o gestione temporanea) e i team l'uno dall'altro. 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 parte separata dello stack e richiede un proprio livello di esperienza, risoluzione di problemi e accesso.
Una cartella principale può contenere fino a 300 cartelle ed è possibile nidificare le cartelle fino a 10 livelli di profondità. Se hai oltre 300 tenant, puoi disporli in gerarchie nidificate per rimanere entro il limite. Per ulteriori informazioni sulle cartelle, consulta Creazione e gestione di cartelle.
Assegnare ruoli utilizzando IAM
Puoi controllare l'accesso alle risorse Google Cloud tramite i criteri IAM. Per prima cosa, identifica i gruppi necessari per la tua organizzazione e il relativo ambito delle operazioni, quindi assegna al gruppo il ruolo IAM appropriato.
Utilizza Google Gruppi per assegnare e gestire in modo efficiente i ruoli IAM per gli utenti.Centralizza il controllo della rete
Per mantenere il controllo centralizzato sulle risorse di rete, ad esempio 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 consente di implementare il principio del privilegio minimo. Ad esempio, un team di rete centralizzato può gestire la rete senza avere 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 un VPC condiviso, devi configurare le subnet e i relativi intervalli IP secondari nel VPC. Per determinare le dimensioni della subnet, devi conoscere il numero previsto di tenant, il numero di pod e servizi che devono essere eseguiti e le dimensioni massime e medie dei pod. Il calcolo della capacità totale necessaria del cluster consente di comprendere la dimensione dell'istanza desiderata e fornisce il numero totale di nodi. Grazie al numero totale di nodi, è possibile calcolare lo spazio IP totale utilizzato e in questo modo fornire la dimensione della subnet desiderata.
Di seguito sono riportati alcuni fattori da considerare anche durante la configurazione della rete:
- Il numero massimo di progetti di servizio che possono essere associati a un progetto host è 1000, mentre il numero massimo di progetti host del 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 del cluster e dell'intervallo di indirizzi dei pod del cluster.
- Per maggiore 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 subnet 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/delle subnet IP ed evita le sovrapposizioni negli intervalli, il che impedisce le opzioni di connettività lungo il percorso. 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 in esecuzione al di fuori dei cluster condivisi (come le VM dedicate di Compute Engine) possono utilizzare il proprio VPC, che è in peering al VPC condiviso eseguito dal team di networking. Fornisce una sicurezza aggiuntiva, a scapito di una maggiore complessità e di numerose altre limitazioni. Per ulteriori informazioni sul peering, consulta Utilizzo del peering di rete VPC. Nell'esempio riportato di seguito, 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 disponibilità elevata e affidabilità implementando i seguenti suggerimenti:
- Crea un progetto di amministrazione del cluster per cluster per ridurre il rischio che le configurazioni a livello di progetto (ad esempio associazioni IAM) influiscano negativamente su molti cluster e per garantire una separazione per quota e fatturazione. I progetti di amministrazione del cluster sono separati dai progetti tenant, che i singoli tenant utilizzano per gestire, ad esempio, le risorse Google Cloud.
- Rendi il cluster di produzione privato per disabilitare l'accesso ai nodi e gestire l'accesso al piano di controllo. Ti consigliamo inoltre di utilizzare cluster privati per gli ambienti di sviluppo e gestione temporanea.
- Assicurati che il piano di controllo per il cluster sia regionale per fornire disponibilità elevata per l'architettura multi-tenancy; eventuali interruzioni del piano di controllo avranno un impatto sui tenant. Tieni presente che l'esecuzione di cluster a livello di regione comporta implicazioni in termini di costi. I cluster Autopilot sono preconfigurati come cluster a livello di regione.
- Assicurati che i nodi nel tuo cluster includano 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 della rete.
Scala automaticamente i nodi e le risorse del cluster
Per soddisfare le esigenze dei tuoi 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 vari tenant nei rispettivi spazi dei nomi o per rispondere a interruzioni del servizio 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 dei carichi di lavoro. Specificando il numero massimo di nodi, puoi assicurarti che ci sia spazio sufficiente per tutti i pod nel cluster, a prescindere dallo spazio dei nomi in cui vengono eseguiti. La scalabilità automatica dei cluster riscala i pool di nodi in base al limite minimo e massimo, contribuendo a ridurre i costi operativi quando il carico del sistema diminuisce ed evitare che i pod passino in stato di attesa quando non sono disponibili risorse cluster sufficienti. Per determinare il numero massimo di nodi, identifica la quantità massima di CPU e memoria richiesta da ciascun tenant e somma le somme 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, prendendo in considerazione lo spazio di subnet IP messo a disposizione del 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. È possibile utilizzare la scalabilità automatica pod verticale (VPA) per scalare automaticamente la richiesta di risorse di 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 VPA, quando necessario.
Determina la dimensione del cluster
Quando determini la dimensione del tuo cluster, ecco alcuni fattori importanti da considerare:
- Il dimensionamento del cluster dipende dal tipo di carichi di lavoro che prevedi di eseguire. Se i carichi di lavoro hanno una maggiore densità, l'efficienza in termini di costi è più elevata, ma c'è anche una maggiore possibilità di conflitti delle risorse.
- La dimensione minima di un cluster è definita dal numero di zone distribuite: un nodo per un cluster di zona e tre nodi per un cluster a livello di regione.
- Per progetto è previsto un massimo di 50 cluster per zona, più 50 cluster a livello di regione per regione.
- 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 le versioni GKE precedenti a 1.23.50,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 Per saperne di più, consulta la pagina Quote e limiti.
Pianificare periodi di manutenzione
Per ridurre i tempi di inattività durante gli upgrade e la manutenzione di 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 facilitare la gestione dei servizi pubblicati dei tenant e la gestione del traffico in entrata verso questi servizi, crea un bilanciatore del carico HTTP(s) per consentire un singolo 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 come il traffico raggiunge i tuoi servizi e come il traffico 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,
come tenanta.example.com e tenantb.example.com.
Protezione del cluster per la multitenancy
Best practice:
Controllare la comunicazione dei pod con i criteri di rete.Esegui carichi di lavoro con GKE Sandbox.
Configura controlli di ammissione basati su criteri.
Utilizzare la federazione delle identità per i carichi di lavoro 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 le comunicazioni di rete tra i pod in ciascuno degli spazi 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 applicazioni di diversi tenant. L'amministratore del cluster può applicare un criterio di rete deny-all per negare tutto il traffico in entrata ed 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 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 limiti di isolamento tra i carichi di lavoro per il tuo ambiente multi-tenant. Per la gestione della sicurezza, consigliamo di iniziare con GKE Sandbox e poi usare 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ò ottenere l'accesso 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 di 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 dell'host. Ogni pod ha il proprio kernel isolato per lo spazio utente.
- Il kernel dello spazio utente viene eseguito anche all'interno degli spazi dei nomi e delle chiamate di sistema di filtro seccomp.
Configura controlli di ammissione basati su criteri
Per impedire che i pod che violano i limiti di sicurezza vengano eseguiti nel cluster, utilizza un controller di ammissione. I controller di ammissione possono controllare le specifiche dei pod in base ai criteri che hai definito e possono impedire l'esecuzione nel cluster dei pod che violano questi criteri.
GKE supporta i seguenti tipi di controllo di ammissione:
- Policy Controller: Dichiara criteri predefiniti o personalizzati e applicali in cluster su larga scala utilizzando i parchi risorse. Policy Controller è un'implementazione dell'agente di criteri aperto Gatekeeper open source ed è una funzionalità di GKE Enterprise.
- Controller di ammissione PodSecurity: applica criteri predefiniti che corrispondono agli standard di sicurezza dei pod nei singoli cluster o in spazi dei nomi specifici.
Utilizza la federazione delle identità per i carichi di lavoro 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 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 che i carichi di lavoro Kubernetes utilizzano per accedere ai servizi Google Cloud. Quando crei un cluster con la federazione delle identità per i carichi di lavoro abilitata 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 a un handle dell'account di servizio Google virtuale, utilizzato per l'associazione IAM degli account di servizio Kubernetes 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 reti autorizzate, puoi autorizzare fino a 50 intervalli CIDR e consentire agli indirizzi IP inclusi in questi intervalli di accedere al piano di controllo. GKE utilizza già Transport Layer Security (TLS) e l'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 degli tenant
Best practice:
Crea progetti tenant.Utilizza RBAC per perfezionare l'accesso del tenant.
Crea spazi dei nomi per l'isolamento tra i 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 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 ruoli e associazioni RBAC Kubernetes a livello di spazio dei nomi per ogni gruppo di tenant.
In precedenza abbiamo identificato due gruppi di tenant: amministratori e sviluppatori di tenant. Per questi gruppi, definiamo i seguenti ruoli e accesso RBAC:
| Gruppo | Ruolo RBAC Kubernetes |
Descrizione |
|---|---|---|
| Amministratore tenant | amministratore spazio dei nomi | Concede l'accesso per elencare e osservare i deployment nel relativo spazio dei nomi. Concede l'accesso per aggiungere e rimuovere utenti nel gruppo di tenant. |
| Sviluppatore inquilini | editor dello spazio dei nomi, visualizzatore dello spazio dei nomi |
Concede l'accesso per creare/modificare/eliminare pod, deployment, servizi e ConfigMap nel relativo 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 richiedono spesso la possibilità di gestire gli utenti in ciascuno di questi gruppi. A seconda dei requisiti della tua organizzazione, puoi delegare all'amministratore tenant le autorizzazioni di Google Workspace o Cloud Identity per gestire la propria appartenenza al gruppo oppure l'amministratore tenant coinvolgendo un team dell'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 maggiori informazioni, consulta Abilitare l'accesso e visualizzare le risorse del cluster per spazio dei nomi.Utilizza Google Gruppi per associare le autorizzazioni
Per gestire in modo efficiente le autorizzazioni dei tenant in un cluster, puoi associare le autorizzazioni RBAC ai tuoi gruppi Google. L'appartenenza a questi gruppi è gestita dagli amministratori di Google Workspace, quindi gli amministratori del cluster non hanno bisogno di informazioni dettagliate sugli utenti.
Ad esempio, supponiamo che abbiamo un gruppo Google denominato tenant-admins@mydomain.com e un
utente di nome admin1@mydomain.com è membro di quel gruppo, la seguente
associazione fornisce all'utente 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 usare risorse specifiche per cluster e tenant per 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 esistono 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 empirica iniziale è cercare di avvicinarsi solo al limite teorico di un vincolo alla volta e di allontanarsi circa di un ordine di grandezza dagli altri limiti, a meno che la sperimentazione non mostri che i casi d'uso funzionino bene. Se hai bisogno di più risorse di quelle che possono essere supportate da un singolo cluster, devi creare altri cluster. Per informazioni sulla scalabilità di Kubernetes, consulta l'articolo Soglie di scalabilità di Kubernetes.
Standardizza la denominazione degli spazi 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, ma utilizza lo stesso nome in tutti gli ambienti. Se utilizzi lo stesso nome, eviterai di dover modificare i file di configurazione nei vari ambienti.
Crea account di servizio per i carichi di lavoro tenant
Crea un account di servizio Google specifico per il tenant per ogni carico di lavoro distinto nello spazio dei nomi di un tenant. Ciò fornisce una forma di sicurezza, garantendo che i tenant possano gestire gli account di servizio per i carichi di lavoro di cui sono proprietari/di cui viene eseguito 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 for 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 delle risorse per ogni spazio dei nomi in base al numero di pod di cui ogni tenant e alla quantità di memoria e CPU richieste per ogni 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. La CPU massima è di 32 GB 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
Monitorare le metriche di utilizzo
Per ottenere ripartizioni 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 monitora le informazioni sulle richieste 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 approssimare la suddivisione dei costi per i reparti/team che condividono un cluster, comprendere i pattern di utilizzo delle singole applicazioni (o anche dei componenti di una singola applicazione), aiutare gli amministratori dei cluster a valutare i picchi di utilizzo e fornire una migliore pianificazione della capacità e definizione del budget.
Quando abiliti l'allocazione dei costi di GKE, il nome del cluster e lo spazio dei nomi dei 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 tabella seguente riassume le attività consigliate per la creazione di cluster multi-tenant in un'organizzazione aziendale:
Passaggi successivi
- Per ulteriori informazioni sulla sicurezza, vedi Rafforzamento della sicurezza del cluster.
- Per saperne di più sulle reti VPC, consulta Best practice e architetture di riferimento per la progettazione VPC.
- Per altre best practice aziendali, vedi Framework dell'architettura Google Cloud.