Cluster Anthos on bare metal supporta più modelli di deployment per soddisfare diverse esigenze di disponibilità, isolamento e impronta 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 dai nodi del piano di controllo e dai nodi worker. Cluster Anthos on bare metal supporta uno o più cluster utente. I cluster utente devono contenere uno o più nodi worker che eseguono i 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 attività seguenti:
- Creazione di cluster utente
- Upgrade di cluster utente
- Aggiorna i 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 del cluster utente e sui nodi worker. Il cluster di amministrazione ha solo nodi del piano di controllo perché i cluster Anthos su componenti 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 abilitare l'installazione remota
- Chiavi dell'account di servizio Google Cloud: utilizzate per accedere a funzionalità come Container Registry
Per proteggere i dati sensibili, limita l'accesso al tuo cluster di amministrazione.
Alta disponibilità
Puoi eseguire cluster di amministrazione o utenti in modalità alta disponibilità. Questa modalità richiede tre o più nodi del piano di controllo (numero dispari) 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 unico punto di errore, utilizza la modalità ad alta disponibilità per i deployment di produzione. Utilizza la modalità non ad alta disponibilità per gli ambienti critici non in uscita, ad esempio un ambiente di test, in cui puoi ricreare il cluster in caso di errore del singolo nodo del piano di controllo. Un cluster utente ad alta disponibilità deve avere due o più nodi worker nel caso in cui si verifichi un guasto del nodo worker.
Modelli di deployment
Cluster Anthos su Bare Metal supporta i seguenti modelli di deployment per soddisfare diversi requisiti:
- Deployment autonomo dei cluster
- Deployment multi-cluster
- Deployment ibrido di cluster
Deployment autonomo dei cluster
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
- Salva tre nodi in una configurazione ad alta disponibilità.
Questo modello presenta i seguenti compromessi in termini di sicurezza perché i carichi di lavoro vengono eseguiti su un cluster con i seguenti dati sensibili:
- Credenziali SSH
- Chiavi account di servizio Google Cloud
Utilizza questo modello se soddisfi una delle seguenti condizioni:
- Gestisci ogni cluster in modo indipendente.
- Hai un numero limitato di nodi worker.
- Sostieni un singolo team.
- Devi eseguire un solo tipo di carico di lavoro.
Questo modello funziona bene nelle seguenti situazioni:
- Ogni cluster è gestito in modo indipendente con chiavi SSH e credenziali Google Cloud diverse
- I cluster vengono eseguiti in partizioni isolate di rete come zone demilitarizzate (DMZ)
- I cluster vengono eseguiti in località perimetrali
2D
Un deployment di cluster autonomo richiede i seguenti nodi:
Nodi del piano di controllo:
- Un nodo del piano di controllo per l'assenza di alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per l'alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Deployment multi-cluster
Utilizza questo modello di deployment se hai un parco risorse di 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 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 piano di controllo centralizzato e un'API per gestire i cicli di vita dei cluster utente.
- Fornisce isolamento tra i diversi team.
- 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 tuo deployment con i tuoi piani di controllo
2D
Un deployment multi-cluster richiede i seguenti nodi:
Cluster di amministrazione
- Un nodo del piano di controllo per l'assenza di alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Cluster utente: puoi configurare alta disponibilità per ogni cluster utente.
Nodi del piano di controllo:
- Un nodo del piano di controllo per l'assenza di alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per l'alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Deployment ibrido di cluster
Questo modello di deployment è un deployment multi-cluster specializzato. Utilizza questo modello per eseguire i carichi di lavoro utente sul cluster di amministrazione. Il cluster di amministrazione gestisce comunque i cluster utente aggiuntivi.
Funzionalità di questo modello:
- L'allocazione di una macchina bare metal completa per un cluster di amministrazione è spesso uno spreco di risorse, poiché i cluster di amministrazione utilizzano relativamente poche risorse. Il deployment del cluster ibrido ti consente di recuperare la capacità inutilizzata su quella macchina 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 su macchine remote) e le chiavi degli 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 utente all'interno del cluster di amministrazione, e questo potrebbe esporre i dati sensibili del cluster di amministrazione ai carichi di lavoro degli utenti.
2D
Un deployment di cluster ibrido richiede i seguenti nodi:
Cluster ibrido
Nodi del piano di controllo:
- Un nodo del piano di controllo per l'assenza di alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per l'alta disponibilità
- Due o più nodi worker per l'alta disponibilità e a seconda del tipo di carico di lavoro
Cluster utente: puoi configurare alta disponibilità per ogni cluster utente.
Nodi del piano di controllo:
- Un nodo del piano di controllo per l'assenza di alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per l'alta disponibilità
- Due o più nodi worker per l'alta disponibilità