Scalabilità

Questa pagina descrive le best practice per la creazione, la configurazione e il funzionamento dei cluster creati utilizzando il software Google Distributed Cloud solo per VMware per gestire i workload 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 che si trovano all'interno di un singolo progetto Google Cloud .

Limiti di scalabilità

Tieni conto dei seguenti limiti quando progetti le tue applicazioni:

  • Se il cluster avanzato non è abilitato:

    • Ogni cluster di amministrazione supporta fino a 100 cluster utente, inclusi i cluster utente ad alta affidabilità (HA) e non HA, utilizzando la modalità di bilanciamento del carico integrato (MetalLB) o il (bilanciamento manuale del carico).

    • Ogni cluster utente supporta fino a:

      • 500 nodi che utilizzano la modalità di bilanciamento del carico integrato (MetalLB)

      • 15.000 pod

      • 500 servizi LoadBalancer che utilizzano la modalità di bilanciamento del carico integrato (MetalLB).

    • Per ogni nodo, puoi creare un massimo di 110 pod (ogni pod può essere composto da 1-2 container). Sono inclusi i pod che eseguono servizi di sistema aggiuntivi.

  • Se il cluster avanzato è abilitato

    • Ogni cluster di amministrazione supporta fino a 100 cluster utente, che devono essere cluster ad alta affidabilità (HA) e utilizzare la modalità di bilanciamento del carico integrato (MetalLB) o il bilanciamento manuale del carico.

    • Ogni cluster utente supporta fino a:

      • 500 nodi che utilizzano la modalità di bilanciamento del carico integrato (MetalLB).

      • 15.000 pod

      • 500 servizi LoadBalancer che utilizzano la modalità di bilanciamento del carico integrato (MetalLB).

    • Per ogni nodo, puoi creare un massimo di 110 pod (ogni pod può essere composto da 1-2 container). Sono inclusi i pod che eseguono servizi di sistema aggiuntivi.

    • Il numero totale di nodi, che include i nodi del control plane del cluster di amministrazione + tutti i nodi del control plane del cluster utente + i nodi worker, non deve superare i 500 nodi.

Informazioni sui limiti

Poiché Google Distributed Cloud è un sistema complesso con un'ampia superficie di integrazione, la scalabilità dei cluster coinvolge molte dimensioni correlate. Ad esempio, Google Distributed Cloud può scalare in base al numero di nodi, pod o servizi. L'estensione di più di una dimensione alla volta può causare problemi anche in cluster più piccoli. Ad esempio, la pianificazione di 110 pod per nodo in un cluster di 500 nodi può sovraccaricare il numero di pod, pod per nodo e nodi.

Per ulteriori dettagli, consulta le soglie di scalabilità di Kubernetes.

I limiti di scalabilità sono inoltre sensibili alla configurazione vSphere e all'hardware su cui è in esecuzione il cluster. Questi limiti vengono verificati in un ambiente che 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, tieni presente i seguenti requisiti e limitazioni.

Requisiti per CPU, memoria e spazio di archiviazione

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

Requisiti di I/O di disco e rete

I workload ad alta intensità di dati e alcuni componenti del control plane sono sensibili alla latenza di I/O del disco e della 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'unità SSD locale tipica o un dispositivo a blocchi virtualizzato ad alte prestazioni).

Indirizzo IP del nodo

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

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

La tabella seguente mostra la suddivisione degli indirizzi IP:

Tipo di nodo Numero di indirizzi IP
VM del control plane del cluster di amministrazione 3
VM del control plane del cluster utente 1 (non ad alta disponibilità) 1
VM dei nodi worker del cluster utente 1 50
VM del control plane del cluster utente 2 (HA) 3
VM dei nodi 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 durante la creazione del cluster di amministrazione.

Blocco CIDR dei pod nel cluster di amministrazione

Il blocco CIDR dei pod è il blocco CIDR per tutti i pod in un cluster di amministrazione. Viene configurato tramite il campo network.podCIDR in admin-cluster.yaml.

Da questo intervallo, vengono assegnati blocchi /24 più piccoli a ciascun nodo. Se tutti i tuoi cluster utente hanno Controlplane V2 abilitato, il tuo cluster di amministrazione ha solo tre nodi e sono disponibili molti indirizzi IP dei pod. Tuttavia, ogni volta che crei un cluster utente che utilizza kubeception anziché Controlplane V2, vengono aggiunti uno o tre nodi al cluster di amministrazione:

  • Ogni cluster utente kubeception ad alta affidabilità (HA) aggiunge tre nodi al cluster di amministrazione.

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

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

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

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

Il blocco CIDR dei pod predefinito 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 affidabilità, sono presenti 3 nodi del control plane del cluster di amministrazione e 300 nodi del control plane del cluster utente. Il numero totale di nodi è 303 (più di 256). Pertanto, devi aggiornare il blocco CIDR dei pod a /15 per supportare fino a 100 cluster utente kubeception ad alta affidabilità.

Per configurare il blocco CIDR del 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 dei servizi è il blocco CIDR per tutti i servizi in un cluster di amministrazione. Viene configurato 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:

