Scalabilità

Questa pagina descrive le best practice per creare, configurare e utilizzare cluster Google Distributed Cloud al fine di soddisfare i carichi di lavoro che si avvicinano ai limiti di scalabilità di Kubernetes.

Regole per i nomi dei cluster

Per ogni progetto Google Cloud:

  • Ogni cluster utente deve avere un nome univoco in tutti i cluster di amministrazione nell'ambito di un progetto Google Cloud.

Limiti di scalabilità

Tieni in considerazione i seguenti limiti durante la progettazione delle tue applicazioni su GKE su VMware:

Informazioni sui limiti

Poiché GKE su VMware è un sistema complesso con un'ampia superficie di integrazione, la scalabilità del cluster prevede molte dimensioni correlate. Ad esempio, GKE su VMware può scalare in base al numero di nodi, pod o servizi. L'estensione di più dimensioni alla volta può causare problemi anche in cluster più piccoli. Ad esempio, la pianificazione di 110 pod per nodo in un cluster con 500 nodi può allungare il numero di pod, pod per nodo e nodi.

Per ulteriori dettagli, consulta Soglie di scalabilità di Kubernetes.

I limiti di scalabilità sono sensibili anche alla configurazione e all'hardware vSphere su cui è in esecuzione il cluster. Questi limiti vengono verificati in un ambiente probabilmente diverso dal tuo. Pertanto, potresti non riprodurre i numeri esatti quando l'ambiente sottostante è il fattore limitante.

Preparazione alla scalabilità

Mentre ti prepari a scalare i cluster di amministrazione o i cluster utente, considera i seguenti requisiti e limitazioni.

Requisiti di CPU, memoria e spazio di archiviazione

Consulta i requisiti di CPU, RAM e spazio di archiviazione per ogni singola VM.

Requisiti di I/O del disco e della rete

I carichi di lavoro che richiedono un uso intensivo dei dati e alcuni componenti del piano di controllo sono sensibili alla latenza di I/O su disco e rete. Ad esempio, per le prestazioni e la stabilità di etcd in un cluster con decine di nodi e migliaia di pod sono in genere necessarie 500 IOPS sequenziali (ad esempio un tipico SSD locale o un dispositivo a blocchi virtualizzato ad alte prestazioni).

Indirizzo IP del nodo

Ogni nodo GKE su VMware richiede un indirizzo IP DHCP o assegnato in modo statico.

Ad esempio, in una configurazione con un cluster utente non ad alta disponibilità con 50 nodi e un cluster utente ad alta disponibilità con 250 nodi, sono necessari 307 indirizzi IP.

La tabella seguente mostra la suddivisione degli indirizzi IP:

Tipo di nodo Numero di indirizzi IP
VM del piano di controllo del cluster di amministrazione 3
VM del piano di controllo cluster utente 1 (non ad alta disponibilità) 1
VM del nodo worker del cluster utente 1 50
VM del piano di controllo del cluster utente 2 (HA) 3
VM del nodo worker del cluster utente 2 250
Totale 307

Esecuzione di molti cluster utente in un cluster di amministrazione

Mentre ti prepari a eseguire molti cluster utente in un cluster di amministrazione, segui questi passaggi quando crei il cluster di amministrazione.

Blocco CIDR pod nel cluster di amministrazione

Il blocco CIDR pod è il blocco CIDR per tutti i pod in un cluster di amministrazione. La configurazione avviene tramite il campo network.podCIDR in admin-cluster.yaml.

In questo intervallo, a ogni nodo vengono assegnati blocchi /24 più piccoli. Se in tutti i tuoi cluster utente è abilitato Controlplane V2, il cluster di amministrazione avrà solo tre nodi e sono disponibili molti indirizzi IP di pod. Tuttavia, ogni volta che crei un cluster utente che utilizza kubeception anziché il piano di controllo V2, al cluster di amministrazione vengono aggiunti uno o tre nodi:

  • Ogni cluster utente kubeception ad alta disponibilità aggiunge tre nodi al cluster di amministrazione.

  • Ogni cluster utente kubeception non ad alta disponibilità aggiunge un nodo al cluster di amministrazione.

Se hai bisogno di un cluster di amministrazione dei nodi N, devi assicurarti che il blocco CIDR dei pod sia sufficientemente grande da supportare blocchi N /24.

