Architettura del cluster GKE

Autopilot Standard

---

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

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

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

Un cluster GKE è costituito da un piano di controllo e da macchine worker denominate nodi. Il piano di controllo 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 del sistema, mentre tu gestisci i nodi.

Il seguente diagramma mostra l'architettura di un cluster GKE. Questo diagramma illustra in modo specifico dove esistono le risorse e chi le gestisce, anziché rappresentare il flusso di traffico:

Informazioni sul piano di controllo

Il piano di controllo esegue processi come il server API Kubernetes, lo scheduler e i controller delle risorse di base. 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 nel piano di controllo, 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 control plane è l'endpoint unificato del cluster. Interagisci con il piano di controllo tramite le chiamate API Kubernetes. Il control plane esegue il processo del server API Kubernetes (kube-apiserver) per gestire le richieste API. Puoi eseguire chiamate all'API Kubernetes nei seguenti modi:

• Chiamate dirette: HTTP/gRPC
• Chiamate indirette: client a riga di comando Kubernetes come kubectl o la console Google 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 di applicazioni, agiscono come 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 ti consente di configurare gli oggetti nell'API in modo imperativo o declarativo.

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

• Informazioni sugli oggetti Kubernetes
• Gestione degli oggetti di Kubernetes

Interazione tra il piano di controllo e i nodi

Il piano di controllo gestisce le applicazioni in esecuzione su tutti i nodi del cluster. Il piano di controllo pianifica i carichi di lavoro e gestisce il ciclo di vita, la scalabilità e gli upgrade dei carichi di lavoro. Il piano di controllo gestisce anche le risorse di rete e di archiviazione per questi carichi di lavoro. 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 da pkg.devArtifact Registry o gcr.ioContainer Registry. Un'interruzione che interessa questi registri potrebbe causare il fallimento delle seguenti azioni:

• Creazione di un nuovo cluster
• Upgrade delle versioni del cluster

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

Se l'interruzione di pkg.devArtifact Registry o gcr.ioContainer Registry è regionale, potremmo reindirizzare le richieste a una zona o una 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 della regione.

Attenzione:Container Registry è deprecato e programmato per l'arresto. Le organizzazioni che non hanno utilizzato Container Registry prima dell'8 gennaio 2024 hanno nuovi repository gcr.io ospitati su Artifact Registry per impostazione predefinita. A partire dal 15 maggio 2024, Google Cloud i progetti senza precedente utilizzo di Container Registry supporteranno solo l'hosting e la gestione delle immagini per il dominio gcr.io in Artifact Registry.

L'arresto di Container Registry è programmato per il 18 marzo 2025. Per informazioni dettagliate sul ritiro, consulta Ritiro di Container Registry.

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) Compute Engine create da GKE. Il piano di controllo gestisce e riceve aggiornamenti sullo stato auto-segnalato di ciascun nodo.

Un nodo esegue i servizi necessari per supportare i container che costituiscono i carichi di lavoro del cluster. Sono inclusi 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 contenitori di sistema che funzionano 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 tua piattaforma di gestire i log delle applicazioni.

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

Componente Node	Modalità Autopilot	Modalità Standard
Ciclo di vita	Completamente gestito da GKE, tra cui: Upgrade automatici Riparazioni automatiche Controlli di integrità Scalabilità automatica dei nodi Creazione ed eliminazione di nodi Ridimensionamento Etichettatura per separazione dei carichi di lavoro.	GKE gestisce quanto segue: Upgrade automatici Riparazioni automatiche Controlli di integrità Puoi gestire quanto segue: Configurazione della scalabilità automatica dei nodi Upgrade manuale delle versioni Modifiche alla configurazione (ad esempio etichette e ridimensionamento) Creazione ed eliminazione di pool di nodi
Visibilità	Visualizza i nodi utilizzando kubectl. Macchine virtuali di Compute Engine di base non visibili o accessibili nellgcloud 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 di base.
Connettività	Nessuna connessione diretta alle VM sottostanti.	Connettiti alle VM sottostanti tramite SSH.
Sistema operativo del nodo	Gestita da GKE. Tutti i nodi utilizzano Container-Optimized OS con containerd (cos_containerd).	Scegli un sistema operativo per i tuoi 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 le dimensioni, la scalabilità, la quantità, la pianificazione e la posizione in base alle esigenze.