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 dei progetti di deployment dei workload siano consigliati, non è obbligatorio seguirli esattamente come descritto. Ogni universo GDC ha requisiti e considerazioni unici che devono essere soddisfatti caso per caso.
Questo documento è destinato agli amministratori IT del gruppo di amministratori della piattaforma responsabili della gestione delle risorse all'interno della propria organizzazione e agli sviluppatori di applicazioni del gruppo di operatori delle applicazioni responsabili dello sviluppo e della manutenzione delle applicazioni in un universo GDC.
Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC air-gapped.
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. Il seguente diagramma illustra la separazione dei carichi di lavoro all'interno del livello del data plane della tua organizzazione.
I carichi di lavoro basati su VM operano all'interno di una VM. Al contrario, i carichi di lavoro dei container operano all'interno di un cluster Kubernetes. La separazione fondamentale tra VM e cluster Kubernetes fornisce limiti di isolamento tra i carichi di lavoro delle VM e i carichi di lavoro dei container. Per saperne di più, consulta Gerarchia delle risorse.
Le sezioni seguenti introducono le differenze tra ogni tipo di carico di lavoro e il relativo ciclo di vita del deployment.
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ò avere molti workload 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.
Carichi di lavoro basati su container
Puoi eseguire il deployment dei carichi di lavoro 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.
I cluster Kubernetes possono essere collegati a uno o più progetti, ma non sono una risorsa secondaria di un progetto. Questa è una differenza fondamentale tra i cluster Kubernetes e le VM. Una VM è una risorsa secondaria di un progetto, mentre i cluster Kubernetes funzionano come risorsa secondaria di un'organizzazione, il che consente loro di essere collegati a più progetti.
Per la pianificazione dei pod all'interno di un cluster Kubernetes, GDC adotta i concetti generali di Kubernetes di pianificazione, preemptive scheduling ed eliminazione. 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. Per ulteriori informazioni sulla gestione dei container in un cluster Kubernetes, consulta Workload dei container in GDC.
Best practice per la progettazione di cluster Kubernetes
Questa sezione introduce le best practice per la progettazione di cluster Kubernetes:
- Crea cluster separati per ambiente di sviluppo software
- Crea cluster più grandi e in numero inferiore
- Crea meno node pool più grandi all'interno di un cluster
Prendi in considerazione ogni best practice per progettare un cluster resiliente per il ciclo di vita del carico di lavoro 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 due ambienti di sviluppo software denominati development e production, puoi creare un insieme separato di cluster Kubernetes per ogni ambiente e collegare i progetti a ogni cluster in base alle tue esigenze. Consigliamo di collegare più progetti ai cluster Kubernetes nei cicli di vita di pre-produzione e produzione.
I cluster definiti per ogni ambiente di sviluppo software presuppongono che i carichi di lavoro all'interno di un ambiente di sviluppo software possano condividere i cluster. Poi assegna i progetti al cluster Kubernetes dell'ambiente appropriato. Un cluster Kubernetes può essere ulteriormente suddiviso in più node pool o utilizzare incompatibilità per l'isolamento dei workload.
Se separi i cluster Kubernetes in base all'ambiente di sviluppo software, puoi isolare il consumo di risorse, i criteri 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 a progetti, cluster, ambienti di sviluppo software e classi di macchine.
Questa architettura di esempio presuppone che i workload all'interno di un ambiente di sviluppo software di produzione e sviluppo possano condividere i cluster. Ogni ambiente ha un insieme separato di cluster Kubernetes, ulteriormente suddivisi in più node pool per diversi requisiti di classe di macchine.
In alternativa, la progettazione di più cluster Kubernetes è utile per le operazioni con i container, come nei 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 la normativa di backup, quindi crei più cluster con configurazioni diverse.
- Esegui copie di un cluster in parallelo per facilitare gli upgrade di versione 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.
Il seguente diagramma mostra un esempio in cui sono configurati più cluster per ambiente di sviluppo software a causa di requisiti come le operazioni del 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 sviluppo software 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 carichi di lavoro 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.
Passaggi successivi
- Gerarchia delle risorse
- Crea un'app containerizzata ad alta disponibilità
- Crea un'app VM a disponibilità elevata