La tabella seguente descrive il numero massimo di nodi supportati da diverse dimensioni dei blocchi CIDR dei pod:

Dimensioni blocco CIDR pod Numero massimo di nodi supportati
/18 64
/17 128
/16 256
/15 512

Il blocco CIDR predefinito dei pod di un cluster di amministrazione è 192.168.0.0/16, che supporta 256 nodi.

In un cluster di amministrazione con 100 cluster utente kubeception ad alta disponibilità, sono presenti 3 nodi del piano di controllo del cluster di amministrazione e 300 nodi del piano di controllo dei cluster utente. Il numero totale di nodi è 303 (più di 256). Di conseguenza, devi aggiornare il blocco CIDR dei pod a /15 per supportare fino a 100 cluster utente kubeception ad alta disponibilità.

Per configurare il blocco CIDR pod, imposta il campo network.podCIDR nel file di configurazione del cluster di amministrazione.

Blocco CIDR del servizio nel cluster di amministrazione

Il blocco CIDR servizio è il blocco CIDR per tutti i servizi in un cluster di amministrazione. La configurazione viene eseguita tramite il campo network.serviceCIDR in admin-cluster.yaml.

La tabella seguente descrive il numero massimo di servizi supportati da diverse dimensioni dei blocchi CIDR dei servizi:

Dimensioni blocco CIDR servizio Numero massimo di servizi supportati
/24 256
/23 512
/22 1024

Il valore predefinito è 10.96.232.0/24, che supporta 256 servizi.

Ogni cluster utente kubeception utilizza 6 servizi, mentre il piano di controllo del cluster di amministrazione utilizza 14 servizi. Di conseguenza, per eseguire 100 cluster utente kubeception, devi modificare il blocco CIDR servizio nel cluster di amministrazione in modo da utilizzare un intervallo /22.

Cloud Logging e Cloud Monitoring

Cloud Logging e Cloud Monitoring ti consentono di monitorare le tue risorse.

L'utilizzo di CPU e memoria dei componenti di logging e monitoraggio di cui è stato eseguito il deployment in un cluster di amministrazione viene scalato in base al numero di cluster utente kubeception.

La tabella seguente descrive la quantità di CPU e memoria del nodo del cluster di amministrazione necessaria per eseguire un numero elevato di cluster utente kubeception:

Numero di cluster utente kubeception CPU del nodo del cluster di amministrazione Memoria dei nodi del cluster di amministrazione
Da 0 a 10 4 CPU 16 GB
Da 11 a 20 4 CPU 32 GB
Da 20 a 100 4 CPU 90GB

Ad esempio, se esistono 2 nodi del cluster di amministrazione, ognuno dei quali ha 4 CPU e 16 GB di memoria, puoi eseguire da 0 a 10 cluster utente kubeception. Per creare più di 20 cluster utente kubeception, devi prima ridimensionare la memoria dei nodi del cluster di amministrazione da 16 GB a 90 GB.

GKE Hub

Per impostazione predefinita, puoi registrare un massimo di 15 cluster utente.

Per registrare più cluster in GKE Hub, puoi inviare una richiesta di aumento della quota nella console Google Cloud:

Vai a Quote

Esecuzione di molti nodi e pod in un cluster utente

Mentre ti prepari a eseguire molti nodi e pod in un cluster utente, segui questi passaggi durante la creazione del cluster utente.

Blocco CIDR dei pod nel cluster utente

Il blocco CIDR pod è il blocco CIDR per tutti i pod in un cluster utente. La configurazione avviene tramite il campo network.podCIDR in user-cluster.yaml.

All'interno di questo intervallo, a ogni nodo viene assegnato un blocco /24 più piccolo. Se hai bisogno di un cluster di nodi N, devi assicurarti che questo blocco sia sufficientemente grande da supportare blocchi N /24.

La tabella seguente descrive il numero massimo di nodi supportati da diverse dimensioni dei blocchi CIDR dei pod:

Dimensioni blocco CIDR pod Numero massimo di nodi supportati
/18 64
/17 128
/16 256
/15 512

