Architettura di cluster multi-tenancy

Questa pagina spiega la multitenancy del cluster su Google Kubernetes Engine (GKE). Sono inclusi i cluster condivisi da utenti diversi di una singola organizzazione e i cluster condivisi da istanze per cliente di un'applicazione SaaS (Software as a Service). L'architettura di cluster multi-tenancy è un'alternativa alla gestione di molti cluster mono-tenant.

Questa pagina riassume anche le funzionalità di Kubernetes e GKE che possono essere utilizzate per gestire i cluster multi-tenant.

Che cos'è il multitenancy?

Un cluster multi-tenant è condiviso da più utenti e/o carichi di lavoro, chiamati "tenant". Gli operatori dei cluster multi-tenant devono isolare i tenant tra loro per ridurre al minimo i danni che un tenant compromesso o malintenzionato può causare al cluster e agli altri tenant. Inoltre, le risorse del cluster devono essere allocate equamente tra i tenant.

Quando pianifichi un'architettura multi-tenant, devi considerare i livelli di isolamento delle risorse in Kubernetes: cluster, spazio dei nomi, nodo, pod e contenitore. Devi anche considerare le implicazioni di sicurezza della condivisione di diversi tipi di risorse tra gli utenti. Ad esempio, la pianificazione di pod di tenant diversi sullo stesso nodo potrebbe ridurre il numero di macchine necessarie nel cluster. D'altra parte, potresti dover impedire il collocamento in comune di determinati carichi di lavoro. Ad esempio, potresti non consentire l'esecuzione di codice non attendibile esterno alla tua organizzazione sullo stesso nodo dei container che elaborano informazioni sensibili.

Sebbene Kubernetes non possa garantire un isolamento perfettamente sicuro tra i tenant, offre funzionalità che potrebbero essere sufficienti per casi d'uso specifici. Puoi separare ogni tenant e le relative risorse Kubernetes in propri spazi dei nomi. Puoi quindi utilizzare i criteri per applicare l'isolamento dei tenant. I criteri sono generalmente definiti in base allo spazio dei nomi e possono essere utilizzati per limitare l'accesso alle API, per limitare l'utilizzo delle risorse e per limitare le operazioni consentite ai container.

I tenant di un cluster multi-tenant condividono:

L'utilizzo di un cluster multi-tenant presenta diversi vantaggi rispetto all'utilizzo di più cluster mono-tenant:

  • Overhead di gestione ridotto
  • Riduzione della frammentazione delle risorse
  • Non è necessario attendere la creazione del cluster per i nuovi tenant

Casi d'uso di multitenancy

Questa sezione descrive come configurare un cluster per vari casi d'uso di multitenancy.

Architettura multi-tenancy aziendale

In un ambiente aziendale, gli tenant di un cluster sono team distinti all'interno dell'organizzazione. In genere, ogni tenant ha uno spazio dei nomi corrispondente. I modelli alternativi di multitenancy con un tenant per cluster o un tenant per Google Cloud progetto sono più difficili da gestire. Il traffico di rete all'interno di uno spazio dei nomi è illimitato. Il traffico di rete tra gli spazi dei nomi deve essere consentito esplicitamente. Questi criteri possono essere applicati utilizzando il criterio di rete di Kubernetes.

Gli utenti del cluster sono suddivisi in tre diversi ruoli, a seconda del loro privilegio:

Amministratore del cluster
Questo ruolo è destinato agli amministratori dell'intero cluster, che gestiscono tutti i tenant. Gli amministratori del cluster possono creare, leggere, aggiornare ed eliminare qualsiasi oggetto di criteri. Possono creare spazi dei nomi e assegnarli agli amministratori dello spazio dei nomi.
Amministratore dello spazio dei nomi
Questo ruolo è destinato agli amministratori di singoli tenant specifici. Un amministratore del nome di un ambito può gestire gli utenti nel proprio ambito.
Sviluppatore
I membri di questo ruolo possono creare, leggere, aggiornare ed eliminare oggetti non correlati ai criteri con spazio dei nomi, come pod, job ed ingressi. Gli sviluppatori dispongono di questi privilegi solo negli spazi dei nomi a cui hanno accesso.

Per informazioni sulla configurazione di più cluster multi-tenant per un'organizzazione aziendale, consulta le best practice per la multitenancy aziendale.

Multitenancy del provider SaaS

Gli tenant del cluster di un provider SaaS sono le istanze per cliente dell'applicazione e il piano di controllo del SaaS. Per sfruttare i criteri basati sullo spazio dei nomi, le istanze dell'applicazione devono essere organizzate in spazi dei nomi propri, così come i componenti del piano di controllo del SaaS. Gli utenti finali non possono interagire direttamente con il piano di controllo Kubernetes, ma utilizzano l'interfaccia del SaaS, che a sua volta interagisce con il piano di controllo Kubernetes.

