Progettare la separazione dei workload

L'isolamento dei workload in Google Distributed Cloud (GDC) con air gap consente di separare le applicazioni container e di macchine virtuali (VM) tra progetti e cluster Kubernetes. La pianificazione dei confini dell'ambiente ti aiuta a controllare le policy di accesso, contenere l'impatto della manutenzione e ottimizzare la capacità dei nodi. Puoi adattare questi pattern di architettura per soddisfare i requisiti specifici di ogni universo GDC.

Questo documento è rivolto al personale IT del gruppo di amministratori della piattaforma che gestisce le risorse dell'organizzazione e agli sviluppatori del gruppo di operatori delle applicazioni che gestiscono i servizi. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC con air gap.

Dove eseguire il deployment dei workload

Sulla piattaforma GDC, le operazioni per il deployment dei workload delle macchine virtuali (VM) e dei workload dei container sono diverse. Il seguente diagramma illustra la separazione dei workload all'interno del livello del piano dati della tua organizzazione.

Separazione dei workload nel piano dati dell'organizzazione.

I workload basati su VM operano all'interno di una VM. Al contrario, i workload dei container operano all'interno di un cluster Kubernetes. La separazione fondamentale tra VM e cluster Kubernetes fornisce confini di isolamento tra i workload delle VM e i workload dei container. Per saperne di più, consulta Gerarchia delle risorse.

Le sezioni seguenti presentano le differenze tra ciascun tipo di workload e il relativo ciclo di vita del deployment.

Workload basati su VM

Puoi creare VM per ospitare i tuoi workload basati su VM. Hai molte opzioni di configurazione per la forma e le dimensioni della VM, per soddisfare al meglio i requisiti del workload basato su VM. Devi creare una VM in un progetto, che può avere molti workload delle VM. Le VM sono una risorsa secondaria di un progetto. Per ulteriori informazioni, consulta la panoramica delle VM.

I progetti che contengono solo workload basati su VM non richiedono un cluster Kubernetes. Pertanto, non è necessario eseguire il provisioning dei cluster Kubernetes per i workload basati su VM.

Workload basati su container

Puoi eseguire il deployment di workload basati su container in un pod su un cluster Kubernetes. Un cluster Kubernetes è costituito dai seguenti tipi di nodi:

  • Nodo del control plane: esegue i servizi di gestione, come la pianificazione, etcd e un server API.

  • Nodo worker: esegue i pod e le applicazioni containerizzate.

Architettura dei cluster Kubernetes

Esistono due tipi di configurazione per i cluster Kubernetes:

  • Cluster condivisi: un cluster Kubernetes con ambito a livello di organizzazione che può estendersi su più progetti e non è gestito da un singolo progetto, ma è collegato ai progetti.
  • Cluster standard: un cluster Kubernetes con ambito a livello di progetto che gestisce le risorse del cluster all'interno di un progetto e non può estendersi su più progetti.

Per saperne di più, consulta Configurazioni dei cluster Kubernetes.

I cluster Kubernetes offrono varie opzioni di gerarchia delle risorse, poiché i cluster condivisi hanno come ambito l'organizzazione e i cluster standard hanno come ambito il progetto. Questa è una differenza fondamentale tra i cluster Kubernetes e le VM. Una VM è una risorsa secondaria di un progetto e non può essere configurata per funzionare al di fuori di un progetto. Per ulteriori informazioni su come progettare l'infrastruttura del cluster Kubernetes, consulta Best practice per la progettazione di cluster Kubernetes.

Per la pianificazione dei pod all'interno di un cluster Kubernetes, GDC adotta i concetti generali di Kubernetes di pianificazione, prerilascio ed espulsione. Le best practice per la pianificazione dei pod all'interno di un cluster variano in base ai requisiti del tuo workload.

Per ulteriori informazioni sui cluster Kubernetes, consulta la panoramica dei cluster Kubernetes. Per saperne di più sulla gestione dei container in un cluster Kubernetes, consulta Workload dei container in GDC.

Best practice per la progettazione di cluster Kubernetes

Questa sezione presenta le best practice per la progettazione di cluster Kubernetes:

Prendi in considerazione ogni best practice per progettare un cluster resiliente per il ciclo di vita del workload dei container.

Crea cluster separati per ambiente di sviluppo software

