L'architettura multi-tenancy in Google Kubernetes Engine (GKE) si riferisce a uno o più condivisi tra i tenant. In Kubernetes, un tenant può essere definiti 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.
Multitenancy dei cluster vengono spesso implementate per ridurre i costi o per applicare in modo coerente l'amministrazione tra i vari tenant. Tuttavia, una configurazione errata Cluster GKE o i relativi cluster GKE associati di risorse possono comportare risparmi inaspettati sui costi, un'applicazione errata dei criteri o le interazioni distruttive tra i vari tenant carichi di lavoro con scale out impegnativi.
Questa guida fornisce le best practice per configurare in modo sicuro ed efficiente di 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 una dell'ambiente aziendale, che prevede i seguenti presupposti e requisiti:
- L'organizzazione è una singola azienda con molti tenant (due o più team dedicati alle applicazioni/servizi) che utilizzano Kubernetes e che vorrebbero condividere di computing e amministrazione.
- Ogni tenant è un singolo team che sviluppa un singolo carico di lavoro.
- Oltre ai team dedicati alle applicazioni/servizi, esistono altri team che utilizzano e gestiscono i cluster, inclusi i membri del team della piattaforma, i cluster amministratori, revisori e così via
- Il team della piattaforma è proprietario dei cluster e definisce la quantità di risorse che il 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 deve essere in grado di influire su altri tenant nel cluster, tranne che tramite decisioni di progettazione esplicite come chiamate API, dati condivisi fonti ecc.
Questa configurazione fungerà da modello da cui potremo dimostrare le migliori prestazioni multi-tenant pratiche. Anche se questa configurazione potrebbe non descrivere perfettamente tutti organizzazioni, può essere facilmente esteso 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 di 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 i nodi e le risorse del cluster.
Pianificare 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 una configurazione aggiuntiva sistemi Google Cloud per gestire la complessità che non esistono in deployment Kubernetes più semplici con applicazione singola e team singolo. Questo include la configurazione di entrambi i progetti per isolare i problemi amministrativi oltre a mappare la struttura organizzativa a identità e account cloud e la gestione di risorse Google Cloud aggiuntive, come database, logging e per il monitoraggio, l'archiviazione e il networking.
Stabilisci una gerarchia di cartelle e progetti
Per capire come la tua organizzazione gestisce le risorse Google Cloud e applicare una separazione dei problemi, usa cartelle e progetti. Le cartelle consentono a diversi team di impostare criteri che vengono applicati a cascata per i progetti, mentre i progetti possono essere usati per isolare gli ambienti (ad esempio produzione o gestione temporanea) e tra i team. Ad esempio, la maggior parte le organizzazioni dispongono di un team per gestire l'infrastruttura di rete e di un team per gestire i cluster. Ogni tecnologia è considerata un pezzo a parte dello stack che richiedono un proprio livello di competenza, risoluzione dei problemi e accesso.
Una cartella principale può contenere fino a 300 cartelle e puoi nidificarne fino a 10 livelli più profondi. Se hai più di 300 affittuari, 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 iniziare, identifica gruppi necessari per l'organizzazione e l'ambito delle operazioni, quindi assegna il ruolo IAM appropriato gruppo.
Usa Google Gruppi per assegnare e gestire in modo efficiente i ruoli IAM per utenti.Centralizza il controllo della rete
Per mantenere il controllo centralizzato sulle risorse di rete, come subnet, route e firewall, utilizzano le reti VPC condivise. Le risorse in un VPC condiviso possono comunicare tra loro in modo sicuro in modo efficiente oltre i confini dei progetti usando IP interni. Ciascuna La rete VPC condiviso è definita e di proprietà di un progetto host centralizzato. e può essere utilizzato da uno o più progetti di servizio.
Utilizzando VPC condiviso e IAM, puoi separare le reti dall'amministrazione dei progetti. Questa separazione consente di implementare il principio del privilegio minimo. Ad esempio, un team di rete centralizzato amministrano la rete senza disporre di autorizzazioni per l'accesso in modo programmatico a gestire i progetti. Analogamente, gli amministratori del progetto possono gestire le risorse del progetto senza autorizzazioni a manipolare la rete condivisa.
Quando configuri un VPC condiviso, devi configurare le subnet e le relative intervalli IP secondari nel VPC. Per determinare le dimensioni della subnet, devi conoscere il numero previsto di tenant, il numero di pod e servizi di esecuzione prevista e le dimensioni massime e medie dei pod. Il calcolo del necessaria per comprendere il comportamento desiderato dimensione dell'istanza, che fornisce il numero totale di nodi. Con il numero totale di nodi, può essere calcolato lo spazio IP totale utilizzato, in modo da 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 collegati a un host progetto è 1000 e il numero massimo di I progetti host del VPC condiviso in una singola organizzazione sono pari a 100.
- Gli intervalli IP di nodi, pod e servizi devono essere tutti univoci. Non puoi creare una subnet con account primario e secondario Gli intervalli di indirizzi IP si sovrappongono.
- Il numero massimo di pod e servizi per un determinato GKE è limitato dalla dimensione degli intervalli secondari del cluster.
- Il numero massimo di nodi nel cluster è limitata dalla dimensione dell'IP principale della subnet del cluster di indirizzi IP e l'intervallo di indirizzi dei pod del cluster.
- Per maggiore flessibilità e maggiore controllo sulla gestione degli indirizzi IP, è possibile configurare il numero massimo di pod che possono essere eseguiti su un nodo. Riducendo il numero di pod per nodo, ridurre l'intervallo CIDR allocato per nodo, richiedendo meno indirizzi IP.
Per calcolare le subnet per i cluster, puoi usare IPAM GKE calcolatrice. IP Address Management (IPAM) abilita un uso efficiente di spazio/subnet IP ed evita sovrapposizioni negli intervalli, impedisce le opzioni di connettività lungo la strada. Per informazioni sugli intervalli di rete in un cluster VPC, consulta Creazione di una rete VPC nativa cluster.
Tenant che richiedono un ulteriore isolamento per le risorse eseguite all'esterno ad esempio le VM dedicate di Compute Engine, possono utilizzare VPC, che è connesso in peering al VPC condiviso eseguito team di networking. Ciò fornisce ulteriore sicurezza al costo di una maggiore complessità e numerosi altri limiti. Per ulteriori informazioni sul peering, consulta Utilizzo del peering di rete VPC. Nella nell'esempio riportato di seguito, tutti i tenant hanno scelto di condividere un singolo progetto (per ambiente) VPC tenant.
Creazione di cluster affidabili e ad alta disponibilità
Progetta l'architettura del tuo cluster per garantire disponibilità elevata e affidabilità tramite l'implementazione dei seguenti consigli:
- Crea un progetto di amministrazione del cluster per cluster per ridurre il rischio a livello di progetto configurazioni errate (ad esempio le associazioni IAM) che interessano molti cluster e per contribuire a fornire una separazione tra quota e fatturazione. I progetti di amministrazione del cluster sono separati dai progetti tenant, utilizzati dai singoli tenant per gestire, ad esempio, le risorse Google Cloud.
- Rendi privato il cluster di produzione per disabilitare l'accesso ai nodi e gestire l'accesso al piano di controllo. Me consigliamo inoltre di usare cluster privati per lo sviluppo e la gestione temporanea ambienti cloud-native.
- Assicurati che il piano di controllo per il cluster sia regionale per fornire alta disponibilità per l'architettura multi-tenancy. eventuali interruzioni del servizio il piano di controllo avrà un impatto sui tenant. Tieni presente che ci sono implicazioni in termini di costi all'esecuzione di cluster a livello di regione. Cluster Autopilot sono preconfigurati come cluster a livello di regione.
- Assicurati che i nodi nel tuo cluster includano almeno tre zone per ottenere risultati a livello di zona l'affidabilità. Per informazioni sul costo del traffico in uscita tra zone nel stessa regione, consulta i prezzi della rete documentazione.
Scala automaticamente i nodi e le risorse del cluster
Per soddisfare le esigenze dei tuoi tenant, scala automaticamente i nodi nel tuo abilitando la scalabilità automatica.La scalabilità automatica aiuta i sistemi a apparire reattivi e integri quando i carichi di lavoro sono intensivi il deployment da parte di 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 tuoi 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 a prescindere dallo spazio dei nomi in cui vengono eseguiti. Scalabilità automatica dei cluster pool di nodi basati sul limite min/max, contribuendo a ridurre i costi operativi quando il carico del sistema diminuisce ed evitare che i pod passino allo stato In attesa quando le risorse del cluster non sono sufficienti. Per determinare il numero massimo di nodi, identifica la quantità massima di CPU e memoria utilizzata da ogni tenant richiede e somma questi importi per ottenere la capacità totale dovrebbe essere in grado di gestire se tutti i tenant fossero al limite. L'utilizzo del di nodi, puoi scegliere le dimensioni e i conteggi delle istanze, prendendo 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 di repliche dei pod in base all'utilizzo di CPU/memoria o a metriche personalizzate. Scalabilità automatica pod verticale (VPA) possono essere usate 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 una con l'altra. Per questo motivo, inizia con l'HPA e solo successivamente VPA quando necessaria.
Determina la dimensione del cluster
Quando determini la dimensione del tuo cluster, ecco alcuni fattori importanti da considera:
- Il dimensionamento del cluster dipende dal tipo di carichi di lavoro che prevedi di vengono eseguiti tutti i test delle unità. Se i carichi di lavoro hanno una maggiore densità, l'efficienza in termini di costi è più elevata ma c'è anche una maggiore possibilità di conflitto tra risorse.
- La dimensione minima di un cluster è definita dal numero di zone distribuite: uno per un cluster a livello di zona e tre nodi per un cluster a livello di regione.
- Per progetto è previsto un massimo di 50 cluster per zona, più 50 a livello di regione cluster per regione.
- Per cluster, esiste un massimo di 15.000 nodi per cluster (5000 versioni GKE fino alla 1.17), 1000 nodi per pool di nodi, 1000 nodi per cluster (se utilizzi GKE controller Ingress), 256 pod per nodo (110 per le versioni GKE precedenti alla 1.23.5-gke.1300), 150.000 pod per cluster e 300.000 container per cluster. Consulta le Pagina Quote e limiti per ulteriori informazioni.
Pianificare periodi di manutenzione
Pianifica per ridurre i tempi di inattività durante gli upgrade e la manutenzione di cluster/nodi periodi di manutenzione avvengono al di fuori delle ore di punta. Durante gli upgrade, possono verificarsi e interruzioni quando si spostano i carichi di lavoro per ricreare i nodi. Per garantire un impatto minimo di tali interruzioni, pianificare gli upgrade al di fuori delle ore di punta e progettare i deployment delle applicazioni per gestire senza problemi le interruzioni parziali, se possibile.
Configura un bilanciatore del carico delle applicazioni esterno con Ingress
Per aiutarti nella gestione dei tenant pubblicato Servizi
e la gestione del traffico in entrata verso tali Servizi, creano un protocollo HTTP(S)
bilanciatore del carico per consentire
del traffico in entrata per cluster, dove i servizi di ogni tenant sono registrati
Risorsa in entrata. Puoi creare e gestire
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 a
dell'applicazione del tenant. Registrando i servizi con la risorsa Ingress,
dei Servizi di denominazione 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.
Utilizza 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 la comunicazione di rete tra i pod in ciascuno dei cluster
degli spazi dei nomi, crea criteri di rete
in base al servizio i tuoi requisiti. Come consiglio iniziale,
dovrebbe bloccare il traffico tra spazi dei nomi che ospitano tenant diversi
diverse applicazioni. L'amministratore del cluster può applicare un criterio di rete deny-all
per negare tutto il traffico in entrata ed evitare accidentalmente pod da uno spazio dei nomi
inviando 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
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 alla sicurezza vulnerabilità rispetto ad altri cluster. Con GKE Sandbox, puoi rafforzare i limiti di isolamento tra i carichi di lavoro per il tuo multi-tenant completamente gestito di Google Cloud. 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, uno progetto di sandboxing di container open source e fornisce un isolamento aggiuntivo per carichi di lavoro multi-tenant aggiungendo un ulteriore livello tra i container e l'host . I runtime dei container spesso vengono eseguiti come utenti con privilegi sul nodo e accesso alla maggior parte delle chiamate di sistema nel kernel dell'host. In un cluster multi-tenant, uno un tenant dannoso può ottenere l’accesso al kernel dell’host e ai dati di altri tenant. GKE Sandbox attenua queste minacce riducendo la necessità di container interagiscono con l'host, riducendo la superficie di attacco dell'host limitare il movimento dei malintenzionati.
GKE Sandbox fornisce due limiti di isolamento tra il container e sistema operativo host:
- Un kernel dello spazio utente, scritto in Go, che gestisce le chiamate di sistema e i limiti l'interazione con il kernel dell'host. Ogni pod ha il proprio spazio utente isolato in un kernel.
- Il kernel dello spazio utente viene eseguito anche all'interno degli spazi dei nomi e del filtro seccomp chiamate di sistema.
Configura controlli di ammissione basati su criteri
Per evitare che i pod che violano i limiti di sicurezza vengano eseguiti in usa un controller di ammissione. I controller di ammissione possono controllare il pod rispetto ai criteri che definisci e possono impedire ai pod che che violano questi criteri per l'esecuzione nel cluster.
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 Agente criteri aperto del gatekeeper ed è una funzionalità di GKE Enterprise.
- Controller di ammissione PodSecurity: Applicare criteri predefiniti che corrispondono Standard di sicurezza dei pod in 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 Federazione delle identità dei carichi di lavoro per GKE in in un cluster Kubernetes. La federazione delle identità per i carichi di lavoro per GKE aiuta gli amministratori a gestire il 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 abilitata per GKE, viene generato uno spazio dei nomi delle identità per il progetto in cui è ospitato il cluster. L'identità consente al cluster di autenticare automaticamente gli account di servizio le applicazioni GKE mediante la mappatura dell'account di servizio Kubernetes all'handle di un account di servizio Google virtuale, che viene utilizzato 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. Nel GKE, quando abiliti Autorizzato reti, puoi autorizzare fino a 50 intervalli CIDR e consentire agli indirizzi IP solo in questi intervalli di accedere dal piano di controllo. GKE utilizza già Transport Layer Security (TLS) e l'autenticazione per fornire un accesso sicuro al piano di controllo dalla rete internet pubblica. Utilizzando reti autorizzate, è possibile limitare 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 del 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 in del progetto host tenant.
Usa RBAC per perfezionare l'accesso del tenant
Definisci un accesso più granulare alle risorse del cluster per i tenant utilizzando RBAC per Kubernetes. In aggiunta all'accesso di sola lettura inizialmente concesso con IAM a 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 nel proprio spazio dei nomi. |
Oltre a creare ruoli e associazioni RBAC che assegnano Google Workspace o Cloud Identity raggruppa varie autorizzazioni all'interno del proprio spazio dei nomi, Tenant. gli amministratori spesso richiedono la possibilità di gestire gli utenti in ciascuno di questi gruppi. Sede in base ai requisiti della tua organizzazione, puoi delegare Autorizzazioni di Google Workspace o Cloud Identity per l'amministratore tenant per la gestione la propria iscrizione al gruppo o l'amministratore inquilino con un team un'organizzazione che dispone delle autorizzazioni di Google Workspace o Cloud Identity per gestire tali modifiche.
. Puoi utilizzare le autorizzazioni IAM e RBAC insieme agli spazi dei nomi per limitare l'accesso interazioni con le risorse del cluster sulla console Google Cloud. Per ulteriori informazioni, vedi Abilita l'accesso e visualizza le risorse del cluster per spazio dei nomi.Utilizza Google Gruppi per associare le autorizzazioni
Per gestire in modo efficiente le autorizzazioni del tenant in un cluster, puoi associare RBAC le autorizzazioni per i tuoi gruppi Google. L'appartenenza a questi gruppi è gestita dal tuo account Google Workspace amministratori di cluster, perciò gli amministratori del cluster non hanno bisogno di informazioni dettagliate sui tuoi utenti.
Ad esempio, abbiamo un gruppo Google chiamato tenant-admins@mydomain.com e un
l'utente admin1@mydomain.com è membro di questo gruppo, quanto segue
L'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, implementare gli spazi dei nomi. Nell'ambito del processo RBAC di Kubernetes, l'amministratore del cluster e crea spazi dei nomi per ogni gruppo di tenant. L'amministratore tenant gestisce gli utenti (tenant degli sviluppatori) all'interno del rispettivo spazio dei nomi tenant. Gli sviluppatori tenant possono 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 ci sono molti fattori che potrebbero impedirti di raggiungere questo limite. Ad esempio, potresti raggiungere il numero massimo di pod a livello di cluster (150.000) e nodi (5000) prima di raggiungere il numero massimo di spazi dei nomi; altro come il numero di Secret, possono ridurre ulteriormente i limiti effettivi. Di conseguenza, una buona regola empirica iniziale è cercare di avvicinarvi alle limite teorico di un vincolo alla volta e rimanere approssimativamente di un ordine di grandezza lontano dagli altri limiti, a meno che la sperimentazione non mostri che la tua per i casi d'uso funzionano bene. Se hai bisogno di più risorse di quelle che possono essere supportate da un un unico cluster, devi creare più cluster. Per informazioni su Scalabilità di Kubernetes, consulta le soglie di scalabilità di Kubernetes .
Standardizza la denominazione degli spazi dei nomi
Per semplificare i deployment in più ambienti ospitati in diversi ambienti standard, standardizza la convenzione di denominazione degli spazi dei nomi che utilizzi. Ad esempio: evitare di associare il nome dell'ambiente (sviluppo, gestione temporanea e produzione) al del nome dello spazio dei nomi, utilizzando invece lo stesso nome in più ambienti. Utilizzando i comandi stesso nome, evitando di dover cambiare i file di configurazione da un ambiente all'altro.
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 in un dello 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 dispongono rispettivi spazi dei nomi. L'account di servizio Kubernetes per ogni spazio dei nomi mappato a un account di servizio Google utilizzando la Federazione delle identità per i carichi di lavoro per GKE.
Applica le quote delle risorse
garantire che tutti i tenant che condividono un cluster abbiano un accesso equo al cluster le risorse, applicare le risorse quotas. Crea una quota di risorse per ogni spazio dei nomi in base il numero di pod di cui è stato eseguito il deployment da ogni tenant e la quantità di memoria e CPU richiesta da ciascun pod.
L'esempio seguente definisce una quota di risorse in cui i pod nel campo tenant-a
può richiedere fino a 16 CPU e 64 GB di memoria e la CPU massima è
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, possono abilitare l'allocazione dei costi di GKE. L'allocazione dei costi di GKE monitora le informazioni sulle richieste e sull'utilizzo delle risorse dei carichi di lavoro di un cluster, che puoi suddividere ulteriormente in base a spazi dei nomi etichette. Con l'allocazione dei costi di GKE, puoi approssimare la suddivisione dei costi per reparti/team che condividono un cluster, comprendano i modelli di utilizzo singole applicazioni (o anche componenti di una singola applicazione), gli amministratori del cluster valutano i picchi di utilizzo e offrono una migliore pianificazione della capacità la definizione del budget.
Quando abiliti l'allocazione dei costi di GKE, il nome e lo spazio dei nomi del cluster I carichi di lavoro GKE vengono visualizzati nel campo Etichette 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, usa Router dei log di Cloud Logging. A per creare log specifici per il tenant, l'amministratore del cluster crea sink per esportare le voci di log in un bucket di log creato nel bucket Google Cloud del tenant progetto.
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, consulta Protezione sicurezza.
- Per saperne di più sulle reti VPC, consulta Best practice e riferimenti per la progettazione di VPC.
- Per altre best practice aziendali, vedi Framework dell'architettura Google Cloud.