Questa pagina descrive le best practice per la creazione, la configurazione e il funzionamento dei cluster Anthos sui cluster VMware (GKE On-Prem) per adattarsi ai carichi di lavoro che si avvicinano ai limiti di scalabilità di Kubernetes.
Limiti di scalabilità
Tieni presente i seguenti limiti quando progetti le applicazioni su cluster Anthos su VMware:
Ciascun cluster di amministrazione supporta fino a 50 cluster utente, inclusi quelli a disponibilità elevata (HA) e non ad alta disponibilità, utilizzando la modalità di bilanciamento del carico in bundle (Seesaw) o la modalità di bilanciamento del carico integrata (F5).
Ogni cluster utente supporta fino a:
500 nodi utilizzando la modalità di bilanciamento del carico in bundle (Seesaw) o 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 250 servizi LoadBalancer utilizzando la modalità di bilanciamento del carico integrata (F5).
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.
Informazioni sui limiti
Poiché i cluster Anthos su VMware sono un sistema complesso con una grande superficie di integrazione, la scalabilità del cluster prevede molte dimensioni interconnesse. Ad esempio, i cluster Anthos su VMware possono scalare tramite il numero di nodi, pod o servizi. L'ampliamento di più di una dimensione alla volta può causare problemi anche nei cluster più piccoli. Ad esempio, la pianificazione di 110 pod per nodo in un cluster di 500 nodi può sovradimensionare 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 vSphere e all'hardware su cui è in esecuzione il cluster. Questi limiti vengono verificati in un ambiente che è probabilmente diverso dal tuo. Pertanto, non puoi riprodurre i numeri esatti quando l'ambiente sottostante è il fattore limitante.
Preparazione alla scalabilità
Durante la preparazione per la scalabilità dei cluster di amministrazione o dei cluster utente, considera i seguenti requisiti e limitazioni.
Requisiti di CPU, memoria e archiviazione
Consulta i requisiti di CPU, RAM e spazio di archiviazione per ogni singola VM.
Requisiti I/O disco e rete
I carichi di lavoro ad alta intensità di dati e alcuni componenti del piano di controllo sono sensibili alla latenza del disco e della rete I/O. Ad esempio, di solito sono necessarie 500 IOPS sequenziali (ad esempio, un tipico SSD locale o un dispositivo a blocchi virtualizzati 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 Cluster Anthos su VMware richiede un indirizzo DHCP o assegnato in modo statico.
Ad esempio, sono necessari 308 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 piano di controllo del cluster di amministrazione | 1 |
VM del nodo aggiuntivo del cluster di amministrazione | 3 |
VM del piano di controllo del cluster utente 1 (non ad alta disponibilità) | 1 |
VM del nodo cluster utente 1 | 50 |
VM del piano di controllo del cluster utente 2 (HA) | 3 |
VM nodo cluster 2 utente | 250 |
Totale | 314 |
Esecuzione di molti cluster utente in un cluster di amministrazione
Mentre ti prepari a eseguire molti cluster utente in un cluster di amministrazione, esegui i passaggi seguenti quando crei il cluster di amministrazione.
Blocco CIDR del pod nel cluster di amministrazione
Il blocco CIDR del pod è il blocco CIDR per tutti i pod in un cluster di amministrazione. È
configurato tramite il campo network.podCIDR
in admin-cluster.yaml
.
Da questo intervallo, a ogni nodo sono assegnati blocchi /24 più piccoli. Se hai bisogno di un cluster di amministrazione N, devi assicurarti che questo blocco sia abbastanza grande da supportare blocchi N /24.
Nella tabella seguente viene descritto il numero massimo di nodi supportati da diverse dimensioni di blocco CIDR dei pod:
Dimensione blocco CIDR pod | Numero massimo di nodi supportati |
---|---|
/18 | 64 |
/17 | 128 |
/16 | 256 |
/15 | 512 |
Il blocco CIDR pod predefinito di un cluster di amministrazione è 192.168.0.0/16, che supporta 256 nodi.
In un cluster di amministrazione con 50 cluster utente ad alta disponibilità (ogni cluster utente ha 3 nodi del piano di controllo), ci sono 1 nodo del piano di controllo del cluster di amministrazione, 2 nodi aggiuntivi del cluster di amministrazione e 150 nodi del piano di controllo del cluster utente. Il numero totale di nodi è inferiore a 256. Pertanto, il blocco CIDR del pod predefinito può supportare fino a 50 cluster utente ad alta disponibilità.
Blocco CIDR di servizio nel cluster di amministrazione
Il blocco CIDR di servizio è il blocco CIDR per tutti i servizi in un cluster di amministrazione.
È configurato tramite il campo network.serviceCIDR
in
admin-cluster.yaml
.
Nella tabella seguente viene descritto il numero massimo di servizi supportati dalle diverse dimensioni di blocco CIDR del servizio:
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 utilizza 5 servizi e il piano di controllo del cluster di amministrazione ne utilizza 13. Pertanto, per eseguire 50 cluster utente, devi modificare il blocco CIDR di servizio nel cluster di amministrazione in modo che utilizzi un intervallo /23.
Cloud Logging e Cloud Monitoring
Cloud Logging e Cloud Monitoring ti aiutano a 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.
La tabella seguente descrive la quantità di CPU del nodo del cluster di amministrazione e memoria richiesta per eseguire un numero elevato di cluster utente:
Numero di cluster utente | CPU del nodo di cluster di amministrazione | Memoria del nodo cluster di amministrazione |
---|---|---|
Da 0 a 10 | 4 CPU | 16 GB |
Da 11 a 20 | 4 CPU | 32 GB |
Da 20 a 50 | 4 CPU | 90GB |
Ad esempio, se ci sono 2 nodi cluster di amministrazione e ciascuno ha 4 CPU e 16 GB di memoria, puoi eseguire da 0 a 10 cluster utente. Per creare più di 20 cluster utente, devi prima ridimensionare la memoria dei nodi del cluster di amministrazione da 16 GB a 90 GB.
Per cambiare la memoria del nodo aggiuntivo del cluster di amministrazione, modifica la configurazione di MachineDeployment:
Esegui questo comando:
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node
dove ADMIN_CLUSTER_KUBECONFIG è il percorso del file kubeconfig per il cluster di amministrazione.
Cambia il campo
spec.template.spec.providerSpec.value.machineVariables.memory
in32768
.Salva la modifica. I nodi del cluster di amministrazione vengono ricreati con 32 GB di memoria.
GKE Hub
Per impostazione predefinita, puoi registrare un massimo di 15 cluster utente. Per registrare altri cluster in GKE Hub, puoi inviare una richiesta per aumentare la quota in Google Cloud Console.
Esecuzione di molti nodi e pod in un cluster utente
Mentre ti prepari a eseguire molti nodi e pod in un cluster utente, esegui i passaggi seguenti durante la creazione del cluster utente.
Blocco CIDR pod nel cluster utente
Il blocco CIDR del pod è il blocco CIDR per tutti i pod in un cluster utente. È
configurato tramite il campo network.podCIDR
in user-cluster.yaml
.
Da questo intervallo, viene assegnato un blocco /24 più piccolo a ogni nodo. Se hai bisogno di un cluster N nodi, devi assicurarti che questo blocco sia abbastanza grande da supportare blocchi N /24.
Nella tabella seguente viene descritto il numero massimo di nodi supportati da diverse dimensioni di blocco CIDR dei pod:
Dimensione blocco CIDR pod | Numero massimo di nodi supportati |
---|---|
/18 | 64 |
/17 | 128 |
/16 | 256 |
/15 | 512 |
Il blocco CIDR pod predefinito è 192.168.0.0/16, che supporta 256 nodi. Ad esempio, per creare un cluster con 500 nodi, devi cambiare il blocco CIDR del pod nel cluster utente per utilizzare un intervallo /15.
Blocco CIDR di servizio nel cluster utente
Il blocco CIDR di servizio è il blocco CIDR per tutti i servizi in un cluster utente. È
configurato tramite il campo network.serviceCIDR
in user-cluster.yaml
.
Nella tabella seguente viene descritto il numero massimo di servizi supportati dalle diverse dimensioni di blocco CIDR del servizio:
Dimensione blocco CIDR servizio | Numero massimo di servizi supportati |
---|---|
/21 | 2048 |
/20 | 4096 |
/19 | 8.192 |
/18 | 16.384 |
Il valore predefinito è 10.96.0.0/20, che supporta 4096 servizi. Il blocco CIDR di servizio predefinito consente di creare un cluster con 500 servizi, che è il numero massimo di cluster Anthos di tipo LoadBalancer su VMware supportati in un cluster utente.
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 descrive la quantità di CPU del nodo del cluster di amministrazione e memoria richiesta per eseguire un numero elevato di cluster utente:
Numero di nodi | CPU del nodo del piano di controllo del cluster utente | Memoria del nodo piano di controllo del cluster utente |
---|---|---|
Da 0 a 250 | 4 CPU | 8 GB |
Da 250 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
.
Piano dati v2
Per i cluster utente a 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 tue risorse.
L'utilizzo di CPU e memoria da parte degli agenti in-cluster di cui è stato eseguito il deployment in un cluster utente scala in termini di numero di nodi e pod in un cluster utente.
I componenti di logging e monitoraggio del cloud come prometheus-server
e stackdriver-prometheus-sidecar
hanno un utilizzo diverso di CPU e memoria in base al numero di nodi e al numero di pod. Prima di fare lo scale up del cluster, imposta la richiesta di risorse e il limite in base all'utilizzo medio stimato di questi componenti. La tabella riportata di seguito 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 | server-prometheus | 100m | 390m | 650 mln | 1.3G |
sidecar stackdriver-prometheus | 100m | 340m | 1.5G | 1.6G | |
Da 51 a 100 | server-prometheus | 160m | 500m | 1,8 G | 5.5G |
sidecar stackdriver-prometheus | 200m | 500m | 1,9 G | 5.7G | |
Da 101 a 250 | server-prometheus | 400m | 2500m | 6.5G | 16G |
sidecar stackdriver-prometheus | 400m | 1300m | 7.5G | 12G | |
Da 250 a 500 | server-prometheus | 1200m | 2600m | 22G | 25G |
sidecar stackdriver-prometheus | 400m | 2250m | 65G | 78 g |
Assicurati di avere nodi abbastanza grandi per pianificare i componenti di Cloud Logging e Cloud Monitoring. Un modo per farlo è prima creare un cluster di piccole dimensioni, modificare le risorse del componente Cloud Logging e Cloud Monitoring in base alla tabella riportata sopra, creare un pool di nodi per ospitare i componenti e, quindi, scalare gradualmente il cluster a una dimensione maggiore.
Puoi scegliere di mantenere un pool di nodi abbastanza grande da consentire la pianificazione dei componenti di monitoraggio e logging per 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
Questo impedisce la pianificazione di altri componenti nel pool di nodi e impedisce l'eliminazione dei carichi di lavoro degli utenti a causa del consumo delle risorse da parte dei componenti di monitoraggio.
Bilanciatore del carico
I servizi discussi in questa sezione si riferiscono ai servizi Kubernetes con il 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), è 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 servizi locali locali. Un servizio locale per il traffico è un servizio il cui
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 quello integrato (F5):
Bilanciamento del carico in bundle (Seesaw) | Bilanciamento del carico integrato (F5) | |
---|---|---|
Numero massimo di servizi | 500 | 250 2 |
Numero 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 per il traffico 1 | N/D 2 |
1 Ad esempio, supponiamo che tu abbia 100 nodi e 99 servizi locali di traffico. Il numero di controlli di integrità è 100 + (99 * 100) = 10.000, che è compreso nel 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 delle istanze virtuali e le licenze.
Componenti del sistema a scalabilità automatica
Cluster Anthos su VMware scala automaticamente i componenti di sistema nei cluster utente in base al numero di nodi senza alcun bisogno di modificare le configurazioni. Puoi utilizzare le informazioni contenute in questa sezione per la pianificazione delle risorse.
I cluster Anthos su VMware eseguono automaticamente la scalabilità verticale scalando le richieste di CPU/memoria e i limiti 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 richiesta e i limiti di CPU e memoria vengono scalati in base al numero di nodi.
La tabella seguente descrive le richieste di risorse/i limiti impostati dal sistema, in base al numero di nodi in un cluster:
Numero di nodi Approssimato1 richiesta/limite della CPU (millisecondi) Approssimato1 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 pari a +-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 viene impostato su 150 m/150 m e la richiesta/il limite di memoria viene impostato su 200 Mi/200 Mi. In un cluster con 250 nodi, il limite/richiesta 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 integrate in Kubernetes. Le richieste e i limiti di CPU e memoria scalano in base al numero di nodi.
I cluster Anthos su VMware eseguono automaticamente la scalabilità orizzontale sia nei cluster di amministrazione che nei cluster utente scalando il numero di repliche dei seguenti componenti di sistema:
kube-dns è la soluzione DNS utilizzata per il Service Discovery nei cluster Anthos su VMware. Viene eseguito come deployment sui nodi worker del cluster utente. Cluster Anthos 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 incrementata/ridotta la replica. Se hai un cluster di nodi
N
eC
core, puoi aspettartimax(N/16, C/256)
repliche. Nota che kube-dns supporta 1500 richieste in parallelo al secondo.calico-typha è un componente per il supporto di networking di pod nei cluster Anthos su VMware. Viene eseguito come deployment sui nodi worker del cluster utente. Cluster Anthos 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ù ingress-gateway/istio-pilot sono i componenti che supportano il cluster in entrata e vengono eseguiti come deployment sui nodi worker di un cluster utente. A seconda della quantità di traffico in entrata nel gateway, i cluster Anthos su VMware utilizzano il Horizontal Pod Autoscaler per scalare il numero di repliche in base al loro utilizzo della CPU, con un minimo di 2 repliche e un massimo di 5 repliche.
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 prevede la clonazione del modello di immagine del sistema operativo del nodo in un nuovo file di disco, che è un'operazione vSphere a elevato utilizzo di I/O. Non vi è alcun isolamento I/O tra le operazioni di clonazione e quelle di I/O per i carichi di lavoro. Se vengono creati troppi nodi contemporaneamente, il completamento delle operazioni di clonazione richiede molto tempo e può influire sulle prestazioni e sulla stabilità del cluster e dei carichi di lavoro esistenti.
Assicurati che il cluster venga scalato per 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-500, il che aiuta a ridurre il carico sull'infrastruttura vSphere.
Ottimizza prestazioni I/O disco etcd
etcd è un archivio chiave valore utilizzato come archivio 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 I/O del datastore vSphere utilizzato per le VM del piano di controllo seguendo questi suggerimenti:
- Segui i requisiti hardware etcd.
- Utilizza SSD o tutto lo spazio di archiviazione Flash.
La latenza di alcune centinaia di millisecondi indica un collo di bottiglia sul disco o sull'I/O di rete e può causare un cluster in stato non integro. Monitora e imposta le 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 utilizzano spazio di archiviazione temporaneo per le loro operazioni interne, ad esempio per il salvataggio di 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 dai cluster Anthos sul file system del nodo VMware, che è supportato dal disco di avvio del nodo.
Dal momento che non esiste un isolamento I/O di archiviazione sui nodi Kubernetes, le applicazioni che consumano I/O estremamente elevati nello spazio di archiviazione temporaneo possono causare instabilità dei nodi ingombrando i componenti di sistema come Kubelet e il daemon docker delle risorse.
Assicurati che le caratteristiche relative alle prestazioni I/O del datastore su cui è stato eseguito il provisioning dei dischi di avvio possono fornire le giuste prestazioni per l'utilizzo da parte dell'applicazione del traffico temporaneo di archiviazione e logging.
Monitora le contese delle risorse fisiche
Tieni presente i report tra vCPU e pCPU e il commissione di overcommit della memoria. Un rapporto non ottimale o una contesa di memoria negli host fisici possono causare un peggioramento delle prestazioni della VM. Dovresti monitorare l'utilizzo delle risorse fisiche a livello di host e allocare risorse sufficienti per eseguire i cluster di grandi dimensioni.