Oltre a progetti separati per ambiente di sviluppo software, ti consigliamo di progettare cluster Kubernetes separati per ambiente di sviluppo software. Un ambiente di sviluppo software è un'area all'interno del tuo universo GDC destinata a tutte le operazioni che corrispondono a una fase del ciclo di vita designata. Ad esempio, se nella tua organizzazione hai tre ambienti di sviluppo software denominati development, staging e production, puoi creare un set separato di cluster Kubernetes per ogni ambiente e collegare i progetti a ogni cluster in base alle tue esigenze.

Ti consigliamo di utilizzare i cluster standard nei cicli di vita di pre-produzione con ambito limitato a un singolo progetto, in modo da isolare dai progetti di produzione eventuali processi distruttivi correlati ai test, mentre i cluster condivisi sono ideali per gli ambienti di produzione che possono estendersi su più progetti. Un cluster condiviso che ospita workload di produzione che si estendono su più progetti fornisce un'area di deployment condivisa in cui i cluster standard con ambito limitato a un singolo progetto possono promuovere i propri workload direttamente nell'ambiente di produzione.

I cluster standard definiti per ogni ambiente di sviluppo software presuppongono che i workload di pre-produzione all'interno di un ambiente di sviluppo software siano limitati a quel cluster. Un cluster Kubernetes potrebbe essere ulteriormente suddiviso in più pool di nodi o utilizzare incompatibilità per l'isolamento dei workload.

Separando i cluster Kubernetes per ambiente di sviluppo software, isoli il consumo di risorse, le policy di accesso, gli eventi di manutenzione e le modifiche alla configurazione a livello di cluster tra i workload di produzione e non di produzione.

Il seguente diagramma mostra un esempio di progettazione di un cluster Kubernetes per più workload che si estendono su progetti, cluster, ambienti di sviluppo software e classi di macchine forniti da pool di nodi diversi.

Configurazione del cluster GDC che si estende su più ambienti di sviluppo software.

Questa architettura di esempio presuppone che i workload negli ambienti di sviluppo software, gestione temporanea e produzione possano condividere i cluster. Ogni ambiente ha un cluster standard separato, che viene ulteriormente suddiviso in più pool di nodi per i diversi requisiti delle classi di macchine. Il cluster condiviso comprende tutti gli ambienti di sviluppo software, fornendo un'area di deployment comune per tutti gli ambienti.

In alternativa, la progettazione di più cluster standard per ambiente di sviluppo software è utile per le operazioni sui container, come nei seguenti scenari:

  • Hai alcuni workload bloccati su una versione specifica di Kubernetes, quindi mantieni cluster diversi con versioni diverse.
  • Hai alcuni workload che richiedono esigenze di configurazione del cluster diverse, come la policy di backup, quindi crei più cluster con configurazioni diverse.
  • Esegui copie di un cluster in parallelo per facilitare gli upgrade di versione invasivi o una strategia di deployment blu/verde.
  • Crei un workload sperimentale che rischia di limitare il server API o altri single point of failure all'interno di un cluster, quindi lo isoli dai workload esistenti.

Devi adattare gli ambienti di sviluppo software ai requisiti stabiliti dalle operazioni dei container.

Crea meno cluster

Per un utilizzo efficiente delle risorse, ti consigliamo di progettare il minor numero di cluster Kubernetes che soddisfano i tuoi requisiti per la separazione degli ambienti di sviluppo software e delle operazioni dei container. Ogni cluster aggiuntivo comporta un consumo aggiuntivo di risorse di overhead, ad esempio i nodi del control plane aggiuntivi richiesti. Pertanto, un cluster più grande con molti workload utilizza le risorse di computing sottostanti in modo più efficiente rispetto a molti cluster di piccole dimensioni.

Quando sono presenti più cluster con configurazioni simili, si crea un overhead di manutenzione aggiuntivo per monitorare la capacità del cluster e pianificare le dipendenze tra cluster.

Se un cluster sta per raggiungere la capacità massima, ti consigliamo di aggiungere altri nodi al cluster anziché crearne uno nuovo.

Crea meno pool di nodi all'interno di un cluster

Per un utilizzo efficiente delle risorse, ti consigliamo di progettare un numero inferiore di pool di nodi più grandi all'interno di un cluster Kubernetes.

La configurazione di più pool di nodi è utile quando devi pianificare pod che richiedono una classe di macchina diversa rispetto ad altri. Crea un pool di nodi per ogni classe di macchina richiesta dai tuoi workload e imposta la capacità dei nodi sulla scalabilità automatica per consentire un utilizzo efficiente delle risorse di computing.

Passaggi successivi