Best practice per architettura multi-tenancy aziendale

Il 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 del funzionamento di uno o più carichi di lavoro.
• Un insieme di carichi di lavoro correlati, gestiti da uno o più team.
• Un singolo workload, ad esempio un deployment.

L'architettura multi-tenant del cluster viene spesso implementata per ridurre i costi o per applicare in modo coerente le norme di amministrazione tra i tenant. Tuttavia, la configurazione errata di un cluster GKE o delle relative risorse GKE può comportare un mancato risparmio sui costi, un'applicazione errata dei criteri o interazioni distruttive tra i 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 di questa guida si basano su un caso d'uso multi-tenant per un ambiente aziendale, che presenta i seguenti presupposti 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 workload.
• Oltre ai team di applicazioni/servizi, esistono altri team che utilizzano e gestiscono i cluster, tra cui i membri del team della piattaforma, gli amministratori dei cluster, gli auditor 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ò richiedere 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 sugli altri tenant nel cluster condiviso, tranne che 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 multitenant. 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

Per le organizzazioni aziendali che eseguono il deployment di cluster multi-tenant in GKE, è necessaria una configurazione aggiuntiva in altri sistemiGoogle Cloud per gestire la complessità che non esiste in deployment Kubernetes più semplici con una sola applicazione e un solo team. Ciò include sia la configurazione del progetto per isolare i problemi amministrativi sia il mapping della struttura dell'organizzazione a identità e account cloud e la gestione di risorse Google Cloud aggiuntive, come database, logging e monitoraggio, spazio di archiviazione e networking.

Stabilire una gerarchia di cartelle e progetti

Per capire in che modo la tua organizzazione gestisce le risorse e per applicare una separazione dei problemi, utilizza cartelle e progetti. Google Cloud Le cartelle consentono a team diversi di impostare policy che si applicano 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 il 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 di profondità. Se hai più di 300 tenant, puoi organizzarli in gerarchie nidificate per rimanere entro il limite. Per saperne di più sulle cartelle, consulta Creare e gestire le cartelle.

Assegnare ruoli utilizzando IAM

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

Centralizzare il controllo di 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.

Utilizzando VPC condiviso e IAM, puoi separare l'amministrazione di rete dall'amministrazione dei progetti. Questa separazione ti aiuta a 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. Allo stesso modo, gli amministratori del progetto possono gestire le risorse del progetto senza alcuna autorizzazione 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 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 desiderate e fornisce il numero totale di nodi. Con il numero totale di nodi, è possibile calcolare lo spazio IP totale utilizzato, che può fornire la dimensione della subnet desiderata.

Ecco alcuni fattori da considerare anche quando configuri la rete:

• Il numero massimo di progetti di servizio che possono essere collegati a un progetto host è 1000 e il numero massimo di progetti host con 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 primari 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 del cluster e dall'intervallo di indirizzi pod del cluster.
• Per flessibilità e un 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 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 al di fuori dei cluster condivisi (ad esempio le VM Compute Engine dedicate) possono utilizzare il proprio VPC, che è in peering con il VPC condiviso gestito dal team di networking. Ciò fornisce una sicurezza aggiuntiva a costo di una maggiore complessità e numerose altre limitazioni. Per saperne di più sul peering, consulta Utilizzo del peering di rete VPC. Nell'esempio 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 cluster per l'alta disponibilità e l'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 i binding IAM) influiscano negativamente su molti cluster e per contribuire a fornire la 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 proprie risorse. Google Cloud
• Configura l'isolamento di rete per disabilitare l'accesso ai nodi e gestire l'accesso al control plane. Consigliamo anche di configurare l'isolamento di rete per gli ambienti di sviluppo e staging.
• Assicurati che il control plane per il cluster sia regionale per fornire un'alta disponibilità per il multi-tenancy; eventuali interruzioni del control plane influiranno sui tenant. 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 si estendano su almeno tre zone per ottenere un'affidabilità zonale. Per informazioni sul costo del traffico in uscita tra zone nella stessa regione, consulta la documentazione sui prezzi di rete.

Scalabilità automatica di nodi e risorse del cluster

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

La scalabilità automatica aiuta i sistemi a sembrare reattivi e integri quando vengono implementati carichi di lavoro pesanti da vari tenant nei rispettivi spazi dei nomi o a rispondere a interruzioni di zona.

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 previste del workload. 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 del cluster ridimensiona i node pool 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 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 ogni 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 quindi 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 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, poiché i due autoscaler possono competere tra loro. Per questo motivo, inizia con HPA e solo in un secondo momento con VPA, se necessario.

Determinare le dimensioni del cluster

Quando determini le dimensioni del cluster, ecco alcuni fattori importanti da considerare:

• Il dimensionamento del cluster dipende dal tipo di carichi di lavoro che prevedi di eseguire. Se i tuoi carichi di lavoro hanno una densità maggiore, l'efficienza dei costi è più elevata, ma c'è anche una maggiore possibilità 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, sono consentiti un massimo di 50 cluster per zona, più 50 cluster regionali per regione.

• Per 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)
  • Per impostazione predefinita,5000 nodi per cluster. Puoi aumentare questo limite a 15.000 o a 65.000 nodi. Per saperne di più, vedi 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.

Pianifica periodi di manutenzione

