Architettura di cluster standard

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Un cluster è la base di Google Kubernetes Engine (GKE): gli oggetti Kubernetes che rappresentano le tue applicazioni containerizzate vengono eseguiti tutti su un cluster.

In GKE, un cluster è composto da almeno un piano di controllo e da più macchine worker denominate nodi. Queste macchine del piano di controllo e del nodo eseguono il sistema di orchestrazione del cluster Kubernetes.

Il seguente diagramma fornisce una panoramica dell'architettura per un cluster di zona in GKE:

GKE esegue il provisioning, la manutenzione e tutto ciò che è presente nel piano di controllo di zona e esegue solo il provisioning dei nodi.

Piano di controllo

Il piano di controllo esegue i processi del piano di controllo, inclusi il server API, lo scheduler e i controller delle risorse principali di Kubernetes. Il ciclo di vita del piano di controllo è gestito da GKE quando crei o elimini un cluster. Sono inclusi gli upgrade alla versione di Kubernetes in esecuzione sul 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 cluster tramite le chiamate API di Kubernetes e il piano di controllo esegue il processo Kubernetes API Server per gestire queste richieste. Puoi effettuare chiamate API Kubernetes direttamente tramite HTTP/gRPC o indirettamente, eseguendo comandi dal client a riga di comando Kubernetes (kubectl) o interagendo con l'interfaccia utente in Google Cloud Console.

Il processo del server API è l'hub per tutte le comunicazioni per il cluster. Tutti i processi interni del cluster (come i nodi del cluster, i componenti di sistema e i controller di applicazioni) agiscono da client del server API; il server API è l'unica "fonte attendibile" per l'intero cluster.

Piano di controllo e interazione con il nodo

Il piano di controllo decide cosa eseguire su tutti i nodi del cluster. Il piano di controllo pianifica i carichi di lavoro, ad esempio applicazioni containerizzate, e gestisce i carichi di lavoro di ciclo di vita, scalabilità e upgrade. Il piano di controllo gestisce anche le risorse di rete e di archiviazione per tali carichi di lavoro.

Il piano di controllo e i nodi comunicano utilizzando le API Kubernetes.

Interazioni del piano di controllo con Artifact Registry e Container Registry

Quando crei o aggiorni un cluster, le immagini container per il software Kubernetes in esecuzione sul piano di controllo (e sui nodi) vengono estratte da pkg.devArtifact Registry o gcr.io Container Registry. Un'interruzione che influisce su questi registri potrebbe causare i seguenti tipi di errore:

  • Creazione di nuovi cluster non riuscita durante l'interruzione.
  • L'upgrade dei cluster non riesce durante l'interruzione.
  • Le interruzioni dei carichi di lavoro possono verificarsi anche senza l'intervento dell'utente, a seconda della natura e della durata dell'interruzione.

In caso di interruzione del servizio Artifact Registry pkg.dev o di Container Registry gcr.io, Google potrebbe reindirizzare le richieste a una zona o un'area geografica non interessata dall'interruzione.

Per verificare lo stato attuale dei servizi Google Cloud, vai alla dashboard dello stato di Google Cloud.

Nodi

Un cluster in genere ha uno o più nodi, ovvero le macchine worker che eseguono le tue applicazioni containerizzate e altri carichi di lavoro. Le singole macchine sono istanze VM di Compute Engine che GKE crea per tuo conto quando crei un cluster.

Ogni nodo è gestito dal piano di controllo, che riceve gli aggiornamenti sullo stato autosegnalato di ogni nodo. Puoi esercitare un controllo manuale sul ciclo di vita dei nodi o fare in modo che GKE esegua riparazioni automatiche e upgrade automatici sui nodi del tuo cluster.

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

In GKE esistono anche una serie di container speciali che vengono eseguiti come agenti per nodo per fornire funzionalità come la raccolta di log e la connettività di rete intra-cluster.

Tipo di macchina dei nodi

Ogni nodo appartiene a un tipo di macchina Compute Engine standard. Il tipo predefinito è e2-medium. Puoi selezionare un tipo di macchina diverso quando crei un cluster.

Immagini sistema operativo nodo

Ogni nodo esegue un'immagine del sistema operativo specializzata per l'esecuzione dei container. Puoi specificare l'immagine del sistema operativo utilizzata dai cluster e dai pool di nodi.

Piattaforma CPU minima

Quando crei un cluster o un pool di nodi, puoi specificare una piattaforma CPU di base minima per i relativi nodi. Scegliere una piattaforma CPU specifica può essere vantaggioso per carichi di lavoro avanzati o con un uso intensivo di calcolo. Per ulteriori informazioni, consulta la sezione Piattaforma CPU minima.

Risorse allocabili dei nodi