Ad esempio, una piattaforma di blogging potrebbe essere eseguita su un cluster multi-tenant. In questo caso, gli utenti sono l'istanza del blog di ciascun cliente e il piano di controllo della piattaforma. Il piano di controllo della piattaforma e ogni blog ospitato funzioneranno tutti in spazi dei nomi distinti. I clienti potevano creare ed eliminare blog, aggiornare le versioni del software di blogging tramite l'interfaccia della piattaforma senza avere alcuna visibilità sul funzionamento del cluster.

Applicazione dei criteri di multitenancy

GKE e Kubernetes forniscono diverse funzionalità che possono essere utilizzate per gestire i cluster multi-tenant. Le sezioni seguenti forniscono una panoramica di queste funzionalità.

Controllo degli accessi

GKE dispone di due sistemi di controllo dell'accesso: Identity and Access Management (IAM) e controllo dell'accesso basato su ruoli (RBAC). IAM è il sistema di controllo dell'accesso di Google Cloudper la gestione dell'autenticazione e dell'autorizzazione per le risorse Google Cloud. Utilizzi IAM per concedere agli utenti l'accesso alle risorse GKE e Kubernetes. L'RBAC è integrato in Kubernetes e concede autorizzazioni granulari per risorse e operazioni specifiche all'interno dei cluster.

Per ulteriori informazioni su queste opzioni e su quando utilizzarle, consulta la Panoramica del controllo dell'accesso.

Consulta la guida di istruzioni RBAC e la guida di istruzioni IAM per scoprire come utilizzare questi sistemi di controllo dell'accesso'accesso.

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

Criteri di rete

I criteri di rete del cluster ti consentono di controllare la comunicazione tra i pod del cluster. I criteri specificano gli spazi dei nomi, le etichette e gli intervalli di indirizzi IP con cui un pod può comunicare.

Consulta la guida ai criteri di rete per istruzioni su come attivare l'applicazione dei criteri di rete su GKE.

Segui il tutorial sui criteri di rete per scoprire come scrivere i criteri di rete.

Quote delle risorse

Le quote di risorse gestiscono la quantità di risorse utilizzate dagli oggetti in un ambito. Puoi impostare le quote in termini di utilizzo della CPU e della memoria o in termini di conteggi degli oggetti. Le quote delle risorse ti consentono di assicurarti che nessun tenant utilizzi più della sua quota assegnata di risorse del cluster.

Per ulteriori informazioni, consulta la documentazione relativa alle quote delle risorse.

Controllo di ammissione dei pod basato su criteri

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

GKE supporta i seguenti tipi di controllo dell'accesso:

Anti-affinità dei pod

Puoi utilizzare l'anti-affinità dei pod per impedire la pianificazione di pod di tenant diversi sullo stesso nodo. I vincoli di anti-affinità si basano sulle etichette dei pod. Ad esempio, la specifica del pod riportata di seguito descrive un pod con l'etichetta "team": "billing" e una regola di anti-affinità che impedisce la pianificazione del pod insieme ai pod senza l'etichetta.

apiVersion: v1
kind: Pod
metadata:
  name: bar
  labels:
    team: "billing"
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: "kubernetes.io/hostname"
        labelSelector:
          matchExpressions:
          - key: "team"
            operator: NotIn
            values: ["billing"]

Lo svantaggio di questa tecnica è che gli utenti malintenzionati potrebbero aggirare la regola applicando l'etichetta team: billing a un pod arbitrario. L'anti-affinità dei pod da sola non può applicare in modo sicuro i criteri ai cluster con tenant non attendibili.

Per ulteriori informazioni, consulta la documentazione sull'anti-affinità dei pod.

Nodi dedicati con incompatibilità e tolleranze

Le incompatibilità dei nodi sono un altro modo per controllare la pianificazione dei carichi di lavoro. Puoi utilizzare le incompatibilità dei nodi per prenotare nodi specializzati da utilizzare da parte di determinati tenant. Ad esempio, puoi dedicare nodi con GPU ai tenant specifici i cui carichi di lavoro richiedono GPU. Per i cluster Autopilot, le tolleranze dei nodi sono supportate solo per la separazione dei carichi di lavoro. I taint dei nodi vengono aggiunti automaticamente dal provisioning automatico dei nodi in base alle esigenze.

Per dedicare un pool di nodi a un determinato tenant, applica un'alterazione con effect: "NoSchedule" al pool di nodi. In questo modo, solo i pod con una tolleranza corrispondente possono essere pianificati sui nodi del pool di nodi.

Lo svantaggio di questa tecnica è che gli utenti malintenzionati potrebbero aggiungere una tolleranza ai loro pod per ottenere l'accesso al pool di nodi dedicato. Le incompatibilità dei nodi e le tolleranze da sole non possono applicare in modo sicuro i criteri ai cluster con tenant non attendibili.

Per ulteriori informazioni, consulta Incompatibilità e tolleranze nella documentazione di Kubernetes.

Passaggi successivi