Google Distributed Cloud supporta più modelli di deployment per soddisfare di disponibilità, isolamento e utilizzo delle risorse. Questa pagina definisce i concetti condivisi da tutti i modelli di deployment e descrive ciascun modello di deployment.
Questa pagina è rivolta ad amministratori, architetti e operatori che definiscono le soluzioni IT e l'architettura di sistema in conformità con la strategia aziendale in coordinamento con gli stakeholder chiave. Per scoprire di più sui ruoli comuni e su alcuni esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.
Cluster utenti
Un cluster utente è un cluster Kubernetes che esegue i carichi di lavoro containerizzati. È composto dai nodi del piano di controllo e dai 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 di utenti
Per creare un cluster utente, il cluster di amministrazione configura Google Distributed Cloud componenti sul piano di controllo e sui nodi worker del cluster utente. L'amministratore ha solo nodi del piano di controllo perché 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
- Chiavi dell'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 cluster di amministrazione o utente in disponibilità (HA). Questo richiede tre o più nodi del piano di controllo (numeri dispari) in esecuzione in un cluster Kubernetes. 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 deployment di machine learning. Utilizza la modalità non ad alta disponibilità per ambienti non mission critical, per Ad esempio, un ambiente di test in cui è possibile ricreare il cluster se un nodo del piano di controllo presenta un errore. 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 diventa inaccessibile in caso di errore.
Modelli di deployment
Google Distributed Cloud supporta i seguenti modelli di deployment per requisiti diversi:
- Deployment di cluster amministrativi e utente
- Deployment di cluster ibridi
- Deployment di un 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 un luogo centralizzato e per deployment più grandi che necessitano di isolamento tra team diversi o tra carichi di lavoro 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 piano di controllo 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 isolamento tra team diversi.
- Isolamento dei carichi di lavoro di sviluppo e produzione.
- Non devi condividere le credenziali SSH e le chiavi dell'account di servizio con i proprietari del cluster.
- Puoi integrare il tuo deployment con i tuoi piani di controllo
Impronta
Un deployment di cluster di amministrazione e utente richiede i seguenti nodi:
Cluster di amministrazione
- Un nodo del piano di controllo per l'alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Cluster di utenti: puoi configurare l'HA per ogni cluster di utenti in modo indipendente.
Nodi del control plane:
- Un nodo del piano di controllo per gli ambienti non ad alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per gli ambienti non ad alta disponibilità
- Due o più nodi worker per l'HA
Deployment di cluster ibridi
Questo modello di deployment è un deployment multicluster specializzato. Un ibrido è un cluster di amministrazione che può eseguire carichi di lavoro utente. Il tuo cluster ibrido che 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 carichi di lavoro utente all'interno del cluster di amministrazione.
- Il cluster di amministrazione contiene dati sensibili come le credenziali SSH (utilizzate il cluster di amministrazione per gestire i cluster utente su macchine remote) Chiavi dell'account di servizio Google Cloud (utilizzate dal cluster di amministrazione per accedere servizi Google Cloud come Cloud Storage). I deployment di cluster ibride eseguono i carichi di lavoro utente all'interno del cluster di amministrazione, il che potenzialmente espone i dati sensibili del cluster di amministrazione ai carichi di lavoro utente.
Impronta
Un deployment di cluster ibrido richiede i seguenti nodi:
Cluster ibrido
Nodi del control plane:
- Un nodo del piano di controllo per gli ambienti non ad alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per gli ambienti non ad alta disponibilità
- Due o più nodi worker per l'HA e a seconda del tipo di carico di lavoro
Cluster di utenti: puoi configurare l'HA per ogni cluster di utenti in modo indipendente.
Nodi del control plane:
- Un nodo del piano di controllo per gli ambienti non ad alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per gli ambienti non ad alta disponibilità
- Due o più nodi worker per l'alta disponibilità
Deployment del cluster autonomo
Questo modello di implementazione 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 limitate in termini di risorse di sistema ed è consigliato per i dispositivi periferici 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 dell'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 è gestito in modo indipendente con chiavi SSH Credenziali Google Cloud
- I cluster vengono eseguiti in partizioni isolate in rete, separate da quelle non attendibili reti
- I cluster vengono eseguiti in località perimetrali
Impronta
Un deployment di cluster autonomo richiede i seguenti nodi:
Nodi del control plane:
- Un nodo del piano di controllo per gli ambienti non ad alta disponibilità
- Tre o più nodi del piano di controllo per l'alta disponibilità
Nodi worker:
- Uno o più nodi worker per gli ambienti non ad alta disponibilità
- Due o più nodi worker per l'HA
Profilo bordo
I cluster autonomi supportano un profilo edge, che riduce al minimo il consumo di risorse per il cluster. Abiliti il profilo perimetrale quando crei un
un cluster autonomo impostando
profile nel cluster
di configurazione del deployment in edge. Il profilo perimetrale è consigliato per i dispositivi periferici
con vincoli di risorse restrittivi. Per i requisiti hardware associati a
il 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, il piano di controllo i nodi vengono configurati automaticamente per accettare carichi di lavoro utente. Ciò significa che non hanno bisogno di un pool di nodi worker. Tuttavia, la riduzione dell'ingombro tramite l'esecuzione carichi di lavoro sul piano di controllo indebolisce la sicurezza e l'isolamento i piani di controllo e dati. Se l'ingombro ridotto vale questo compromesso, puoi configurare un cluster autonomo con il profilo perimetrale per l'esecuzione su un singolo nodo del piano di controllo oppure su più nodi del piano di controllo per garantire l'alta disponibilità.