Dimensione del blocco CIDR del 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 control plane del cluster di amministrazione utilizza 14 servizi. Pertanto, per eseguire 100 cluster utente kubeception, devi modificare il blocco CIDR del servizio nel cluster di amministrazione in modo che utilizzi un intervallo /22.

Cloud Logging e Cloud Monitoring per i cluster utente kubeception

Cloud Logging e Cloud Monitoring ti aiutano a monitorare le tue risorse.

L'utilizzo di CPU e memoria utilizzata 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 del nodo del cluster di amministrazione
Da 0 a 10 4 CPU 16 GB
11-20 4 CPU 32 GB
Da 20 a 100 4 CPU 90GB

Ad esempio, se sono presenti 2 nodi del cluster di amministrazione e ciascuno 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 del nodo del cluster di amministrazione da 16 GB a 90 GB.

Nodi del cluster di amministrazione quando sono abilitati i cluster avanzati

L'utilizzo della CPU e la memoria utilizzata dei componenti del ciclo di vita di cui è stato eseguito il deployment in un cluster di amministrazione vengono scalati in base al numero totale di tutti i nodi (il numero totale di nodi, che include i nodi del control plane del cluster di amministrazione + tutti i nodi del control plane del cluster utente + i nodi worker)

La tabella seguente descrive la quantità di CPU e memoria dei nodi del cluster di amministrazione necessaria per eseguire un numero elevato di tutti i nodi che gestisce:

Numero totale di nodi CPU del nodo del cluster di amministrazione Memoria del nodo del cluster di amministrazione
Da 0 a 20 4 CPU 16 GB
Da 21 a 100 8 CPU 16 GB
Da 101 a 500 16 CPU 32 GB

Ad esempio, se sono presenti 3 nodi del cluster di amministrazione e ciascuno ha 4 CPU e 16 GB di memoria, puoi eseguire un cluster utente ad alta affidabilità con 14 nodi worker. Per creare più di 20 cluster utente avanzati, ciascuno con più di 10 nodi, devi prima ridimensionare la memoria dei nodi del cluster di amministrazione da 16 GB a 32 GB.

GKE Hub

Per impostazione predefinita, puoi registrare un massimo di 250 cluster con appartenenze globali per parco risorse. Per registrare più cluster in GKE Hub, puoi inviare una richiesta per aumentare la quota nella console Google Cloud :

Vai a Quote

Per saperne di più sulle quote dei cluster in base alle impostazioni di appartenenza, consulta Quote di allocazione.

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 dei pod è il blocco CIDR per tutti i pod in un cluster utente. Viene configurato tramite il campo network.podCIDR in user-cluster.yaml.

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

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

Dimensione del blocco CIDR dei 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 del 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:

Dimensione del blocco CIDR del servizio Numero massimo di servizi supportati
/21 2048
/20 4096
/19 8192
/18 16.384

Nodi del control plane del cluster utente

La memoria utilizzata dai componenti del control plane del cluster utente viene scalata in base al numero di nodi nel cluster utente.

La tabella seguente mostra la CPU e la memoria richieste da un nodo del control plane del cluster utente in base alle dimensioni del cluster utente:

Numero di nodi del cluster utente CPU del nodo del control plane Memoria del nodo del control plane
Da 0 a 20 3 CPU 5 GB
21-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 i nodi del control plane del cluster utente con almeno 16 GB di memoria.

La specifica del nodo del control plane del cluster utente può essere modificata tramite il campo masterNode in user-cluster.yaml.

Dataplane V2

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

Cloud Logging e Cloud Monitoring

Cloud Logging e Cloud Monitoring ti aiutano a monitorare le tue risorse.

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

I componenti di Cloud Logging e Monitoring come prometheus-server e stackdriver-prometheus-sidecar hanno un utilizzo diverso delle risorse di CPU e memoria in base al numero di nodi e 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 tabella seguente mostra le stime per la quantità media di utilizzo per ogni componente:

Numero di nodi Nome container Utilizzo della CPU stimato Memoria utilizzata stimata
0 pod/nodo 30 pod/nodo 0 pod/nodo 30 pod/nodo
Da 3 a 50 prometheus-server 100m 390m 650 mln 1,3 G
stackdriver-prometheus-sidecar 100m 340 mln 1.5G 1.6G
Da 51 a 100 prometheus-server 160m 500m 1.8G 5.5G
stackdriver-prometheus-sidecar 200m 500m 1,9 G 5,7 G
Da 101 a 250 prometheus-server 400m 2500m 6.5G 16G
stackdriver-prometheus-sidecar 400m 1300m 7.5G 12G
Da 250 a 500 prometheus-server 1200m 2600m 22G 25G
stackdriver-prometheus-sidecar 400m 2250m 65G 78G

Assicurati di avere nodi abbastanza grandi da 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 di Cloud Logging e Cloud Monitoring in base alla tabella riportata sopra, creare un node pool per ospitare i componenti e poi fare lo scale up graduale del cluster fino a una dimensione maggiore.

