Architettura del cluster GKE

Questa pagina descrive l'architettura dei cluster Google Kubernetes Engine (GKE) che eseguono i tuoi carichi di lavoro containerizzati. Utilizza questa pagina per scoprire di più sul control plane, sui nodi e su come interagiscono tra loro i vari componenti del cluster GKE.

Questa pagina è rivolta ad amministratori, architetti e operatori che definiscono soluzioni IT e architettura di sistema. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere l'architettura del cluster Kubernetes.

Un cluster GKE è costituito da un control plane e da macchine worker denominate nodi. Il piano di controllo e i nodi costituiscono il sistema di orchestrazione dei cluster di Kubernetes. GKE Autopilot gestisce l'intera infrastruttura sottostante dei cluster, inclusi il piano di controllo, i nodi e tutti i componenti di sistema.

Se utilizzi la modalità GKE Standard, GKE gestisce il piano di controllo e i componenti di sistema, mentre tu gestisci i nodi.

Il seguente diagramma mostra l'architettura di un cluster GKE:

Questo diagramma mostra i seguenti componenti:

  • Control plane: gestito da GKE. Esegue il server API Kubernetes, i controller dei carichi di lavoro, lo scheduler Kubernetes e l'archiviazione dello stato del cluster.
  • Nodi: gestiti da GKE in modalità Autopilot e gestiti dai clienti in modalità Standard. Tutti i tuoi pod vengono eseguiti nei nodi.
  • Altri servizi Google Cloud : disponibili per l'integrazione con GKE.

Informazioni sul control plane

Il control plane esegue processi come il server API Kubernetes, lo scheduler e i controller delle risorse di base. GKE gestisce il ciclo di vita del control plane dalla creazione all'eliminazione del cluster. Sono inclusi gli upgrade alla versione di Kubernetes in esecuzione sul control plane, che GKE esegue automaticamente o manualmente su tua richiesta se preferisci eseguire l'upgrade prima della pianificazione automatica.

Control plane e API Kubernetes

Il control plane è l'endpoint unificato per il cluster. Interagisci con il piano di controllo tramite chiamate API Kubernetes. Il control plane esegue il processo del server API Kubernetes (kube-apiserver) per gestire le richieste API. Puoi effettuare chiamate API Kubernetes nei seguenti modi:

  • Chiamate dirette: HTTP/gRPC
  • Chiamate indirette: client della riga di comando Kubernetes come kubectl o la consoleGoogle Cloud .

Il processo del server API è l'hub per tutte le comunicazioni del cluster. Tutti i componenti interni del cluster, come nodi, processi di sistema e controller delle applicazioni, fungono da client del server API.

Le tue richieste API comunicano a Kubernetes lo stato desiderato per gli oggetti nel tuo cluster. Kubernetes tenta di mantenere costantemente questo stato. Kubernetes consente di configurare gli oggetti nell'API in modo imperativo o dichiarativo.

Per saperne di più sulla gestione degli oggetti in Kubernetes, consulta le seguenti pagine:

Control plane e database dello stato del cluster

Il progetto open source Kubernetes utilizza etcd come database di archiviazione per tutti i dati del cluster per impostazione predefinita. Lo stato del cluster viene conservato in un archivio chiave-valore che contiene informazioni sullo stato di ogni oggetto API Kubernetes nel cluster. Ad esempio, il database dello stato del cluster memorizza ogni secret, ConfigMap e deployment.

I cluster GKE archiviano lo stato del cluster in uno dei seguenti store chiave-valore:

  • etcd: GKE archivia lo stato del cluster nelle istanze etcd che vengono eseguite su ogni macchina virtuale (VM) del control plane.
  • Spanner: GKE archivia lo stato del cluster in Spanner. Il database Spanner non viene eseguito nel piano di controllo del cluster.

Indipendentemente dal tipo di database, ogni cluster GKE gestisce l'API etcd nel control plane. Il server API Kubernetes utilizza l'API etcd per comunicare con il database dello stato del cluster di backend.

Interazione tra il control plane e i nodi

Il control plane gestisce ciò che viene eseguito su tutti i nodi del cluster. Il piano di controllo pianifica i carichi di lavoro e ne gestisce il ciclo di vita, lo scaling e gli upgrade. Il control plane gestisce anche le risorse di rete e di archiviazione per questi carichi di lavoro. Il control plane e i nodi comunicano tra loro utilizzando le API Kubernetes.

Interazioni del control plane con Artifact Registry

Quando crei o aggiorni un cluster, GKE estrae le immagini container per il software di sistema Kubernetes in esecuzione sul control plane e sui nodi dai repository Artifact Registry nel dominio pkg.dev o gcr.io. Un'interruzione che interessa questi registri potrebbe causare il mancato funzionamento delle seguenti azioni:

  • Creazione di un nuovo cluster
  • Upgrade della versione del cluster

Potrebbero verificarsi interruzioni dei carichi di lavoro anche senza il tuo intervento, a seconda della natura e della durata specifiche dell'interruzione.

Se l'interruzione del repository Artifact Registry è regionale, potremmo reindirizzare le richieste a una zona o regione non interessata dall'interruzione.

Per controllare lo stato dei Google Cloud servizi, vai alla Google Cloud dashboard di stato.

Best practice:

Esegui il deployment in più regioni per consentire la disponibilità delle applicazioni durante le interruzioni delle regioni.

Informazioni sui nodi

I nodi sono le macchine worker che eseguono le tue applicazioni containerizzate e altri carichi di lavoro. Le singole macchine sono macchine virtuali (VM) di Compute Engine che GKE crea. Il control plane gestisce e riceve aggiornamenti sullo stato auto-segnalato di ogni nodo.

Un nodo esegue i servizi necessari per supportare i container che costituiscono i carichi di lavoro del cluster. Questi includono il runtime e l'agente nodo Kubernetes (kubelet), che comunica con il control plane ed è responsabile dell'avvio e dell'esecuzione dei container pianificati sul nodo.

GKE esegue anche una serie di container di sistema che vengono eseguiti come agenti per nodo, chiamati DaemonSet, che forniscono funzionalità come la raccolta dei log e la connettività di rete intra-cluster.

Best practice:

Utilizza stdout per le applicazioni containerizzate perché stdout consente alla piattaforma di gestire i log delle applicazioni.

La gestione dei nodi varia in base alla modalità di funzionamento del cluster, come segue:

Componente Nodo Modalità Autopilot Modalità Standard
Ciclo di vita

Completamente gestito da GKE, tra cui:

GKE gestisce quanto segue:

Puoi gestire quanto segue:
Visibilità Visualizza i nodi utilizzando kubectl. Macchine virtuali Compute Engine sottostanti non visibili o accessibili in gcloud CLI o nella console Google Cloud . Visualizza i nodi utilizzando kubectl, gcloud CLI e la console Google Cloud . Visualizza e accedi alle VM di Compute Engine sottostanti.
Connettività Nessuna connessione diretta alle VM sottostanti. Connettiti alle VM sottostanti utilizzando SSH.
Sistema operativo del nodo Gestito da GKE. Tutti i nodi utilizzano Container-Optimized OS con containerd (cos_containerd). Scegliere un sistema operativo per i nodi.
Selezione dell'hardware della macchina

Richiedi classi di calcolo nei pod in base al caso d'uso.

GKE gestisce la configurazione, la pianificazione, la quantità e il ciclo di vita delle macchine.

 Scegli e configura i tipi di macchine Compute Engine quando crei pool di nodi. Configura le impostazioni per dimensionamento, scalabilità, quantità, pianificazione e posizione in base alle esigenze.