Il blocco CIDR predefinito dei pod è 192.168.0.0/16, che supporta 256 nodi. Ad esempio, per creare un cluster con 500 nodi, devi modificare il blocco CIDR dei pod nel cluster utente in modo da utilizzare un intervallo /15.

Blocco CIDR del servizio nel cluster utente

Il blocco CIDR servizio è il blocco CIDR per tutti i servizi in un cluster utente. Viene configurato tramite il campo network.serviceCIDR in user-cluster.yaml.

La tabella seguente descrive il numero massimo di servizi supportati da diverse dimensioni dei blocchi CIDR dei servizi:

Dimensioni blocco CIDR servizio Numero massimo di servizi supportati
/21 2048
/20 4096
/19 8.192
/18 16.384

Nodi del piano di controllo del cluster utente

L'utilizzo della memoria dei componenti del piano di controllo del cluster utente viene scalato in base al numero di nodi nel cluster utente.

La seguente tabella fornisce la CPU e la memoria richieste dal nodo del piano di controllo di un cluster utente in base alle dimensioni del cluster utente:

Numero di nodi del cluster utente CPU del nodo del piano di controllo Memoria del nodo del piano di controllo
Da 0 a 20 3 CPU 5 GB
Da 21 a 75 3 CPU 6GB
Da 76 a 250 4 CPU 8 GB
Da 251 a 500 4 CPU 16 GB

Ad esempio, per creare più di 250 nodi in un cluster utente, devi utilizzare nodi del piano di controllo del cluster utente con almeno 16 GB di memoria.

La specifica del nodo del piano di controllo del cluster utente può essere modificata tramite il campo masterNode in user-cluster.yaml.

Dataplane v2

Per cluster utente con 500 nodi che utilizzano Dataplane V2, consigliamo 120 GB di memoria e 32 core CPU per i nodi del piano di controllo del cluster utente.

Cloud Logging e Cloud Monitoring

Cloud Logging e Cloud Monitoring ti consentono di monitorare le tue risorse.

L'utilizzo di CPU e memoria degli agenti nel cluster di cui è stato eseguito il deployment in un cluster utente fare lo scale in termini di numero di nodi e pod in un cluster utente.

I componenti di Cloud Logging e Monitoring, come prometheus-server e stackdriver-prometheus-sidecar, utilizzano un utilizzo delle risorse di CPU e memoria diverso in base al numero di nodi e al numero di pod. Prima di fare lo scale up del cluster, imposta la richiesta e il limite di risorse in base all'utilizzo medio stimato di questi componenti. La seguente tabella mostra le stime per il volume medio di utilizzo per ogni componente:

Numero di nodi Nome container Utilizzo stimato della CPU Memoria utilizzata stimata
0 pod/nodo 30 pod/nodo 0 pod/nodo 30 pod/nodo
Da 3 a 50 prometheus-server 100 min 390m 650 mln 1,3 G
stackdriver-prometheus-sidecar 100 min 340 min 1,5 G 1,6 G
Da 51 a 100 prometheus-server 160 min 500m 1,8 G 5,5 G
stackdriver-prometheus-sidecar 200m 500m 1,9 G 5,7 G
Da 101 a 250 prometheus-server 400m 2.500 m 6,5 G 16G
stackdriver-prometheus-sidecar 400m 1.300 m 7,5 G 12 GB
Da 250 a 500 prometheus-server 1200m 2.600 m 22 GB 25G
stackdriver-prometheus-sidecar 400m 2250m 65G 78 GB

Assicurati di avere nodi sufficientemente grandi per pianificare i componenti di Cloud Logging e Cloud Monitoring. Un modo per farlo è creare prima un cluster di piccole dimensioni, modificare le risorse dei componenti Cloud Logging e Cloud Monitoring in base alla tabella precedente, creare un pool di nodi per ospitare i componenti, quindi fare lo scale up del cluster gradualmente fino a dimensioni maggiori.

Puoi scegliere di mantenere un pool di nodi abbastanza grande da consentire ai componenti di monitoraggio e logging di impedire la pianificazione di altri pod nel pool di nodi. A questo scopo, devi aggiungere le seguenti incompatibilità al pool di nodi:

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

In questo modo si impedisce la pianificazione di altri componenti nel pool di nodi e viene impedito l'eliminazione dei carichi di lavoro degli utenti a causa del consumo delle risorse dei componenti di monitoraggio.