Puoi scegliere di mantenere un pool di nodi di dimensioni sufficienti per i componenti di monitoraggio e logging per impedire la pianificazione di altri pod nel pool di nodi. Per farlo, devi aggiungere i seguenti taint 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 l'espulsione dei workload degli utenti a causa del consumo di risorse dei componenti di monitoraggio.

Bilanciatore del carico

I servizi discussi in questa sezione si riferiscono ai servizi Kubernetes con tipo LoadBalancer.

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

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

La tabella seguente 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)
Max Services 500 250 2
N. massimo di nodi 500 250 2
Numero massimo di controlli di integrità N + (L * N) <= 10.000, dove N è il numero di nodi e L è il numero di servizi locali di traffico 1 N/A 2

1 Ad esempio, supponiamo che tu abbia 100 nodi e 99 servizi locali per il traffico. Il numero di controlli di integrità è 100 + (99 * 100) = 10.000, che rientra nel limite di 10.000.

2 Per saperne di più, consulta F5. Questo numero è influenzato da fattori come il numero di modello dell'hardware F5, la CPU/memoria dell'istanza virtuale e le licenze.

Componenti di sistema con scalabilità automatica

Google Distributed Cloud scala automaticamente i componenti di sistema nei cluster utente in base al numero di nodi, senza che tu debba modificare le configurazioni. Puoi utilizzare le informazioni contenute in questa sezione per la pianificazione delle risorse.

  • Google Distributed Cloud esegue automaticamente lo scale up e lo scale down verticali delle richieste/limiti di CPU e memoria dei seguenti componenti di sistema utilizzando addon-resizer:

    • kube-state-metrics è un deployment in esecuzione sui nodi worker del cluster che ascolta il server API Kubernetes e genera metriche sullo stato degli oggetti. La richiesta e i limiti di CPU e memoria vengono scalati in base al numero di nodi.

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

      Numero di nodi Richiesta/limite di CPU approssimativo1 (milli) Richiesta/limite di memoria approssimativa1 (Mi)
      3-5 105 110
      Da 6 a 500 100 + num_nodes 100 + (2 * num_nodes)

      1 Esiste un margine di +/-5% per ridurre il numero di riavvii dei componenti durante la scalabilità.

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

    • metrics-server è un deployment in esecuzione sui nodi worker del cluster utilizzato dalle pipeline di scalabilità automatica integrate di Kubernetes. La richiesta e i limiti di CPU e memoria vengono scalati in base al numero di nodi.

  • Google Distributed Cloud esegue automaticamente la scalabilità orizzontale sia nei cluster di amministrazione sia nei cluster utente, scalando il numero di repliche dei seguenti componenti di sistema:

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

    • calico-typha è un componente per supportare il networking dei pod. Viene eseguito come deployment sui nodi worker del cluster utente. Google Distributed Cloud 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 supportare l'accesso al cluster e viene eseguito come deployment sui nodi worker del cluster utente. A seconda della quantità di traffico gestita da ingress-gateway, Google Distributed Cloud 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 control plane del cluster utente. Incanala il traffico in uscita del kube-apiserver dell'utente 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 konnectivity in base al numero di nodi nel cluster.

      Numero di nodi (N) Numero di repliche dell'agente konnectivity
      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 cluster in più fasi

La creazione di un nodo Kubernetes comporta la clonazione del template dell'immagine 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 del workload. Se vengono creati troppi nodi contemporaneamente, le operazioni di clonazione richiedono molto tempo per essere completate e potrebbero influire sulle prestazioni e sulla stabilità del cluster e dei workload esistenti.

Assicurati che il cluster venga scalato in 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 di I/O del disco etcd

etcd è un archivio di coppia chiave-valore utilizzato come archivio di backup di Kubernetes per tutti i dati del cluster. Le sue prestazioni e la sua 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 control plane seguendo questi consigli:

  • Una latenza di alcune centinaia di millisecondi indica un collo di bottiglia sul disco o sull'I/O di rete e potrebbe causare un cluster non integro. Monitora e imposta le soglie di avviso per le seguenti metriche di latenza di I/O di 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 utilizzano l'archiviazione temporanea per le operazioni interne, come il salvataggio di file temporanei. L'archiviazione temporanea viene utilizzata dal livello scrivibile del container, dalla directory dei log e dai volumi emptyDir. L'archiviazione temporanea proviene dal file system del nodo, supportato dal disco di avvio del nodo.

Poiché non esiste un isolamento dell'I/O di archiviazione sui nodi Kubernetes, le applicazioni che consumano un I/O estremamente elevato sul loro spazio di archiviazione temporaneo possono potenzialmente causare instabilità dei nodi privando di risorse i componenti di sistema come Kubelet e il daemon Docker.

Assicurati che le caratteristiche delle prestazioni di I/O del datastore su cui è stato eseguito il provisioning dei dischi di avvio possano fornire le prestazioni adeguate per l'utilizzo dello spazio di archiviazione temporaneo e del traffico di logging da parte dell'applicazione.

Monitora la contesa delle risorse fisiche

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