Alcune risorse di un nodo sono necessarie per eseguire i componenti dei nodi GKE e Kubernetes necessari per far funzionare quel nodo come parte del cluster. Per questo motivo, potresti notare una disparità tra le risorse totali del nodo (come specificato nella documentazione del tipo di macchina) e le risorse allocabili del nodo in GKE.

Poiché i tipi di macchine più grandi tendono a eseguire più container (e, per estensione, più pod), la quantità di risorse che GKE riserva per i componenti di Kubernetes scala verso l'alto per le macchine più grandi. I nodi di Windows Server richiedono anche più risorse di un tipico nodo Linux. I nodi hanno bisogno di risorse aggiuntive per tenere conto del sistema operativo Windows e dei componenti Windows Server che non possono essere eseguiti nei container.

Puoi richiedere risorse per i tuoi pod o limitarne l'utilizzo. Per scoprire come richiedere o limitare l'utilizzo delle risorse per i pod, consulta Gestione delle risorse per i container.

Per esaminare le risorse allocabili dei nodi in un cluster, esegui il comando seguente, sostituendo NODE_NAME con il nome del nodo che vuoi controllare:

kubectl describe node NODE_NAME | grep Allocatable -B 7 -A 6

L'output restituito contiene i campi Capacity e Allocatable con misurazioni per archiviazione temporanea, memoria e CPU.

Soglia di rimozione

Per determinare la quantità di memoria disponibile per i pod, devi anche considerare la soglia di rimozione. GKE riserva altri 100 MiB di memoria su ciascun nodo per l'eliminazione dei kubelet.

Risorse di memoria e CPU allocabili

Le risorse allocabili vengono calcolate nel seguente modo:

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

Per le risorse di memoria, GKE riserva quanto segue:

  • 255 MiB di memoria per macchine con meno di 1 GiB di memoria
  • 25% dei primi 4 GiB di memoria
  • 20% dei successivi 4 GiB di memoria (fino a 8 GiB)
  • 10% dei successivi 8 GiB di memoria (fino a 16 GiB)
  • 6% dei successivi 112 GiB di memoria (fino a 128 GiB)
  • 2% di qualsiasi memoria superiore a 128 GiB

Per le risorse della CPU, GKE riserva quanto segue:

  • 6% del primo core
  • 1% del core successivo (fino a 2 core)
  • 0,5% dei prossimi 2 core (fino a 4 core)
  • 0,25% di tutti i core superiori a 4 core

Risorse di archiviazione temporanea locale allocabile

A partire dalla versione 1.10 di GKE, puoi gestire le risorse di archiviazione temporanea locale come le tue risorse di CPU e memoria. Per scoprire come fare in modo che i tuoi pod specifichino richieste e limiti di archiviazione temporanea e per vedere come vengono gestiti, consulta Archiviazione temporanea locale nella documentazione di Kubernetes.

GKE in genere configura i propri nodi con un singolo file system e scansione periodica. Lo spazio di archiviazione temporaneo può anche essere supportato da SSD locali. In entrambi i casi, una parte del file system è riservata all'utilizzo kubelet. La parte rimanente, chiamata archiviazione temporanea locale allocabile, è disponibile per l'uso come risorse di archiviazione temporanea.

La quantità di file system riservata a kubelet e ad altri componenti del sistema viene fornita da:

EVICTION-THRESHOLD + SYSTEM-RESERVATION

Spazio di archiviazione temporaneo supportato da disco di avvio

Per impostazione predefinita, l'archiviazione temporanea è supportata dal disco di avvio del nodo. In questo caso, la soglia di rimozione e le dimensioni della prenotazione di sistema sono fornite dalle seguenti formule:

EVICTION-THRESHOLD = 10% * BOOT-DISK-CAPACITY

SYSTEM-RESERVATION = Min(50% * BOOT-DISK-CAPACITY, 6GiB + 35% * BOOT-DISK-CAPACITY, 100 GiB)

Per una rappresentazione approssimativa della quantità di spazio di archiviazione temporanea allocabile disponibile man mano che la capacità del disco di avvio aumenta, consulta il seguente grafico:

Un grafico che mostra come l'archiviazione temporanea aumenta con la capacità del disco di avvio. La relazione è indicativamente lineare.

Archiviazione temporanea supportata da SSD locali

Lo spazio riservato al sistema dipende dal numero di SSD locali:

Numero di SSD locali SYSTEM-RESERVATION (GiB)
1 50
2 75
3 o più 100

La soglia di rimozione è simile allo spazio di archiviazione temporaneo supportato dal disco di avvio:

EVICTION-THRESHOLD = 10% * NUM-LOCAL-SSDS * 375 GB

La capacità di ogni SSD locale è di 375 GiB. Per scoprire di più, consulta la documentazione di Compute Engine sull'aggiunta di SSD locali.