Google Distributed Cloud supporta più modelli di deployment per soddisfare le 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 base alla strategia aziendale in coordinamento con i principali stakeholder. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti di GKE. Google Cloud
Cluster utenti
Un cluster utente è un cluster Kubernetes che esegue i 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 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 di cluster utente
- Aggiorna i cluster utente
- Elimina 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 worker del cluster utente. Il cluster di amministrazione ha solo nodi del piano di controllo perché i componenti di Google Distributed Cloud vengono eseguiti sui nodi del piano di controllo.
Il cluster di amministrazione contiene i seguenti tipi di dati sensibili:
- Credenziali SSH: utilizzate per abilitare l'installazione remota
- Google Cloud Chiavi degli account di servizio: utilizzate per accedere a funzionalità come Artifact Registry
Per proteggere i dati sensibili, limita l'accesso al cluster di amministrazione.
Alta affidabilità
Puoi eseguire cluster di amministrazione o utente in alta disponibilità (HA) modalità. Questa modalità richiede tre o più (numero dispari) nodi del piano di controllo in esecuzione nel cluster. Se esegui un cluster in modalità non ad alta disponibilità, il cluster richiede un solo nodo del piano di controllo.
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 piano di controllo 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:
- Deployment di cluster di amministrazione e utente
- Deployment di cluster ibridi
- Deployment di cluster autonomi
Deployment di 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 è composto 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 piano di controllo e i nodi worker, che eseguono i carichi di lavoro utente.
Questo modello soddisfa i seguenti requisiti:
- Fornisce un piano di controllo 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 dell'account di servizio con i proprietari dei cluster.
- Puoi integrare il deployment con i tuoi piani di controllo
Footprint
Un deployment di cluster di amministrazione e utente richiede i seguenti nodi:
Cluster di amministrazione
- Un nodo del piano di controllo per la non alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Cluster utente: puoi configurare l'alta disponibilità per ogni cluster utente in modo indipendente.
Nodi del piano di controllo:
- Un nodo del piano di controllo per la non alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per la non alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Deployment di cluster ibridi
Questo modello di deployment è un deployment multi-cluster specializzato. Un cluster ibrido è un cluster di amministrazione che può eseguire carichi di lavoro utente. Il cluster ibrido gestisce comunque altri cluster utente.
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 di cluster ibridi consente di recuperare la capacità inutilizzata su queste macchine perché consente di eseguire carichi di lavoro utente all'interno del cluster di amministrazione.
- Il cluster di amministrazione contiene dati sensibili come le credenziali SSH (utilizzate da il cluster di amministrazione per gestire i cluster utente su macchine remote) e Google Cloud le chiavi dell'account di servizio (utilizzate dal cluster di amministrazione per accedere a Google Cloud servizi come Cloud Storage). I deployment di cluster ibridi eseguono i carichi di lavoro utente all'interno del cluster di amministrazione, il che espone potenzialmente i dati sensibili del cluster di amministrazione ai carichi di lavoro utente.
Footprint
Un deployment di cluster ibridi richiede i seguenti nodi:
Cluster ibrido
Nodi del piano di controllo:
- Un nodo del piano di controllo per la non alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per la non alta disponibilità
- Due o più nodi worker per l'alta disponibilità e a seconda del tipo di carico di lavoro
Cluster utente: puoi configurare l'alta disponibilità per ogni cluster utente in modo indipendente.
Nodi del piano di controllo:
- Un nodo del piano di controllo per la non alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per la non alta disponibilità
- Due o più nodi worker per l'alta disponibilità
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 elevati.
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
- Google Cloud Chiavi dell'account di servizio
Utilizza questo modello se soddisfi una delle seguenti condizioni:
- Gestisci ogni cluster in modo indipendente.
- Hai un numero ridotto di nodi worker.
- Supporti un singolo team.
- Esegui un singolo tipo di carico di lavoro.
Questo modello funziona bene nelle seguenti situazioni:
- Ogni cluster viene gestito in modo indipendente con chiavi e credenziali SSH diverse Google Cloud
- I cluster vengono eseguiti in partizioni isolate dalla rete, separate dalle reti non attendibili
- I cluster vengono eseguiti in località edge
Footprint
Un deployment di cluster autonomi richiede i seguenti nodi:
Nodi del piano di controllo:
- Un nodo del piano di controllo per la non alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per la non alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Profilo edge
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 edge è consigliato per i dispositivi edge con vincoli di risorse restrittivi. Per i requisiti hardware associati a
il profilo edge, consulta
Requisiti di risorse per i cluster autonomi che utilizzano il profilo edge.
In un cluster autonomo configurato per utilizzare il profilo edge, i nodi del piano di controllo vengono configurati automaticamente per accettare i carichi di lavoro utente. Ciò significa che non hai bisogno di un pool di nodi worker. Tuttavia, la riduzione del footprint eseguendo i carichi di lavoro sul piano di controllo indebolisce la sicurezza e l'isolamento delle risorse tra il piano di controllo e il piano dati. Se il footprint 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 affidabilità.