Scelta di un modello di deployment

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

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.

Diagramma del deployment di un cluster di amministrazione e di un cluster utente
Deployment di cluster di amministrazione e utente ad alta disponibilità (fai clic per ingrandire)

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.

Diagramma di deployment di un cluster autonomo
Deployment di cluster ibridi ad alta disponibilità (fai clic per ingrandire)

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.

Diagramma di deployment di un cluster autonomo
Deployment di cluster autonomi ad alta disponibilità (fai clic per ingrandire)

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à