Scalabilità

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:

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:

  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.

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 e C core, puoi aspettarti max(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:

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