GKE su Bare Metal 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.
Cluster utenti
Un cluster utente è un cluster Kubernetes che esegue i carichi di lavoro containerizzati. È costituito da nodi del piano di controllo e nodi worker. GKE su Bare Metal supporta uno o più cluster utente. I cluster utente devono contenere uno o più nodi worker che eseguono carichi di lavoro degli utenti.
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 cluster utente
- Elimina cluster utente
Per creare un cluster utente, il cluster di amministrazione configura i componenti Anthos on bare metal sul piano di controllo e sui nodi worker del cluster utente. Il cluster di amministrazione contiene solo nodi del piano di controllo perché i componenti GKE su Bare Metal vengono eseguiti sui nodi del piano di controllo.
Il cluster di amministrazione contiene i seguenti tipi di dati sensibili:
- Credenziali SSH: utilizzate per attivare l'installazione remota
- Chiavi degli account di servizio Google Cloud: utilizzate per accedere a funzionalità come Container Registry
Per proteggere i dati sensibili, limita l'accesso al cluster di amministrazione.
Alta disponibilità
Puoi eseguire i cluster di amministrazione o utenti in modalità ad alta disponibilità (HA). Questa modalità richiede almeno tre (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
GKE su Bare Metal supporta i seguenti modelli di deployment per soddisfare requisiti diversi:
- Deployment dei cluster di amministrazione e utente
- Deployment del cluster ibrido
- Deployment del cluster autonomo
Deployment dei cluster di amministrazione e utente
Utilizza questo modello di deployment se nello stesso data center sono presenti più cluster 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 piano di controllo e i nodi worker che eseguono i carichi di lavoro degli utenti.
Questo modello soddisfa i seguenti requisiti:
- Fornisce un'API e un piano di controllo centralizzati per gestire i cicli di vita dei cluster utente.
- Fornisce l'isolamento tra team diversi.
- Fornisce l'isolamento tra carichi di lavoro di sviluppo e produzione.
- Non è necessario condividere le credenziali SSH e le chiavi degli account di servizio con i proprietari dei 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 piano di controllo per non ad alta disponibilità
- Tre o più nodi del piano di controllo per 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 non ad alta disponibilità
- Tre o più nodi del piano di controllo per alta disponibilità
Nodi worker:
- Uno o più nodi worker per non ad alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Deployment ibrido del cluster
Questo modello di deployment è un deployment multi-cluster specializzato. Un cluster ibrido è un cluster di amministrazione che può eseguire carichi di lavoro degli utenti. Il cluster ibrido gestisce ancora cluster utente aggiuntivi.
Caratteristiche di questo modello:
- L'allocazione di un set di macchine per un cluster di amministrazione è spesso uno spreco perché i cluster di amministrazione utilizzano risorse relativamente poche. Il deployment del cluster ibrido ti consente di recuperare la capacità inutilizzata su quelle macchine perché ti consente di eseguire i carichi di lavoro degli utenti 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 sulle macchine remote) e le chiavi dell'account di servizio Google Cloud (utilizzate dal cluster di amministrazione per accedere ai servizi Google Cloud come Cloud Storage). I deployment di cluster ibridi eseguono carichi di lavoro degli utenti all'interno del cluster di amministrazione e questo espone potenzialmente i dati sensibili del cluster di amministrazione ai carichi di lavoro degli utenti.
Impronta
Il deployment di un cluster ibrido richiede i seguenti nodi:
Cluster ibrido
Nodi del piano di controllo:
- Un nodo del piano di controllo per non ad alta disponibilità
- Tre o più nodi del piano di controllo per alta disponibilità
Nodi worker:
- Uno o più nodi worker per non ad alta disponibilità
- Due o più nodi worker per l'alta disponibilità e in base al 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 non ad alta disponibilità
- Tre o più nodi del piano di controllo per alta disponibilità
Nodi worker:
- Uno o più nodi worker per non ad alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Deployment del cluster autonomo
Questo modello di deployment ha un singolo cluster che funge da cluster utente e da cluster di amministrazione.
Questo modello offre i seguenti vantaggi:
- Non richiede un cluster di amministrazione separato
- Supporta il profilo perimetrale, che ha requisiti in termini di risorse di sistema notevolmente ridotti ed è consigliato per i dispositivi periferici con vincoli di risorse elevati.
Questo modello presenta alcuni compromessi in termini di sicurezza, poiché i carichi di lavoro vengono eseguiti su un cluster con i seguenti dati sensibili:
- Credenziali SSH
- Chiavi degli account di servizio Google 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 singolo tipo di carico di lavoro.
Questo modello funziona bene nelle seguenti situazioni:
- Ogni cluster viene gestito in modo indipendente con chiavi SSH e credenziali Google Cloud diverse
- I cluster vengono eseguiti in partizioni isolate di rete come le zone demilitarizzate (DMZ)
- I cluster vengono eseguiti in località perimetrali
Impronta
Un deployment di cluster autonomo richiede i seguenti nodi:
Nodi del piano di controllo:
- Un nodo del piano di controllo per non ad alta disponibilità
- Tre o più nodi del piano di controllo per alta disponibilità
Nodi worker:
- Uno o più nodi worker per non ad alta disponibilità
- Due o più nodi worker per l'alta disponibilità