Bilanciatore del carico

I servizi descritti in questa sezione fanno riferimento ai servizi Kubernetes di tipo LoadBalancer.

Esiste un limite al numero di nodi nel cluster e al numero di servizi che puoi configurare sul tuo bilanciatore del carico.

Per il bilanciamento del carico in bundle (Seesaw), è previsto anche un limite al numero di controlli di integrità. Il numero di controlli di integrità dipende dal numero di nodi e dal numero di traffico dei servizi locali. Un servizio locale di traffico è un servizio per cui il criterio externalTrafficPolicy è impostato su Local.

La seguente tabella descrive il numero massimo di servizi, nodi e controlli di integrità per il bilanciamento del carico in bundle (Seesaw) e il bilanciamento del carico integrato (F5):

Bilanciamento del carico in bundle (Seesaw) Bilanciamento del carico integrato (F5)
Numero massimo di servizi 500 250 2
N. massimo di nodi 500 250 2
Numero massimo di controlli di integrità N + (L * N) <= 10K, dove N è il numero di nodi e L è il numero di traffico dei servizi locali 1 N/A 2

1 Ad esempio, supponiamo di avere 100 nodi e 99 servizi locali di traffico. Il numero di controlli di integrità è 100 + (99 * 100) = 10.000, ovvero entro il limite di 10.000.

2 Per ulteriori informazioni, consulta F5. Questo numero è influenzato da fattori quali il numero di modello hardware F5, la CPU/memoria dell'istanza virtuale e le licenze.

Componenti di sistema di scalabilità automatica

GKE su VMware scala automaticamente i componenti di sistema nei cluster utente in base al numero di nodi, senza che sia necessario modificare le configurazioni. Puoi utilizzare le informazioni di questa sezione per la pianificazione delle risorse.

  • GKE su VMware esegue automaticamente la scalabilità verticale scalando le richieste/limiti di CPU e memoria dei seguenti componenti di sistema utilizzando addon-resizer:

    • kube-state-metrics è un deployment in esecuzione su nodi worker del cluster che rimane in ascolto del server API Kubernetes e genera metriche sullo stato degli oggetti. Le richieste e i limiti di CPU e memoria scalano in base al numero di nodi.

      La seguente tabella descrive le richieste/limiti di risorse impostati dal sistema, dato il numero di nodi in un cluster:

      Numero di nodi Circa1 richiesta/limite di CPU (milli) Approssimativamente1 richiesta/limite di memoria (Mi)
      Da 3 a 5 105 110
      Da 6 a 500 100 + num_nodi 100 + (2 * num_nodi)

      1 È disponibile un margine pari a +-5% per ridurre il numero di riavvii dei componenti durante il ridimensionamento.

      Ad esempio, in un cluster con 50 nodi, la richiesta/limite di CPU è impostato su 150 m/150 m e il limite di memoria è impostato su 200 Mi/200 Mi. In un cluster con 250 nodi, la richiesta/il limite di CPU è impostato su 350 m/350 m e il limite di memoria è impostato su 600 Mi.

    • metrics-server è un deployment in esecuzione su nodi worker del cluster che viene utilizzato dalle pipeline di scalabilità automatica integrate di Kubernetes. Le richieste e i limiti di CPU e memoria scalano in base al numero di nodi.

  • GKE su VMware esegue automaticamente la scalabilità orizzontale sia nei cluster di amministrazione che nei cluster utente scalando il numero di repliche dei seguenti componenti di sistema:

    • core-dns è la soluzione DNS utilizzata per Service Discovery in GKE su VMware. Viene eseguito come deployment sui nodi worker del cluster utente. GKE su VMware scala automaticamente il numero di repliche in base al numero di nodi e core della CPU nel cluster. A ogni aggiunta/eliminazione di 16 nodi o 256 core, viene aumentata/diminuita 1 replica. Se hai un cluster di nodi N e C core, puoi prevedere max(N/16, C/256) repliche.

    • calico-typha è un componente per il supporto del networking dei pod in GKE su VMware. Viene eseguito come deployment sui nodi worker del cluster utente. GKE su VMware scala automaticamente il numero di repliche calico-typha in base al numero di nodi nel cluster:

      Numero di nodi (N) Numero di repliche calico-typha
      N = 1 1
      1 < N < 200 2
      N >= 200 3 o più

    • Istio ingress-gateway è il componente per il supporto di Ingress del cluster e viene eseguito come Deployment sui nodi worker del cluster utente. A seconda della quantità di traffico gestita dal gateway in entrata, GKE su VMware utilizza Horizontal Pod Autoscaler per scalare il numero di repliche in base all'utilizzo della CPU, con un minimo di 2 repliche e un massimo di 5 repliche.

    • Il proxy di rete konnectivity (KNP) fornisce un proxy a livello TCP per il traffico in uscita dai nodi del piano di controllo dei cluster utente. Tiluna il traffico in uscita dall'utente kube-apiserver destinato ai nodi del cluster utente. L'agente Konnectivity viene eseguito come Deployment sui nodi worker del cluster utente. Google Distributed Cloud scala automaticamente il numero di repliche dell'agente di connettività in base al numero di nodi nel cluster.

      Numero di nodi (N) Numero di repliche dell'agente di connettività
      1 <= N <= 6 N
      6 < N < 10 6
      10 <= N < 100 8
      N >= 100 12 o più

