Architettura di cluster multi-tenancy

Questa pagina illustra la multi-tenancy dei cluster sulle Google Kubernetes Engine (GKE). Sono inclusi i cluster condivisi da diversi utenti su una singola organizzazione e i cluster condivisi da istanze di un'applicazione SaaS (Software as a Service). L'architettura multi-tenancy dei cluster un'alternativa alla gestione di molti cluster a singolo tenant.

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

Che cos'è la multitenancy?

Un cluster multi-tenant è condiviso da più utenti e/o carichi di lavoro che sono o "tenant". Gli operatori dei cluster multi-tenant devono isolare i tenant l’uno dall’altro per ridurre al minimo i danni causati che un tenant può eseguire sul cluster e su altri tenant. Inoltre, le risorse del cluster devono essere abbastanza distribuito tra i tenant.

Quando pianifichi un'architettura multi-tenant, devi considerare i livelli di di isolamento delle risorse in Kubernetes: cluster, spazio dei nomi, nodo, pod e container. Tu dovrebbe anche considerare le implicazioni sulla sicurezza derivanti dalla condivisione delle risorse tra i tenant. Ad esempio, pianificare pod da tenant diversi lo stesso nodo può ridurre il numero di macchine necessarie nel cluster. Il giorno Inoltre, potresti dover impedire la co-location di determinati carichi di lavoro. Ad esempio, potresti non consentire il codice non attendibile al di fuori del tuo in modo che sia eseguita sullo stesso nodo dei container che elaborano informazioni sensibili.

Sebbene Kubernetes non possa garantire l'isolamento perfettamente sicuro tenant, offre funzionalità che possono essere sufficienti per casi d'uso specifici. Puoi separare ogni tenant e le relative risorse Kubernetes in spazi dei nomi. Puoi quindi utilizzare i criteri per applicare e l'isolamento dei tenant. In genere, i criteri sono limitati allo spazio dei nomi e possono essere utilizzati per limitare accesso API, per limitare l'utilizzo delle risorse e per limitare i container che possono eseguire.

I tenant di un cluster multi-tenant condividono:

Il funzionamento di un cluster multi-tenant presenta diversi vantaggi rispetto al funzionamento di più istanze, di cluster a singolo tenant:

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

Casi d'uso multi-tenancy

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

Architettura multi-tenancy aziendale

In un ambiente aziendale, i tenant di un cluster sono team distinti all'interno all'interno dell'organizzazione. In genere, ogni tenant ha uno spazio dei nomi corrispondente. Modelli alternativi di multi-tenancy con un tenant per cluster o un tenant per progetti Google Cloud, sono più difficili da gestire. Il traffico di rete all'interno di uno spazio dei nomi non è limitato. Traffico di rete tra devono essere consentiti in modo esplicito. Questi criteri possono essere applicati Criterio di rete di Kubernetes.

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

Amministratore del cluster
Questo ruolo appartiene agli amministratori dell'intero cluster, che gestiscono tutti tenant. Gli amministratori di cluster possono creare, leggere, aggiornare ed eliminare qualsiasi criterio . Possono creare spazi dei nomi e assegnarli agli amministratori.
Amministratore spazio dei nomi
Questo ruolo è riservato agli amministratori di singoli tenant specifici. Uno spazio dei nomi amministratore può gestire gli utenti all'interno del proprio spazio dei nomi.
Sviluppatore
I membri di questo ruolo possono creare, leggere, aggiornare ed eliminare gli spazi dei nomi non conformi come oggetti Pod, Job e Ingress. Gli sviluppatori hanno con questi privilegi negli spazi dei nomi a cui hanno accesso.

Per informazioni sulla configurazione di più cluster multi-tenant per un consulta le best practice per le best practice che lo richiedono.

Provider di SaaS multi-tenancy

I tenant di un cluster di un provider SaaS sono le istanze per cliente e il piano di controllo del SaaS. Per sfruttare i vantaggi dell'ambito le istanze dell'applicazione devono essere organizzate in così come i componenti del piano di controllo SaaS. Gli utenti finali non possono interagiscono direttamente con il piano di controllo Kubernetes, 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 l'istanza dal piano di controllo. Il piano di controllo della piattaforma e ogni blog ospitato venivano tutti eseguiti in spazi dei nomi separati. I clienti creavano ed eliminavano blog, aggiornavano blogging delle versioni di software attraverso l'interfaccia della piattaforma senza visibilità nel funzionamento del cluster.

Applicazione dei criteri multi-tenancy

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

Controllo degli accessi

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

Fai riferimento alla sezione Controllo dell'accesso Panoramica per ulteriori informazioni. su queste opzioni e su quando utilizzarle.

Consulta le istruzioni per RBAC e la guida illustrativa IAM per scoprire come utilizzarli sistemi di controllo dell'accesso.

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.

Criteri di rete

Rete cluster norme per consentirti di controllare la comunicazione tra i pod del cluster. Norme specificare gli spazi dei nomi, le etichette e gli intervalli di indirizzi IP che un pod può comunicare con.

Consulta le istruzioni relative alle norme della rete per istruzioni su come abilitare l'applicazione forzata dei criteri di rete su con GKE.

Rispettare le norme della rete tutorial per imparare a usare e scrivere i criteri di rete.

Quote delle risorse

Le quote delle risorse gestiscono la quantità di risorse utilizzate dagli oggetti in un nello spazio dei nomi. Puoi impostare le quote in termini di utilizzo di CPU e memoria o il conteggio degli oggetti. Le quote delle risorse consentono di assicurare che nessun tenant utilizzi più del suo la quota assegnata delle risorse del cluster.

Fai riferimento alla risorsa quote documentazione per ulteriori informazioni.

Controllo dell'ammissione dei pod basato 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:

Anti-affinità pod

Puoi utilizzare i pod anti-affinità per impedire la pianificazione di pod di tenant diversi sullo stesso nodo. I vincoli di anti-affinità si basano sui pod etichette. 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 eludere la regola. applicando l'etichetta team: billing a un pod arbitrario. Anti-affinità pod da sola non è in grado di applicare in modo sicuro i criteri sui cluster con tenant non attendibili.

Fai riferimento al pod anti-affinità per ulteriori informazioni.

Nodi dedicati con incompatibilità e tolleranze

Le incompatibilità dei nodi sono un altro modo per controllare la pianificazione dei carichi di lavoro. Puoi utilizzare il nodo incompatibilità per prenotare nodi specializzati per l'utilizzo da parte di determinati tenant. Ad esempio, può dedicare i nodi dotati di GPU tenant specifici i cui carichi di lavoro richiedono GPU. Per i cluster Autopilot, le tolleranze dei nodi sono supportate solo separazione dei carichi di lavoro. Le incompatibilità dei nodi vengono aggiunte automaticamente dal provisioning automatico dei nodi, se necessario.

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

Lo svantaggio di questa tecnica è che utenti malintenzionati potrebbero aggiungere tolleranze i propri pod per ottenere l'accesso al pool di nodi dedicato. Incompatibilità e tolleranze dei nodi da sola non è in grado di applicare in modo sicuro i criteri sui cluster con tenant non attendibili.

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

Passaggi successivi