In questa pagina vengono descritte le best practice per la creazione, la configurazione e l'utilizzo dei cluster GKE On-Prem, per gestire i carichi di lavoro che si avvicinano ai limiti di stabilità di Kubernetes.
Limiti di scalabilità
Tieni presente i seguenti limiti quando progetti le applicazioni su GKE On-Prem:
Ogni cluster di amministrazione supporta fino a 20 cluster utente, inclusi quelli a disponibilità elevata (HA) e non.
Ogni cluster utente supporta fino a:
250 nodi
7500 pod
500 servizi LoadBalancer in modalità di bilanciamento del carico in bundle (Seesaw) o 250 servizi LoadBalancer in 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é GKE On-Prem è un sistema complesso con una grande superficie di integrazione, la scalabilità del cluster prevede molte dimensioni intercorrelate. Ad esempio, GKE On-Prem può scalare attraverso 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 da 250 nodi può sovraccaricare 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à
Mentre ti prepari a scalare, considera i requisiti e le limitazioni per l'infrastruttura vSphere, il networking di Kubernetes, GKE Hub, Cloud Logging e Cloud Monitoring.
Infrastruttura vSphere
Questa sezione illustra le considerazioni sulla scalabilità per i requisiti di CPU, memoria, archiviazione, disco e I/O di rete, oltre agli indirizzi IP dei nodi.
Requisiti di CPU, memoria e archiviazione
I seguenti requisiti si applicano alle VM del piano di controllo:
Il piano di controllo e i nodi aggiuntivi del cluster di amministrazione possono supportare fino a 20 cluster utente, inclusi i cluster utente ad alta disponibilità e non ad alta disponibilità. Di conseguenza, non è necessaria alcuna ottimizzazione sul cluster di amministrazione.
La configurazione predefinita della VM del piano di controllo del cluster utente (4 CPU, 8 GB di memoria e 40 GB di spazio di archiviazione) è la configurazione minima necessaria per eseguire fino a 250 nodi in un cluster utente.
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 GKE On-Prem richiede un indirizzo IP 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 seguente tabella 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 |
Networking Kubernetes
Questa sezione illustra le considerazioni sulla scalabilità per il blocco CIDR del pod e i servizi Kubernetes.
Blocco CIDR pod
Il blocco CIDR del pod è il blocco CIDR per tutti i pod in un cluster utente. In questo intervallo di tempo, a ogni nodo vengono assegnati blocchi /24 più piccoli. Se hai bisogno di un cluster N nodo, devi assicurarti che questo blocco sia abbastanza grande da supportare N /24 blocchi.
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 |
---|---|
/19 | 32 |
/18 | 64 |
/17 | 128 |
/16 | 256 |
Il blocco CIDR pod predefinito è 192.168.0.0/16, che supporta 256 nodi. Il blocco CIDR pod predefinito consente di creare un cluster con 250 nodi, che è il numero massimo di nodi supportati da GKE On-Prem in un cluster utente.
Servizi Kubernetes
Questa sezione illustra le considerazioni sulla scalabilità per il blocco CIDR del servizio e il bilanciatore del carico.
Blocco CIDR servizio
Il blocco CIDR di servizio è il blocco CIDR per tutti i servizi in un cluster utente. I Servizi trattati in questa sezione fanno riferimento ai Servizi Kubernetes con il tipo LoadBalancer.
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 |
---|---|
/20 | 4096 |
/19 | 8.192 |
/18 | 16.384 |
Il valore predefinito è 10.96.0.0/12, che supporta 1.048.576 servizi. Il blocco CIDR di servizio predefinito consente di creare un cluster con 500 servizi, che è il numero massimo di servizi GKE On-Prem supportati in un cluster utente.
Bilanciatore del carico
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 | 250 | 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.
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.
Cloud Logging e Cloud Monitoring
Cloud Logging e Cloud Monitoring ti aiutano a monitorare le tue risorse.
Esecuzione di molti nodi in un cluster utente
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
,
stackdriver-prometheus-sidecar
e stackdriver-log-aggregator
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 ciascun 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 | stackdriver-log-aggregator | 150m | 170m | 1.6G | 1,7 G |
server-prometheus | 100m | 390m | 650 mln | 1.3G | |
sidecar stackdriver-prometheus | 100m | 340m | 1.5G | 1.6G | |
Da 51 a 100 | stackdriver-log-aggregator | 220m | 1100m | 1.6G | 1,8 G |
server-prometheus | 160m | 500m | 1,8 G | 5.5G | |
sidecar stackdriver-prometheus | 200m | 500m | 1,9 G | 5.7G | |
Da 101 a 250 | stackdriver-log-aggregator | 450m | 1800m | 1,7 G | 1,9 G |
server-prometheus | 400m | 2500m | 6.5G | 16G | |
sidecar stackdriver-prometheus | 400m | 1300m | 7.5G | 12G |
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.
Esecuzione di molti cluster utente in un cluster di amministrazione
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 |
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 10 cluster utente, devi prima ridimensionare la memoria dei nodi del cluster di amministrazione da 16 GB a 32 GB.
Per cambiare la memoria del nodo 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.
Componenti del sistema a scalabilità automatica
GKE On-Prem scala automaticamente i componenti di sistema nel cluster 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.
GKE On-Prem esegue automaticamente la scalabilità verticale scalando la CPU e le richieste/i limiti di 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 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 250 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.
GKE On-Prem esegue automaticamente la scalabilità orizzontale scalando il numero di repliche dei seguenti componenti di sistema:
kube-dns è la soluzione DNS utilizzata per il Service Discovery in GKE On-Prem. Viene eseguito come deployment sui nodi worker del cluster utente. GKE On-Prem 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 e core C, puoi aspettarti un numero massimo di repliche(N/16, C/256). Nota che kube-dns è stato aggiornato poiché GKE On-Prem 1.4 supporta 1500 richieste in parallelo al secondo.
calico-typha è un componente per il supporto di networking di pod in GKE On-Prem. Viene eseguito come deployment sui nodi worker del cluster utente. GKE On-Prem scala automaticamente il numero di repliche in base al numero di nodi nel cluster. È presente una replica di calico-typha in un cluster con meno di 200 nodi e 2 repliche in un cluster con 200 o più nodi.
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, GKE On-Prem utilizza 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 250 nodi, valuta la possibilità di scalarlo in fasi da 80 a 160 a 250, 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 dal file system dei nodi on-prem di GKE, 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.