Questa pagina illustra l'architettura di un cluster Google Kubernetes Engine (GKE). Tutti i carichi di lavoro Kubernetes containerizzati vengono eseguiti in un cluster GKE.
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 contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.
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 dell'intera infrastruttura sottostante dei cluster, compreso il piano di controllo, nodi e tutti i componenti del 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:
Informazioni sul piano di controllo
Il piano di controllo esegue processi come il server API, lo scheduler e controller di 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 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 piano di controllo è l'endpoint unificato per il tuo cluster. Interagisci con il piano di controllo tramite le chiamate API Kubernetes. Il piano di controllo esegue
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
kubectlo la console Google Cloud.
Il processo del server API è l'hub per tutte le comunicazioni del cluster. Tutti i componenti del cluster interno come nodi, processi di sistema 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 consente di configurare oggetti nell'API in modo imperativo in modo dichiarativo.
Per saperne di più sulla gestione degli oggetti in Kubernetes, consulta quanto segue pagine:
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 gruppo di controllo pianifica i carichi di lavoro e gestisce il traffico il ciclo di vita, la scalabilità upgrade. Il piano di controllo gestisce anche le risorse di rete e di archiviazione per carichi di lavoro con scale out impegnativi. 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 esegue il pull delle immagini container
per il software di sistema Kubernetes in esecuzione sul piano di controllo
Artifact Registry pkg.dev o gcr.io Container Registry. Un'interruzione che interessa questi registri potrebbe causare l'esito negativo delle seguenti azioni:
- Creazione di un nuovo cluster
- Upgrade delle versioni dei 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 servizi Google Cloud, vai alla dashboard dello stato di Google Cloud.
Esegui il deployment in più regioni per consentire la disponibilità delle applicazioni durante le interruzioni della regione.
Informazioni sui nodi
I nodi sono le macchine worker che eseguono le tue applicazioni containerizzate e altre carichi di lavoro con scale out impegnativi. Le singole macchine vengono Macchine virtuali (VM) Compute Engine creati da GKE. Il piano di controllo gestisce e riceve aggiornamenti sullo stato di autosegnalazione 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.
Utilizza stdout per le applicazioni containerizzate perché stdout consente alla tua piattaforma di gestire i log delle applicazioni.
| 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 di base
non visibili o accessibili nell'interfaccia a riga di comando gcloud o nella console Google Cloud. |
Visualizza i nodi utilizzando kubectl, gcloud CLI e
la console Google Cloud. Visualizza e accedi a Compute Engine sottostante
delle VM in esecuzione. |
| Connettività | Nessuna connessione diretta alle VM sottostanti. | Connettiti alle VM sottostanti tramite SSH. |
| Sistema operativo del nodo | Gestito 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 | Richiesta classi di computing nei pod in base al caso d'uso. GKE gestisce configurazione, pianificazione, quantità e ciclo di vita. | Scegli e configura i tipi di macchine di Compute Engine quando creazione di pool di nodi. Configura le impostazioni per dimensioni, scalabilità, quantità, pianificazione e posizione in base alle esigenze. |