I modelli di deployment di Google Distributed Cloud ti consentono di personalizzare l'infrastruttura in base a requisiti specifici di disponibilità, isolamento e utilizzo delle risorse. Per implementare il modello di deployment che meglio supporta le tue esigenze operative, puoi scegliere tra quattro tipi di cluster: amministratore, utente, ibrido o autonomo.
Cluster utenti
Un cluster utente è un cluster Kubernetes che esegue i tuoi workload containerizzati. È costituito 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 workload 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
- Elimina i cluster utente
Per creare un cluster utente, il cluster di amministrazione configura i componenti di Google Distributed Cloud sul control plane 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 cluster di amministrazione contiene i seguenti tipi di dati sensibili:
- Credenziali SSH: utilizzate per attivare l'installazione remota
- Chiavi dei service accountGoogle Cloud : utilizzate per accedere a funzionalità come Artifact Registry
Per proteggere i dati sensibili, limita l'accesso al cluster di amministrazione.
Alta affidabilità
Puoi eseguire i cluster di amministrazione o utente in modalità ad alta affidabilità (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 nel caso in cui un nodo worker non funzioni.
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 dei cluster utente e di amministrazione
- Deployment di cluster ibridi
- Deployment di cluster autonomi
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 workload di sviluppo e di 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 workload 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 i diversi team.
- Fornisce l'isolamento tra i workload di sviluppo e di produzione.
- Non è necessario condividere le credenziali SSH e le chiavi dei account di servizio con i proprietari dei cluster.
- Puoi integrare il tuo deployment con i tuoi control plane
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 non-HA
- Tre o più nodi del control plane per l'alta affidabilità
Cluster utente: puoi configurare l'HA per ogni cluster utente in modo indipendente.
Nodi del control plane:
- Un nodo del control plane per non-HA
- Tre o più nodi del control plane per l'alta affidabilità
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 multi-cluster specializzato. Un cluster ibrido è un cluster di amministrazione che può eseguire workload utente. Il tuo 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 del cluster ibrido consente di recuperare la capacità inutilizzata su queste macchine perché permette 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 dei 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, il che potrebbe esporre i dati sensibili del cluster di amministrazione ai workload utente.
Impronta
Il deployment di un cluster ibrido richiede i seguenti nodi:
Cluster ibrido
Nodi del control plane:
- Un nodo del control plane per non-HA
- Tre o più nodi del control plane per l'alta affidabilità
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'HA per ogni cluster utente in modo indipendente.
Nodi del control plane:
- Un nodo del control plane per non-HA
- Tre o più nodi del control plane per l'alta affidabilità
Nodi worker:
- Uno o più nodi worker per non-HA
- Due o più nodi worker per l'alta affidabilità
Deployment di cluster autonomo
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 perimetrale, che ha requisiti di risorse di sistema notevolmente ridotti ed è consigliato per i dispositivi edge con vincoli di risorse elevati.
Questo modello presenta alcuni compromessi in termini di sicurezza, perché i workload possono essere eseguiti su un cluster con i seguenti dati sensibili:
- Credenziali SSH
- Chiavi service account:Google Cloud
Utilizza questo modello se soddisfi una delle seguenti condizioni:
- Gestisci ogni cluster in modo indipendente.
- Hai un numero ridotto di nodi worker.
- Sostieni una sola squadra.
- Esegui un singolo tipo di workload.
Questo modello funziona bene nelle seguenti situazioni:
- Ogni cluster è gestito in modo indipendente con chiavi SSH e credenzialiGoogle Cloud diverse
- I cluster vengono eseguiti in partizioni di rete isolate, separate da reti non attendibili
- I cluster vengono eseguiti in località perimetrali
Impronta
Il deployment di un cluster autonomo richiede i seguenti nodi:
Nodi del control plane:
- Un nodo del control plane per non-HA
- Tre o più nodi del control plane per l'alta affidabilità
Nodi worker:
- Uno o più nodi worker per non-HA
- Due o più nodi worker per l'alta affidabilità
Profilo perimetrale
I cluster autonomi supportano un profilo perimetrale, che riduce al minimo il consumo di risorse per il cluster. Puoi attivare il profilo perimetrale quando crei un cluster autonomo impostando profile nel file di configurazione del cluster su edge. Il profilo perimetrale è consigliato per i dispositivi edge con vincoli di risorse restrittivi. Per i requisiti hardware associati al profilo perimetrale, consulta Requisiti delle risorse per i cluster autonomi che utilizzano il profilo perimetrale.
In un cluster autonomo configurato per l'utilizzo del profilo perimetrale, 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'impatto mediante l'esecuzione dei workload sul control plane indebolisce la sicurezza e l'isolamento delle risorse tra il control plane e il piano dati. Se l'impatto ridotto vale questo compromesso, puoi configurare un cluster autonomo con il profilo perimetrale da eseguire su un singolo nodo del control plane o su più nodi del control plane per l'alta affidabilità.