Questo documento fornisce una panoramica della gestione dei carichi di lavoro in Google Distributed Cloud (GDC) con air gap. Vengono trattati i seguenti argomenti:
Sebbene alcuni progetti di deployment del carico di lavoro siano consigliati, non è obbligatorio seguirli esattamente come prescritto. Ogni universo GDC ha requisiti e considerazioni unici che devono essere soddisfatti caso per caso.
Dove eseguire il deployment dei carichi di lavoro
Sulla piattaforma GDC, le operazioni per il deployment dei carichi di lavoro delle macchine virtuali (VM) e dei carichi di lavoro dei container sono diverse. Questa sezione introduce le differenze e il punto in cui viene eseguito il deployment di ogni risorsa.
Carichi di lavoro basati su VM
Puoi creare VM per ospitare i carichi di lavoro basati su VM. Hai a disposizione molte opzioni di configurazione per la forma e le dimensioni della tua VM, in modo da soddisfare al meglio i requisiti del carico di lavoro basato sulla VM. Devi creare una VM in un progetto, che può contenere molte VM e carichi di lavoro VM. 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.
Carichi di lavoro basati su container
Puoi eseguire il deployment dei carichi di lavoro basati su container in un pod su un cluster Kubernetes. I cluster Kubernetes possono essere collegati a uno o più progetti, ma non sono una risorsa secondaria di un progetto. Ti consigliamo di collegare i cluster solo ai progetti nell'ambiente di deployment appropriato. Ad esempio, un cluster per i workload di produzione è collegato a un progetto per i workload di produzione.
Per la pianificazione dei pod all'interno di un cluster Kubernetes, GDC adotta i concetti generali di Kubernetes di pianificazione, preemption ed espulsione. Le best practice per la pianificazione dei pod all'interno di un cluster variano in base ai requisiti del tuo carico di lavoro.
Per ulteriori informazioni sui cluster Kubernetes, consulta la panoramica dei cluster Kubernetes. Consulta la panoramica dei carichi di lavoro dei container per informazioni dettagliate sulla gestione dei container in un cluster Kubernetes.
Best practice per la progettazione di cluster Kubernetes
Questa sezione introduce le best practice per la progettazione di cluster Kubernetes:
- Creare cluster separati per ambiente di deployment
- Crea cluster più grandi e in numero inferiore
- Crea meno node pool più grandi all'interno di un cluster
Crea cluster separati per ambiente di deployment
Oltre a progetti separati per ambiente di deployment, ti consigliamo di progettare cluster Kubernetes separati per ambiente di deployment. Separando sia il cluster Kubernetes sia il progetto per ambiente, isoli il consumo di risorse, le norme di accesso, gli eventi di manutenzione e le modifiche alla configurazione a livello di cluster tra i carichi di lavoro di produzione e non di produzione.
Il seguente diagramma mostra un progetto di cluster Kubernetes di esempio per più carichi di lavoro che si estendono su progetti, cluster, ambienti di deployment e classi di macchine.
Questa architettura di esempio presuppone che i carichi di lavoro all'interno di un ambiente di deployment possano condividere i cluster. Ogni ambiente di deployment ha un insieme separato di cluster Kubernetes. Poi assegni i progetti al cluster Kubernetes dell'ambiente di deployment appropriato. Un cluster Kubernetes può essere ulteriormente suddiviso in più node pool per diversi requisiti di classe di macchine.
In alternativa, la progettazione di più cluster Kubernetes è utile per operazioni con i container come i seguenti scenari:
- Alcuni carichi di lavoro sono bloccati su una versione specifica di Kubernetes, quindi mantieni cluster diversi a versioni diverse.
- Hai alcuni carichi di lavoro che richiedono configurazioni del cluster diverse, ad esempio le norme di backup, quindi crei più cluster con configurazioni diverse.
- Esegui copie di un cluster in parallelo per facilitare gli upgrade di versione distruttivi o una strategia di deployment blu/verde.
- Crei un carico di lavoro sperimentale che rischia di limitare il server API o altri single point of failure all'interno di un cluster, quindi lo isoli dai carichi di lavoro esistenti.
Il seguente diagramma mostra un esempio in cui sono configurati più cluster per ambiente di deployment a causa di requisiti come le operazioni sui container descritte nella sezione precedente.
Crea meno cluster
Per un utilizzo efficiente delle risorse, ti consigliamo di progettare il minor numero di cluster Kubernetes che soddisfino i tuoi requisiti per la separazione degli ambienti di deployment e delle operazioni sui container. Ogni cluster aggiuntivo comporta un consumo di risorse di overhead aggiuntivo, ad esempio i nodi del control plane aggiuntivi richiesti. Pertanto, un cluster più grande con molti workload utilizza le risorse di calcolo sottostanti in modo più efficiente rispetto a molti cluster piccoli.
Quando ci sono più cluster con configurazioni simili, si crea un sovraccarico di manutenzione aggiuntivo per monitorare la capacità del cluster e pianificare le dipendenze tra cluster.
Se un cluster si sta avvicinando alla capacità massima, ti consigliamo di aggiungere altri nodi a un cluster anziché crearne uno nuovo.
Crea meno node pool all'interno di un cluster
Per un utilizzo efficiente delle risorse, ti consigliamo di progettare pool di nodi più grandi e in numero inferiore all'interno di un cluster Kubernetes.
La configurazione di più pool di nodi è utile quando devi pianificare pod che richiedono una classe di macchine diversa dalle altre. 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.