Scalabilità

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:

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:

  1. 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.

  2. Cambia il campo spec.template.spec.providerSpec.value.machineVariables.memory in 32768.

  3. 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:

  • 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.