best practice

Questa sezione descrive le best practice per la scalabilità delle risorse.

Scala il tuo cluster in più fasi

La creazione di un nodo Kubernetes comporta la clonazione del modello di immagine del sistema operativo del nodo in un nuovo file del disco, che è un'operazione vSphere ad alta intensità di I/O. Non esiste un isolamento di I/O tra l'operazione di clonazione e le operazioni di I/O dei carichi di lavoro. Se vengono creati troppi nodi contemporaneamente, il completamento delle operazioni di clonazione richiede molto tempo e potrebbe influire sulle prestazioni e sulla stabilità del cluster e dei carichi di lavoro esistenti.

Assicurati che lo scale up del cluster venga eseguito in più fasi a seconda delle risorse vSphere. Ad esempio, per ridimensionare un cluster da 3 a 500 nodi, valuta la possibilità di scalarlo in fasi da 150 a 350 a 500, in modo da ridurre il carico sull'infrastruttura vSphere.

Ottimizza le prestazioni I/O del disco etcd

etcd è un archivio chiave-valore utilizzato come backup di Kubernetes per tutti i dati del cluster. Le sue prestazioni e stabilità sono fondamentali per l'integrità di un cluster e sono sensibili alla latenza di I/O del disco e della rete.

  • Ottimizza le prestazioni di I/O del datastore vSphere utilizzato per le VM del piano di controllo seguendo questi suggerimenti:

  • Una latenza di alcune centinaia di millisecondi indica un collo di bottiglia sul disco o sull'I/O di rete, che potrebbe causare un integrità del cluster. Monitora e imposta soglie di avviso per le seguenti metriche di latenza I/O etcd:

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

Ottimizza le prestazioni di I/O del disco di avvio del nodo

I pod usano lo spazio di archiviazione temporaneo per le proprie operazioni interne, ad esempio per il salvataggio di file temporanei. L'archiviazione temporanea viene consumata dal livello accessibile in scrittura, dalla directory dei log e dai volumi emptyDir del container. L'archiviazione temporanea proviene dal file system del nodo GKE su VMware, che è supportato dal disco di avvio del nodo.

Poiché non esiste un isolamento I/O dell'archiviazione sui nodi Kubernetes, le applicazioni che consumano un I/O estremamente elevato nell'archiviazione temporanea possono potenzialmente causare instabilità dei nodi eliminando i componenti di sistema come Kubelet e il daemon docker delle risorse.

Assicurati che le caratteristiche delle prestazioni di I/O del datastore su cui viene eseguito il provisioning dei dischi di avvio possano fornire le prestazioni corrette per l'utilizzo da parte dell'applicazione del traffico di logging e archiviazione temporanea.

Monitora la contesa delle risorse fisiche

Tieni presente i proporzioni tra vCPU e pCPU e l'overcommitment della memoria. Un rapporto non ottimale o una contesa della memoria negli host fisici possono causare un peggioramento delle prestazioni della VM. Devi monitorare l'utilizzo delle risorse fisiche a livello di host e allocare risorse sufficienti per eseguire cluster di grandi dimensioni.