Per ridurre i tempi di inattività durante gli upgrade e la manutenzione di cluster/nodi, pianifica periodi di manutenzione da eseguire durante le ore non di punta. Durante gli upgrade, possono verificarsi interruzioni temporanee quando i workload vengono spostati per ricreare i nodi. Per garantire un impatto minimo di queste interruzioni, pianifica gli upgrade per le ore non di punta e progetta i deployment delle applicazioni in modo che gestiscano 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 la gestione del traffico in entrata verso questi servizi, crea un bilanciatore del carico HTTP(S) per consentire un singolo ingresso per cluster, in cui i servizi di ogni 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 il modo in cui 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 unico ingresso, come tenanta.example.com e tenantb.example.com.

Protezione del cluster per l'architettura multi-tenant

Controllare 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 tenant diversi. 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 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 a vulnerabilità di sicurezza rispetto ad altri cluster. Utilizzando 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 utilizzare i controlli di ammissione basati su criteri per colmare eventuali lacune.

GKE Sandbox si basa su gVisor, un progetto di sandboxing dei container open source, e fornisce un isolamento aggiuntivo per i carichi di lavoro multi-tenant aggiungendo un livello extra tra i container e il sistema operativo host. I runtime dei container vengono spesso eseguiti come utente privilegiato sul nodo e hanno accesso alla maggior parte delle chiamate di sistema al kernel host. In un cluster multi-tenant, un tenant dannoso può accedere al kernel host e ai dati di altri tenant. GKE Sandbox mitiga 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 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 user-space isolato.
• Il kernel dello spazio utente viene eseguito anche all'interno di spazi dei nomi e chiamate di sistema di filtraggio seccomp.

Configurare i controlli di ammissione basati su policy

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

GKE supporta i seguenti tipi di controllo dell'ammissione:

• Policy Controller: Dichiara norme predefinite o personalizzate e applicale nei cluster su larga scala utilizzando i fleet. Policy Controller è un'implementazione dell'agente open source per i criteri Gatekeeper ed è una funzionalità di GKE Enterprise.

• Controller di ammissione PodSecurity: Applica criteri predefiniti che corrispondono agli 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 Google Cloud servizi

Per concedere in modo sicuro l'accesso ai servizi ai workload, abilita la federazione delle identità per i carichi di lavoro per GKE nel cluster. Google Cloud Workload Identity Federation for GKE aiuta gli amministratori a gestire gli account di servizio Kubernetes che i workload Kubernetes utilizzano 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 i service account per le applicazioni GKE mappando il nome del account di servizio Kubernetes a un handle di account di servizio Google virtuale, che viene utilizzato per il binding IAM dei service account Kubernetes tenant.

Limita l'accesso di rete al control plane

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

Provisioning del 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 per le applicazioni tenant (ad esempio, log, monitoraggio, bucket di archiviazione, service account e così via). Tutti i progetti di servizio tenant sono connessi al VPC condiviso nel progetto host tenant.

Utilizzare RBAC per perfezionare l'accesso al 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 tenant, definisci ruoli e associazioni RBAC di Kubernetes a livello di spazio dei nomi per ogni gruppo tenant.

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

Oltre a creare ruoli e binding RBAC che assegnano a 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, questa operazione può essere gestita delegando le autorizzazioni Google Workspace o Cloud Identity all'amministratore tenant per gestire la propria appartenenza al gruppo oppure chiedendo all'amministratore tenant di collaborare con un team della tua organizzazione che disponga delle autorizzazioni Google Workspace o Cloud Identity per gestire queste modifiche.

Utilizzare 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 viene gestita dagli amministratori di Google Workspace, pertanto gli amministratori del cluster non hanno bisogno di informazioni dettagliate sugli utenti.

Ad esempio, se abbiamo un Gruppo Google denominato tenant-admins@mydomain.com e un utente denominato admin1@mydomain.com è membro di questo gruppo, il seguente binding 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 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 tenant gestisce gli utenti (sviluppatori tenant) all'interno del proprio spazio dei nomi tenant. Gli sviluppatori tenant possono quindi utilizzare risorse specifiche del cluster e del 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 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 pratica iniziale è tentare di avvicinarsi al limite teorico di un vincolo alla volta e rimanere a circa un ordine di grandezza di distanza dagli altri limiti, a meno che la sperimentazione non dimostri che i tuoi casi d'uso funzionano bene. Se hai bisogno di più risorse di quelle supportate da 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 cluster diversi, standardizza la convenzione di denominazione dello spazio dei nomi che utilizzi. Ad esempio, evita di collegare 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. Utilizzando lo stesso nome, eviti di dover modificare i file di configurazione nei vari ambienti.

Crea service account per i carichi di lavoro del tenant

Crea un account di servizio Google specifico per il tenant per ogni workload distinto in uno spazio dei nomi tenant. In questo modo viene fornita una forma di sicurezza, garantendo che i tenant possano gestire gli account di servizio per i workload di loro proprietà/che distribuiscono nei rispettivi spazi dei nomi. Il account di servizio Kubernetes per ogni spazio dei nomi viene 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. Crea 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 richiesta da 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 e la CPU massima è 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

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 GKE tiene traccia delle informazioni sulle richieste di risorse e sull'utilizzo delle risorse 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 stimare la suddivisione dei costi per dipartimenti/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 eseguire il triage dei 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 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 del progetto, 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 la sezione Logging multi-tenant su GKE.

Riepilogo della lista di controllo

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

Passaggi successivi

• Per ulteriori informazioni sulla sicurezza, vedi Rafforzare la sicurezza del cluster.
• Per ulteriori informazioni sulle reti VPC, consulta Best practice e architetture di riferimento per la progettazione di VPC.
• Per altre best practice aziendali, consulta il Google Cloud Well-Architected Framework.