Google Distributed Cloud supporta più modelli di deployment per soddisfare diverse esigenze di disponibilità, isolamento e utilizzo delle risorse. Questa pagina definisce i concetti condivisi da tutti i modelli di deployment e descrive ogni modello di deployment.
Questa pagina è rivolta ad amministratori, architetti e operatori che definiscono soluzioni IT e architetture di sistema in linea con la strategia aziendale in coordinamento con i principali stakeholder. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta la pagina Ruoli e attività comuni degli utenti GKE.
Cluster utenti
Un cluster utente è un cluster Kubernetes che esegue i tuoi carichi di lavoro containerizzati. È composto da nodi del control plane e nodi worker. Google Distributed Cloud supporta uno o più cluster utente. I cluster utente devono contenere uno o più nodi worker che eseguono i carichi di lavoro utente.
Cluster di amministrazione
Un cluster di amministrazione è un cluster Kubernetes che gestisce uno o più cluster utente. Il cluster di amministrazione può eseguire le seguenti attività:
- Creazione di cluster utente
- Esegui l'upgrade dei cluster utente
- Aggiorna i cluster utente
- Eliminare i cluster utente
Per creare un cluster utente, il cluster di amministrazione configura i componenti di Google Distributed Cloud sui nodi del piano di controllo e sui nodi worker del cluster utente. Il cluster di amministrazione ha solo nodi del control plane perché i componenti di Google Distributed Cloud vengono eseguiti sui nodi del control plane.
Il tuo cluster amministrativo contiene i seguenti tipi di dati sensibili:
- Credenziali SSH: utilizzate per abilitare l'installazione remota
- Google Cloud Chiavi del service account: utilizzate per accedere a funzionalità come Artifact Registry
Per proteggere i dati sensibili, limita l'accesso al cluster di amministrazione.
Alta disponibilità
Puoi eseguire cluster di amministrazione o utente in modalità ad alta disponibilità (HA). Questa modalità richiede tre o più (numero dispari) nodi del control plane in esecuzione nel cluster. Se esegui un cluster in modalità non ad alta disponibilità, il cluster richiede un solo nodo del control plane.
Per evitare di avere un single point of failure, utilizza la modalità ad alta disponibilità per i deployment di produzione. Utilizza la modalità non ad alta disponibilità per ambienti non mission critical, ad esempio un ambiente di test in cui puoi ricreare il cluster in caso di errore del nodo del control plane singolo. Un cluster utente ad alta disponibilità deve avere due o più nodi worker in caso di errore di un nodo worker.
Quando esegui l'upgrade dei cluster, un deployment ad alta disponibilità riduce anche il rischio che il cluster diventi inaccessibile in caso di errore.
Modelli di deployment
Google Distributed Cloud supporta i seguenti modelli di deployment per soddisfare requisiti diversi:
- Implementazione di cluster amministrativi e utente
- Deployment del cluster ibrido
- Deployment del cluster autonomo
Deployment dei cluster di amministrazione e utente
Utilizza questo modello di deployment se hai più cluster nello stesso data center che vuoi gestire da una posizione centralizzata e per deployment più grandi che richiedono l'isolamento tra team diversi o tra carichi di lavoro di sviluppo e produzione.
Questo modello di deployment è costituito dai seguenti cluster:
- Un cluster di amministrazione: il punto di gestione centrale che fornisce un'API per gestire i cluster utente. Il cluster di amministrazione esegue solo i componenti di gestione.
- Uno o più cluster utente: contengono i nodi del control plane e i nodi worker, che eseguono i carichi di lavoro degli utenti.
Questo modello soddisfa i seguenti requisiti:
- Fornisce un control plane e un'API centralizzati per gestire i cicli di vita dei cluster utente.
- Fornisce l'isolamento tra team diversi.
- Fornisce l'isolamento tra i carichi di lavoro di sviluppo e produzione.
- Non devi condividere le credenziali SSH e le chiavi del account di servizio con i proprietari del cluster.
- Puoi integrare il deployment con i tuoi piani di controllo
Impronta
Il deployment di un cluster di amministrazione e di un cluster utente richiede i seguenti nodi:
Cluster di amministrazione
- Un nodo del control plane per la modalità non ad alta disponibilità
- Tre o più nodi del control plane per l'alta disponibilità
Cluster utente: puoi configurare l'alta disponibilità per ogni cluster utente in modo indipendente.
Nodi del control plane:
- Un nodo del control plane per la modalità non ad alta disponibilità
- Tre o più nodi del control plane per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per non HA
- Due o più nodi worker per l'alta affidabilità
Deployment di cluster ibridi
Questo modello di deployment è un deployment multicluster specializzato. Un cluster ibrido è un cluster di amministrazione che può eseguire carichi di lavoro utente. Il tuo cluster ibrido gestisce ancora cluster utente aggiuntivi.
Caratteristiche di questo modello:
- L'allocazione di un insieme di macchine per un cluster di amministrazione è spesso uno spreco perché i cluster di amministrazione utilizzano relativamente poche risorse. Il deployment del cluster ibrido consente di recuperare la capacità inutilizzata su queste macchine perché consente di eseguire i workload utente all'interno del cluster di amministrazione.
- Il cluster di amministrazione contiene dati sensibili come le credenziali SSH (utilizzate dal cluster di amministrazione per gestire i cluster utente su macchine remote) e le chiavi del service accountGoogle Cloud (utilizzate dal cluster di amministrazione per accedere ai serviziGoogle Cloud come Cloud Storage). I deployment di cluster ibridi eseguono i workload utente all'interno del cluster di amministrazione e ciò espone potenzialmente i dati sensibili del cluster di amministrazione ai workload utente.
Impronta
Un deployment di cluster ibrido richiede i seguenti nodi:
Cluster ibrido
Nodi del control plane:
- Un nodo del control plane per la modalità non ad alta disponibilità
- Tre o più nodi del control plane per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per non HA
- Due o più nodi worker per l'alta affidabilità e a seconda del tipo di workload
Cluster utente: puoi configurare l'alta disponibilità per ogni cluster utente in modo indipendente.
Nodi del control plane:
- Un nodo del control plane per la modalità non ad alta disponibilità
- Tre o più nodi del control plane per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per non HA
- Due o più nodi worker per l'alta affidabilità
Deployment di cluster autonomi
Questo modello di deployment ha un singolo cluster che funge da cluster utente e da cluster di amministrazione.
Questo modello presenta i seguenti vantaggi:
- Non richiede un cluster di amministrazione separato
- Supporta il profilo edge, che presenta esigenze notevolmente ridotte in termini di risorse di sistema ed è consigliato per i dispositivi edge con vincoli di risorse particolarmente restrittivi.
Questo modello presenta alcuni compromessi in termini di sicurezza, perché i carichi di lavoro possono essere eseguiti su un cluster con i seguenti dati sensibili:
- Credenziali SSH
- Chiavi service accountGoogle Cloud
Utilizza questo modello se soddisfi una delle seguenti condizioni:
- Gestisci ogni cluster in modo indipendente.
- Hai un numero ridotto di nodi worker.
- Supporti un solo team.
- Esegui un solo tipo di workload.
Questo modello funziona bene nelle seguenti situazioni:
- Ogni cluster viene gestito in modo indipendente con credenziali e chiavi SSH diverse.Google Cloud
- I cluster vengono eseguiti in partizioni isolate dalla rete, separate da reti non attendibili
- I cluster vengono eseguiti in località perimetrali
Impronta
Un deployment del cluster autonomo richiede i seguenti nodi:
Nodi del control plane:
- Un nodo del control plane per la modalità non ad alta disponibilità
- Tre o più nodi del control plane per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per non HA
- Due o più nodi worker per l'alta affidabilità
Profilo del bordo
I cluster autonomi supportano un profilo edge, che riduce al minimo il consumo di risorse
per il cluster. Abiliti il profilo edge quando crei un cluster autonomo impostando profile nel file di configurazione del cluster su edge. Il profilo perimetrale è consigliato per i dispositivi periferici
con vincoli di risorse restrittivi. Per i requisiti hardware associati
al profilo edge, consulta
Requisiti delle risorse per i cluster autonomi che utilizzano il profilo edge.
In un cluster autonomo configurato per utilizzare il profilo edge, i nodi del control plane vengono configurati automaticamente per accettare i workload utente. Ciò significa che non hai bisogno di un pool di nodi worker. Tuttavia, la riduzione dell'impronta eseguendo i carichi di lavoro sul control plane indebolisce la sicurezza e l'isolamento delle risorse tra il control plane e il data plane. Se l'ingombro ridotto vale questo compromesso, puoi configurare un cluster autonomo con il profilo edge da eseguire su un singolo nodo del control plane o su più nodi del control plane per l'alta disponibilità.