Best practice multi-tenancy

Best Practice: utilizzare il responsabile autorizzazioni RBAC per un accesso con filtro aggiuntivo

Si consiglia di utilizzare l'authorizer RBAC Kubernetes per applicare il controllo dell'accesso con filtro per gli utenti su cluster specifici tramite ruoli RBAC e clusterroles Kubernetes.

Un ruolo RBAC Kubernetes è una raccolta di autorizzazioni. Ad esempio, un ruolo potrebbe includere l'autorizzazione di lettura per i pod e l'autorizzazione di elenco per i pod. Un ruolo cluster RBAC Kubernetes è simile a un ruolo, ma può essere utilizzato in qualsiasi punto del cluster. Un'associazione di ruoli RBAC Kubernetes mappa un ruolo a un utente o a un gruppo, concedendo le autorizzazioni di tale ruolo all'utente o al gruppo per le risorse in tale spazio di nomi. Analogamente, un clusterrolebinding RBAC Kubernetes mappa un clusterrole a un utente o a un gruppo, concedendo le autorizzazioni di tale clusterrole all'utente o al gruppo nell'intero cluster.

Vedere Informazioni sul controllo dell'accesso e sul motore Kubernetes (OKE).

Best Practice: utilizzare gli spazi di nomi se più cluster non sono un'opzione

Si consiglia di creare spazi di nomi separati per ogni team se un cluster Kubernetes è di grandi dimensioni (con centinaia di nodi) e vi sono più team che lavorano sul cluster. Ad esempio, in genere si creano spazi di nomi diversi per i team di sviluppo, test e produzione.

Un cluster Kubernetes può essere organizzato in spazi dei nomi per dividere le risorse del cluster tra più utenti. Inizialmente, un cluster dispone dei seguenti spazi di nomi:

• predefinito per le risorse senza altri spazi di nomi
• kube-system, per le risorse create dal sistema Kubernetes
• kube-node-lease, per un oggetto di leasing per nodo per determinare la disponibilità del nodo
• kube-pubblico, di solito utilizzato per le risorse che devono essere accessibili in tutto il cluster

Gli spazi di nomi svolgono un ruolo importante nel mantenere un cluster sicuro quando più utenti e team lavorano sullo stesso cluster.

Vedere Spazi di nomi nella documentazione di Kubernetes.

Best Practice: utilizzare una convenzione di denominazione dello spazio di nomi per semplificare la distribuzione in più ambienti

Si consiglia di stabilire e utilizzare una convenzione di denominazione dello spazio di nomi che semplifichi la creazione di distribuzioni in più ambienti e in hosting in cluster diversi.

Ad esempio, evitare di includere i nomi degli ambienti nei nomi degli spazi di nomi. In alternativa, utilizzare lo stesso nome dello spazio di nomi in tutti gli ambienti. Utilizzando lo stesso nome dello spazio di nomi, è possibile utilizzare gli stessi file di configurazione in tutti gli ambienti ed evitare di dover creare un file di configurazione specifico per ogni ambiente.

Vedere Spazi di nomi nella documentazione di Kubernetes.

Best Practice: isola i carichi di lavoro nei pool di nodi dedicati

Si consiglia di implementare un forte isolamento dell'infrastruttura utilizzando pool di nodi dedicati per isolare i tenant. Ad esempio, per un'applicazione multi-tenant che esegue ogni tenant su una risorsa di computazione dedicata, separata da pool di nodi.

Molte applicazioni SaaS multi-tenant richiedono l'esecuzione dei tenant su risorse di computazione dedicate e richiedono la possibilità di controllare il traffico di rete tramite liste di sicurezza per tenant. Le due strategie più comuni per un modello di tenancy dell'applicazione SaaS di questo tipo sono le seguenti:

• Sfrutta gli spazi di nomi e i criteri di rete per isolare i tenant.
• Utilizza elenchi di calcolo/sicurezza dedicati per isolare i tenant.

Best Practice: applica le quote delle risorse

Si consiglia di creare e applicare le quote delle risorse Kubernetes per garantire che tutti i tenant che condividono un cluster dispongano di un accesso equo alle risorse del cluster.

Crea una quota di risorse per ogni spazio di nomi, in base al numero di pod distribuiti da ciascun tenant e alla quantità di memoria e CPU richiesta da ciascun pod.

Ad esempio, la seguente configurazione ResourceQuota:

• consente ai pod nello spazio di nomi tenant-a di richiedere fino a 16 CPU e fino a 64 GB di memoria
• limita il numero massimo di CPU a 32 e la memoria massima a 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

Vedere Quota risorse nella documentazione di Kubernetes.

Best Practice: scalabilità automatica di nodi di lavoro e pod

Si consiglia di abilitare il ridimensionamento automatico per soddisfare la domanda dei tenant ridimensionando automaticamente i pool di nodi e i pod in un cluster.

Il ridimensionamento automatico garantisce che il sistema continui a apparire reattivo e in buono stato, anche quando tenant diversi distribuiscono carichi di lavoro pesanti nei propri spazi di nomi. Il ridimensionamento automatico consente inoltre al sistema di rispondere alle interruzioni.

Vedere Uso di Kubernetes Cluster Autoscaler, Uso di Kubernetes Horizontal Pod Autoscaler.

Best practice: utilizza un load balancer flessibile

Ti consigliamo di specificare una forma flessibile per i load balancer di Oracle Cloud Infrastructure per soddisfare la domanda dei tenant.

L'utilizzo di una forma flessibile per i load balancer OCI di cui Kubernetes Engine esegue il provisioning per i servizi Kubernetes di tipo LoadBalancer consente di:

• Evitare le limitazioni associate alle forme del load balancer a larghezza di banda fissa perché è possibile specificare valori minimi e massimi per creare un intervallo di dimensioni superiore e inferiore per la forma della larghezza di banda del load balancer.
• Evita le limitazioni associate al ridimensionamento in base solo a modelli di traffico generali.

Vedere Specifica delle forme flessibili del load balancer.

Best Practice: Centralizzare il controllo di rete (facoltativo)

Si consiglia di mantenere il controllo centralizzato sulle risorse di rete utilizzando un gateway di instradamento dinamico (DRG) e (facoltativamente) una VCN hub.

L'uso di un DRG consente di instradare il traffico attraverso un'appliance virtuale di rete centralizzata.

Facoltativamente, la creazione di una VCN hub consente di configurare l'instradamento principale e i firewall. Le risorse in una VCN hub possono comunicare con altre VCN in modo sicuro ed efficiente utilizzando gli IP interni. L'uso di una VCN e di una IAM hub garantisce che solo gli amministratori di rete abbiano accesso alla VCN centralizzata. Questa separazione consente di implementare il principio di privilegio minimo.

Ad esempio:

• Il team di rete centralizzato può amministrare la rete senza avere alcuna autorizzazione per accedere ai cluster Kubernetes (che risiedono in VCN spoke).
• Gli amministratori del motore Kubernetes possono gestire i cluster senza disporre di autorizzazioni per manipolare la rete condivisa.

Vedere Instradamento del traffico tramite un'appliance virtuale di rete centrale.