In questa pagina vengono descritte le best practice per creare, configurare e utilizzare i cluster Google Distributed Cloud al fine di supportare 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à
Prendi in considerazione i seguenti limiti quando progetti le tue applicazioni su GKE on VMware:
Ogni cluster di amministrazione supporta fino a 100 cluster utente, inclusi i cluster utente ad alta disponibilità (HA) e non ad alta disponibilità, utilizzando la modalità di bilanciamento del carico in bundle (Seesaw o MetalLB) o la modalità di bilanciamento del carico integrato (F5).
Ogni cluster utente supporta fino a:
500 nodi utilizzando la modalità di bilanciamento del carico in bundle (Seesaw o MetalLB) oppure 250 nodi utilizzando la modalità di bilanciamento del carico integrata (F5)
15.000 pod
500 servizi LoadBalancer utilizzando la modalità di bilanciamento del carico in bundle (Seesaw o MetalLB) oppure 250 servizi LoadBalancer che utilizzano la modalità di bilanciamento del carico integrato (F5).
Per ogni nodo puoi creare un massimo di 110 pod (ciascun pod può essere composto da 1-2 container). Sono inclusi i pod che eseguono servizi di sistema aggiuntivi.
Informazioni sui limiti
Poiché GKE on VMware è un sistema complesso con un'ampia superficie di integrazione, la scalabilità del cluster richiede molte dimensioni correlate. Ad esempio, GKE on VMware può scalare attraverso il numero di nodi, pod o servizi. L'estensione di più dimensioni contemporaneamente può causare problemi anche in cluster più piccoli. Ad esempio, la pianificazione di 110 pod per nodo in un cluster da 500 nodi può causare un sovraccarico del 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. Potresti quindi non riprodurre i numeri esatti quando l'ambiente sottostante è il fattore limitante.
Preparazione della scalabilità in corso...
Prima di prepararti a scalare i cluster di amministrazione o i cluster utente, considera i requisiti e le limitazioni seguenti.
Requisiti di CPU, memoria e spazio di archiviazione
Vedi i requisiti di CPU, RAM e spazio di archiviazione per ogni singola VM.
Requisiti di I/O per disco e 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 del disco e della rete. Ad esempio, sono generalmente necessarie 500 IOPS sequenziali (ad esempio un tipico SSD locale o un dispositivo a blocchi virtualizzato ad alte prestazioni) per le prestazioni e la stabilità di etcd in un cluster con decine di nodi e migliaia di pod.
Indirizzo IP del nodo
Ogni nodo GKE on VMware 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 seguente tabella 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 del 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 | 296 |
Esecuzione di molti cluster utente in un cluster di amministrazione
Mentre ti prepari a eseguire molti cluster utente in un cluster di amministrazione, esegui 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.
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 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 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 abbastanza grande da supportare blocchi N /24.
La tabella seguente descrive il numero massimo di nodi supportati da diverse dimensioni dei blocchi CIDR dei pod:
| Dimensione blocco CIDR 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 disponibilità, sono presenti 3 nodi del piano di controllo del cluster di amministrazione e 300 nodi del piano di controllo del cluster utente. Il numero totale di nodi è 303 (più di 256). Devi quindi aggiornare il blocco CIDR dei pod a /15, per supportare fino a 100 cluster utente kubeception ad alta disponibilità.
Per configurare il blocco CIDR dei 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 di un cluster di amministrazione.
Viene configurato tramite il campo network.serviceCIDR in admin-cluster.yaml.
Nella tabella seguente viene descritto il numero massimo di servizi supportati dalle diverse dimensioni dei blocchi CIDR dei servizi:
| Dimensione 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. 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
Cloud Logging e Cloud Monitoring ti aiutano a monitorare le 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 seguente tabella descrive la quantità di CPU e memoria dei nodi 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 |
| Da 11 a 20 | 4 CPU | 32 GB |
| Da 20 a 100 | 4 CPU | 90GB |
Ad esempio, se sono presenti 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 altri cluster in GKE Hub, puoi inviare una richiesta di aumento della quota nella console Google Cloud:
Esecuzione di molti nodi e pod in un cluster utente
Mentre ti prepari a eseguire molti nodi e pod in un cluster utente, esegui questi passaggi quando crei il 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 a N nodi, devi assicurarti che questo blocco sia abbastanza grande da supportare blocchi N /24.
La tabella seguente descrive il numero massimo di nodi supportati da diverse dimensioni dei blocchi CIDR dei pod:
| Dimensione 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 che utilizzi un intervallo /15.
Blocco CIDR del servizio nel cluster utente
Il blocco CIDR dei servizi è il blocco CIDR per tutti i servizi di un cluster utente.
Viene configurato tramite il campo network.serviceCIDR in user-cluster.yaml.
Nella tabella seguente viene descritto il numero massimo di servizi supportati dalle diverse dimensioni dei blocchi CIDR dei servizi:
| Dimensione 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 scala in base al numero di nodi nel cluster utente.
La tabella seguente fornisce la CPU e la memoria necessarie per un nodo del piano di controllo del 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 da 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 aiutano a monitorare le risorse.
L'utilizzo di CPU e memoria 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 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 delle 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 CPU stimato | Utilizzo memoria stimato | ||
|---|---|---|---|---|---|
| 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 | 340m | 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 | 16 GB |
| stackdriver-prometheus-sidecar | 400m | 1.300 m | 7,5 G | 12 GB | |
| Da 250 a 500 | prometheus-server | 1.200 m | 2.600 m | 22 GB | 25 GB |
| stackdriver-prometheus-sidecar | 400m | 2250m | 65 GB | 78 GB | |
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 Cloud Logging e Cloud Monitoring in base alla tabella precedente, creare un pool di nodi per ospitare i componenti e quindi fare gradualmente lo scale up del cluster per ottenere una dimensione maggiore.
Puoi scegliere di mantenere un pool di nodi abbastanza grande per i componenti di monitoraggio e logging al fine di impedire la pianificazione di altri pod per il pool di nodi. Per farlo, devi aggiungere le seguenti incompatibilità al pool di nodi:
taints:
- effect: NoSchedule
key: node-role.gke.io/observability
Questo impedisce la pianificazione di altri componenti nel pool di nodi e impedisce l'eliminazione dei carichi di lavoro utente a causa del consumo di risorse da parte dei componenti di monitoraggio.
Bilanciatore del carico
I servizi discussi in questa sezione fanno riferimento 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 di 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) | |
|---|---|---|
| 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 ed L è il numero di traffico di servizi locali 1 | N/D2 |
1 Ad esempio, supponiamo che tu abbia 100 nodi e 99 servizi locali con traffico. Il numero di controlli di integrità è 100 + (99 * 100) = 10.000, entro il limite di 10.000.
2 Consulta F5 per ulteriori informazioni. Questo numero dipende da fattori come il numero di modello hardware F5, la CPU/memoria dell'istanza virtuale e le licenze.
Scalabilità automatica dei componenti del sistema
GKE on VMware scala automaticamente i componenti di sistema nei cluster utente in base al numero di nodi, senza dover modificare le configurazioni. Puoi usare le informazioni in questa sezione per la pianificazione delle risorse.
GKE on VMware esegue automaticamente la scalabilità verticale scalando le richieste/i 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. La scalabilità delle richieste e dei limiti di CPU e memoria in base al numero di nodi.
La tabella seguente descrive le richieste/i limiti delle risorse impostati dal sistema, in base al numero di nodi di un cluster:
Numero di nodi Approssimativamente1 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 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 è impostato su 150 m/150 m, mentre la richiesta/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 la richiesta/il limite di memoria è impostato su 600 Mi.
metrics-server è un deployment in esecuzione su nodi worker del cluster utilizzato dalle pipeline di scalabilità automatica incorporate di Kubernetes. La richiesta di CPU e memoria limita la scalabilità in base al numero di nodi.
GKE on 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 on VMware. Viene eseguito come deployment sui nodi worker del cluster utente. GKE on VMware scala automaticamente il numero di repliche in base al numero di nodi e core CPU nel cluster. Con ogni aggiunta/eliminazione di 16 nodi o 256 core, 1 replica viene aumentata/diminuita. Se hai un cluster di
Nnodi eCcore, puoi prevederemax(N/16, C/256)repliche.calico-typha è un componente per il supporto del networking di pod in GKE on VMware. Viene eseguito come deployment sui nodi worker del cluster utente. GKE on VMware scala automaticamente il numero di repliche calico-typha in base al numero di nodi nel cluster:
Numero di nodi (N) Numero di repliche del calico-tifa N = 1 1 1 < N < 200 2 N >= 200 3 o più Istio ingress-gateway è il componente per il supporto del traffico in entrata nel cluster e viene eseguito come deployment sui nodi worker del cluster utente. A seconda della quantità di traffico gestita dal gateway in entrata, GKE on 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 del cluster utente. Tunnela il traffico in uscita dell'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 knowledge base in base al numero di nodi nel cluster.
Numero di nodi (N) Numero di repliche dell'agente di knowledge base 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 modello di immagine del sistema operativo del nodo in un nuovo file disco, che è un'operazione vSphere che richiede un uso intensivo di I/O. Non esiste isolamento 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 potrebbero influire sulle prestazioni e sulla stabilità del cluster e sui carichi di lavoro esistenti.
Assicurati che la scalabilità del cluster venga eseguita 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 chiave-valore utilizzato come archivio di supporto 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 I/O del datastore vSphere utilizzato per le VM del piano di controllo seguendo questi suggerimenti:
- Segui i requisiti hardware etcd.
- Usa SSD o tutte le unità di archiviazione flash.
Una latenza di poche centinaia di millisecondi indica un collo di bottiglia sul disco o I/O di rete e potrebbe causare un malfunzionamento del cluster. Monitora e imposta le soglie di avviso per le seguenti metriche di latenza I/O etcd:
etcd_disk_backend_commit_duration_secondsetcd_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 operazioni interne, ad esempio il salvataggio dei file temporanei. L'archiviazione temporanea viene utilizzata dal livello accessibile in scrittura del container, dalla directory dei log e dai volumi emptyDir. L'archiviazione temporanea proviene dal file system del nodo GKE on VMware, supportato dal disco di avvio del nodo.
In assenza di isolamento I/O di archiviazione sui nodi Kubernetes, le applicazioni che consumano un I/O estremamente elevato nell'archiviazione temporanea possono causare instabilità dei nodi eliminando i componenti di sistema come Kubelet e il daemon Docker delle risorse.
Assicurati che le caratteristiche delle prestazioni I/O del datastore in cui viene eseguito il provisioning dei dischi di avvio possano fornire le prestazioni giuste per l'utilizzo dell'archiviazione temporanea e del traffico di logging da parte dell'applicazione.
Monitora la contesa delle risorse fisiche
Presta attenzione al rapporto tra vCPU e pCPU e all'overcommitment della memoria. Un rapporto non ottimale o un conflitto di 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 cluster di grandi dimensioni.