Architettura di cluster multi-tenancy

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

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

Che cos'è l'architettura multi-tenancy?

Un cluster multi-tenant è condiviso da più utenti e/o carichi di lavoro denominati "tenant". Gli operatori dei cluster multi-tenant devono isolare i tenant l'uno dall'altro per ridurre al minimo i danni che un tenant compromesso o dannoso può causare al cluster e ad 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 container. Dovresti anche considerare le implicazioni in termini di sicurezza della condivisione di diversi tipi di risorse tra i tenant. Ad esempio, la pianificazione di pod di tenant diversi sullo stesso nodo potrebbe ridurre il numero di macchine necessarie nel cluster. D'altra parte, potrebbe essere necessario impedire la colocation di determinati carichi di lavoro. Ad esempio, potresti non consentire l'esecuzione di codice non attendibile esterno all'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 possono essere sufficienti per casi d'uso specifici. Puoi separare ciascun tenant e le relative risorse Kubernetes in spazi dei nomi propri. Puoi quindi utilizzare i criteri per applicare l'isolamento dei tenant. I criteri hanno in genere l'ambito per spazio dei nomi e possono essere utilizzati per limitare l'accesso alle API, limitare l'utilizzo delle risorse e limitare le azioni consentite ai container.

I tenant di un cluster multi-tenant condividono:

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

  • Spese di gestione ridotte
  • Frammentazione delle risorse ridotta
  • Non è necessario attendere la creazione del cluster per i nuovi tenant

Casi d'uso della multitenancy

Questa sezione descrive come configurare un cluster per vari casi d'uso multi-tenancy.

Architettura multi-tenancy aziendale

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

Gli utenti del cluster sono divisi in tre diversi ruoli, a seconda dei privilegi di cui dispongono:

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 dei 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 tenant singoli specifici. Un amministratore dello spazio dei nomi può gestire gli utenti nel loro spazio dei nomi.
Sviluppatore
I membri di questo ruolo possono creare, leggere, aggiornare ed eliminare oggetti non basati sui criteri con spazio dei nomi come Pod, Job e In entrata. Gli sviluppatori hanno 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 multi-tenancy aziendale.

Provider SaaS multi-tenancy

I tenant del cluster di un provider SaaS sono le istanze dell'applicazione per cliente e il piano di controllo del SaaS. Per sfruttare i criteri basati sullo spazio dei nomi, le istanze delle applicazioni 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 invece l'interfaccia di 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, i tenant 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 vengono eseguiti in spazi dei nomi separati. I clienti creavano ed eliminavano i blog, aggiornavano le versioni software dei blog tramite l'interfaccia della piattaforma senza avere visibilità sul funzionamento del cluster.

Applicazione dei criteri multi-tenancy

GKE e Kubernetes offrono varie funzionalità che possono essere usate per gestire cluster multi-tenant. Le sezioni seguenti forniscono una panoramica di queste funzionalità.

Controllo dell'accesso

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

Fai riferimento alla panoramica sul controllo dell'accesso per saperne di più su queste opzioni e su quando utilizzarle.

Per scoprire come utilizzare questi sistemi di controllo dell'accesso dell'accesso, consulta la guida illustrativa di RBAC e la guida illustrativa di IAM.

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.

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 le istruzioni sui criteri di rete per istruzioni su come abilitare 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 delle risorse gestiscono la quantità di risorse utilizzate dagli oggetti in uno spazio dei nomi. Puoi impostare le quote in termini di utilizzo di CPU e memoria o in termini di conteggio degli oggetti. Le quote delle risorse consentono di assicurare che nessun tenant utilizzi una quota di risorse del cluster superiore a quella assegnata.

Per ulteriori informazioni, consulta la documentazione sulle quote delle risorse.

Controllo di ammissione dei pod basato su criteri

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

GKE supporta i seguenti tipi di controlli di ammissione:

Anti-affinità dei pod

Puoi utilizzare l'anti-affinità dei pod per impedire che i pod di tenant diversi vengano pianificati 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 utenti malintenzionati potrebbero aggirare la regola applicando l'etichetta team: billing a un pod arbitrario. La sola anti-affinità dei pod non può applicare in modo sicuro i criteri sui cluster con tenant non attendibili.

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

Nodi dedicati con incompatibilità e tolleranze

Le incompatibilità dei nodi rappresentano un altro modo per controllare la pianificazione dei carichi di lavoro. Puoi utilizzare le incompatibilità dei nodi per prenotare nodi specializzati utilizzati da determinati tenant. Ad esempio, puoi dedicare i nodi dotati di GPU a tenant specifici i cui carichi di lavoro richiedono GPU. Per i cluster Autopilot, le tolleranze dei nodi sono supportate solo per la separazione del carico di lavoro. Le incompatibilità dei nodi vengono aggiunte automaticamente dal provisioning automatico dei nodi, se necessario.

Per dedicare un pool di nodi a un determinato tenant, applica un'incompatibilità con effect: "NoSchedule" al pool di nodi. Quindi solo i pod con una tolleranza corrispondente possono essere pianificati per i nodi nel pool di nodi.

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

Consulta la pagina di istruzioni sulle incompatibilità dei nodi per scoprire come controllare la pianificazione con le incompatibilità dei nodi.

Passaggi successivi