Architettura del cluster GKE

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

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

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

Un cluster GKE è costituito da un piano di controllo e da macchine worker denominate nodi. Il control plane e i nodi costituiscono il sistema di orchestrazione dei cluster 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:

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

Informazioni sul piano di controllo

Il piano di controllo esegue processi come il server API Kubernetes, lo scheduler e i controller delle risorse principali. GKE gestisce il ciclo di vita del piano di controllo 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.

Piano di controllo e API Kubernetes

Il piano di controllo è l'endpoint unificato per il cluster. Interagisci con il piano di controllo tramite chiamate API Kubernetes. Il piano di controllo 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 Google Cloud console.

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 richieste API indicano a Kubernetes lo stato desiderato per gli oggetti nel 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:

Piano di controllo e database dello stato del cluster

Per impostazione predefinita, il progetto open source Kubernetes utilizza etcd come database di archiviazione per tutti i dati del cluster. Lo stato del cluster viene mantenuto in un archivio di coppia chiave-valore che contiene informazioni sullo stato di ogni oggetto API Kubernetes nel cluster. Ad esempio, il database dello stato del cluster archivia ogni oggetto Secret, ConfigMap e Deployment.

I cluster GKE archiviano lo stato del cluster in uno dei seguenti archivi di coppia chiave-valore:

  • etcd: GKE archivia lo stato del cluster nelle istanze etcd in esecuzione su ogni macchina virtuale (VM) del piano di controllo.
  • 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 piano di controllo. Il server API Kubernetes utilizza l'API etcd per comunicare con il database dello stato del cluster di backend.

Interazione tra piano di controllo e nodi

Il piano di controllo gestisce ciò che viene eseguito su tutti i nodi del cluster. Il piano di controllo pianifica i workload e ne gestisce il ciclo di vita, la scalabilità e gli upgrade. Il piano di controllo gestisce anche le risorse di rete e di archiviazione per questi workload. Il piano di controllo e i nodi comunicano tra loro utilizzando le API Kubernetes.

Interazioni del piano di controllo con Artifact Registry

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

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

A seconda della natura e della durata specifiche dell'interruzione, i workload potrebbero subire interruzioni anche senza il tuo intervento.

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 dello stato.

Best practice:

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

Informazioni sui nodi

I nodi sono le macchine worker che eseguono le tue applicazioni containerizzate e altri workload. 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 workload del cluster. Questi includono il runtime e l'agente del nodo Kubernetes (kubelet), che comunica con il piano di controllo 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 di log e la connettività di rete in-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. Le macchine virtuali Compute Engine sottostanti non sono visibili o accessibili in gcloud CLI o nella Google Cloud console. Visualizza i nodi utilizzando kubectl, gcloud CLI e la Google Cloud console. Visualizza e accedi alle VM Compute Engine sottostanti.
Connettività Nessuna connessione diretta alle VM sottostanti. Connettiti alle VM sottostanti utilizzando SSH.
Sistema operativo (OS) del nodo Gestito da GKE. Tutti i nodi utilizzano Container-Optimized OS con containerd (cos_containerd). Scegli un sistema operativo per i nodi.
Selezione dell'hardware della macchina

Richiedi classi di computing 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 durante la creazione dei node pool. Configura le impostazioni per dimensionamento, scalabilità, quantità, pianificazione e località in base alle esigenze.

Registrazione dei nodi con l'API Kubernetes

Quando viene creato un nodo in un cluster GKE, il processo kubelet su quel nodo stabilisce una connessione TLS con il server API Kubernetes. Durante l'inizializzazione del nodo, kubelet crea un CertificateSigningRequest per richiedere un certificato client univoco dal server API. kubelet utilizza il certificato per creare un oggetto Node nell'API Kubernetes.

Una funzionalità GKE denominata Nodi GKE protetti, abilitata per impostazione predefinita in tutti i nuovi cluster, migliora la sicurezza di questo processo di auto-registrazione dei nodi utilizzando un modulo della piattaforma attendibile virtuale (vTPM) sul nodo per verificare crittograficamente l'identità del nodo. Questa verifica garantisce che il piano di controllo emetta le credenziali solo per i nodi legittimi.

Facoltativamente, puoi richiedere a un componente del piano di controllo GKE attendibile di creare questi oggetti Node anziché kubelet, il che riduce il potenziale impatto se un nodo viene compromesso. Per saperne di più, consulta Creazione di nodi del piano di controllo (anteprima).

Passaggi successivi