Scalabilità

Questa pagina descrive le best practice per creare, configurare e utilizzare cluster Anthos sui cluster VMware (GKE on-prem) per supportare i carichi di lavoro che avvicinano i limiti di scalabilità di Kubernetes.

Regole per il nome del cluster

Per ogni progetto Google Cloud: * Ogni cluster utente deve avere un nome univoco in tutti i cluster di amministrazione inclusi in un singolo progetto Google Cloud.

Limiti di scalabilità

Tieni in considerazione i seguenti limiti durante la progettazione delle applicazioni su Cluster Anthos su VMware:

Informazioni sui limiti

Poiché i cluster Anthos su VMware sono un sistema complesso con un'ampia superficie di integrazione, la scalabilità del cluster prevede molte dimensioni interconnesse. Ad esempio, i cluster Anthos su VMware possono scalare in base al numero di nodi, pod o servizi. L'allungamento di più dimensioni può causare problemi anche nei cluster più piccoli. Ad esempio, la pianificazione di 110 pod per nodo in un cluster di 500 nodi può sovraccaricare il numero di pod, dei pod per nodo e dei nodi.

Per maggiori dettagli, vedi 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 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 i tuoi cluster di amministrazione o cluster utente, considera i seguenti requisiti e limitazioni.

CPU, memoria e requisiti di archiviazione

Consulta 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 ad alta intensità di dati e alcuni componenti del piano di controllo sono sensibili alla latenza di disco e rete di I/O. Ad esempio, sono generalmente necessarie 500 IOPS sequenziali (ad esempio un'unità SSD locale standard o un dispositivo di blocco 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 cluster Anthos sul nodo VMware richiede un indirizzo DHCP o assegnato in modo statico.

Ad esempio, in una configurazione con un cluster utente non ad alta disponibilità con 50 nodi e un cluster utente ad alta disponibilità con 250 nodi sono necessari 308 indirizzi IP.

La tabella riportata di seguito mostra l'analisi 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 HA) 1
VM del nodo utente 1 del nodo 50
VM del piano di controllo del cluster utente 2 (HA) 3
VM del nodo utente 2 250
Totale 308

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 pod nel cluster di amministrazione

Il blocco CIDR pod è il blocco CIDR per tutti i pod in un cluster di amministrazione. È configurata tramite il campo network.podCIDR in admin-cluster.yaml.

Da questo intervallo, vengono assegnati blocchi /24 più piccoli a ogni nodo. Se hai bisogno di un cluster di amministrazione con nodi N, devi assicurarti che questo blocco sia abbastanza grande da supportare i blocchi N /24.

La tabella seguente descrive il numero massimo di nodi supportati da diverse dimensioni dei blocchi CIDR di 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 100 cluster utente ad alta disponibilità (ogni cluster utente ha 3 nodi del piano di controllo), esistono 1 nodo del piano di controllo del cluster di amministrazione, 2 nodi del componente aggiuntivo del cluster di amministrazione e 300 nodi del piano di controllo del cluster utente. Il numero totale di nodi è 303 (più di 256). Di conseguenza, devi aggiornare il blocco CIDR di pod su /15 per supportare fino a 100 cluster utente HA.

Per configurare il blocco CIDR del pod, imposta il campo network.podCIDR nel file di configurazione del cluster di amministrazione.

Blocco CIDR di servizi nel cluster di amministrazione

Il blocco CIDR servizio è il blocco CIDR per tutti i servizi in un cluster di amministrazione. È configurato tramite il campo network.serviceCIDR in admin-cluster.yaml.

La tabella seguente descrive il numero massimo di servizi supportati da diverse dimensioni di blocco CIDR servizio:

Dimensione blocco CIDR di 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 6 servizi e il piano di controllo del cluster di amministrazione utilizza 14 servizi. Di conseguenza, per eseguire 100 cluster utente, è necessario modificare il blocco CIDR di 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 tue risorse.

L'utilizzo di CPU e memoria da parte dei componenti di logging e monitoraggio di cui è stato eseguito il deployment in una scala del cluster di amministrazione in base al numero di cluster utente.

La tabella seguente descrive la quantità di CPU e memoria del nodo del cluster di amministrazione richiesta per eseguire un numero elevato di cluster utente:

Numero di cluster utente CPU del nodo del 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 100 4 CPU 90GB

Ad esempio, se ci sono 2 nodi del cluster di amministrazione e ognuno 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 del nodo 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 più cluster in GKE Hub, puoi inviare una richiesta di aumento della quota in Google Cloud Console:

 [Go to Quotas](https://console.cloud.google.com/apis/api/gkehub.googleapis.com/quotas){: target="console"
 class="button button-primary" track-type="quotas" track-name="consoleLink" track-metadata-end-goal="modifyQuota"}

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 quando crei il cluster utente.

Blocco CIDR pod nel cluster utente

Il blocco CIDR pod è il blocco CIDR per tutti i pod in un cluster utente. È configurata 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 N /24 blocchi.

La tabella seguente descrive il numero massimo di nodi supportati da diverse dimensioni dei blocchi CIDR di 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 servizi nel cluster utente

Il blocco CIDR servizio è il blocco CIDR per tutti i servizi in un cluster utente. È configurata tramite il campo network.serviceCIDR in user-cluster.yaml.

La tabella seguente descrive il numero massimo di servizi supportati da diverse dimensioni di blocco CIDR servizio:

Dimensione blocco CIDR di 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 servizio predefinito consente di creare un cluster con 500 servizi, che corrisponde al numero massimo di cluster Anthos Service 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 fornisce CPU e memoria richieste dal nodo del piano di controllo del cluster utente a seconda delle dimensioni del cluster utente:

Numero di nodi 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 i 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 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, in termini di numero di nodi e pod in un cluster utente.

I componenti di logging e monitoraggio, 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 seguente mostra le stime per la quantità di utilizzo media per ogni componente:

Numero di nodi Nome container Utilizzo stimato della CPU Utilizzo stimato della memoria
0 pod/nodo 30 pod/nodo 0 pod/nodo 30 pod/nodo
Da 3 a 50 server-prometheus 100m 390m 650 mln 1,3 G
stackcarri-prometheus 100m 340m 1,5 G 1,6 G
Da 51 a 100 server-prometheus 160m 500m 1,8 G 5.5G
stackcarri-prometheus 200m 500m 1,9 G 5,7 G
Da 101 a 250 server-prometheus 400m 2500m 6,5 G 16G
stackcarri-prometheus 400m 1300m 7,5 G 12 g
Da 250 a 500 server-prometheus 1200m 2600m 22G 25G
stackcarri-prometheus 400m 2250m 65 g 78 g

Assicurati di avere nodi sufficientemente grandi per pianificare i componenti Cloud Logging e Cloud Monitoring. Un modo per farlo è quello di creare prima un piccolo cluster, modificare le risorse del componente Cloud Logging e Cloud Monitoring in base alla tabella riportata sopra, creare un pool di nodi per accogliere i componenti, quindi scalare gradualmente il cluster a una dimensione maggiore.

Puoi scegliere di mantenere un pool di nodi abbastanza grande da consentire la monitoraggio e il logging dei componenti per impedire la pianificazione di altri pod nel pool di nodi. Per farlo, devi aggiungere le seguenti incompatibilità al pool di nodi:

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

Ciò impedisce la pianificazione di altri componenti nel pool di nodi e impedisce che i carichi di lavoro degli utenti vengano rimossi a causa del consumo delle risorse da parte dei componenti di monitoraggio.

Bilanciatore del carico

I servizi descritti 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), è presente anche un limite per il 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 2502
Numero massimo di nodi 500 2502
Numero massimo controlli di integrità N + (L * N) <= 10.000, dove N è il numero di nodi e L è il numero di servizi locali di traffico 1 N/D 2

1Ad esempio, supponiamo che tu abbia 100 nodi e 99 servizi locali di traffico. Il numero di controlli di integrità è 100 + (99 * 100) = 10.000, entro il limite di 10.000.

2 Per ulteriori informazioni, consulta F5. Questo numero è influenzato da fattori quali il numero del modello hardware F5, la CPU/memoria dell'istanza virtuale e le licenze.

Componenti del sistema di scalabilità automatica

I cluster Anthos su VMware scalano automaticamente i componenti di sistema nei cluster utente in base al numero di nodi senza che sia necessario modificare le configurazioni. Puoi utilizzare le informazioni in questa sezione per la pianificazione delle risorse.

  • I cluster Anthos su VMware eseguono automaticamente la scalabilità verticale scalando le richieste/limiti delle CPU e della 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 scalano 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 in un cluster:

      Numero di nodi Circa 1 richiesta/limite CPU (millisecondi) Approssimativa1 richiesta/limite di memoria (Mi)
      Da 3 a 5 105 110
      Da 6 a 500 100 + num_nodi 100 + (2 * num_nodi)

      1 C'è 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 e il limite di CPU sono impostati su 150 m/150 m e la richiesta/il limite di memoria è impostato su 200 Mi/200 Mi. In un cluster con 250 nodi, la richiesta e il limite di CPU sono impostati su 350 m/350 m, mentre la richiesta e il limite di memoria sono impostati su 600 Mi.

    • metrics-server è un deployment in esecuzione su nodi worker del cluster utilizzati dalle pipeline di scalabilità automatica integrate in Kubernetes. La richiesta e i limiti di CPU e memoria scalano in base al numero di nodi.

  • I cluster Anthos su VMware eseguono automaticamente la scalabilità orizzontale nei cluster di amministrazione e nei cluster utente scalando il numero di repliche dei seguenti componenti di sistema:

    • core-dns è la soluzione DNS utilizzata per il Service Discovery nei cluster Anthos su VMware. Viene eseguito come deployment sui nodi worker del cluster utente. I cluster Anthos su VMware scalano automaticamente il numero di repliche in base al numero di nodi e core della CPU nel cluster. Con ogni aggiunta/eliminazione di 16 nodi o 256 core, viene incrementata/ridotta 1 replica. Se hai un cluster di nodi N e C core, puoi aspettarti max(N/16, C/256) repliche.

    • calico-typha è un componente per supportare il networking di pod in cluster Anthos su VMware. Viene eseguito come deployment sui nodi worker del cluster utente. I 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 traffico in entrata del cluster, che vengono eseguiti come deployment sui nodi worker del cluster utente. A seconda della quantità di traffico in entrata in entrata, il cluster Anthos su 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 di TCP per l'inoltro dai nodi del piano di controllo del cluster utente. Esegue il tunneling dell'utente kube-apiserver in uscita dal traffico destinato ai nodi dei cluster utente. L'agente Konnectivity viene eseguito come deployment sui nodi worker del cluster utente. I cluster Anthos su VMware scalano automaticamente il numero di repliche dell'agente di pertinenza in base al numero di nodi nel cluster.

      Numero di nodi (N) Numero di repliche di agenti
      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.

Scalabilità del 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 del disco, che è un'operazione vSphere con uso intensivo di I/O. Non esiste un isolamento I/O tra le operazioni di clone e le operazioni di I/O per i carichi di lavoro. Se vengono creati troppi nodi contemporaneamente, il completamento delle operazioni di clone 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 in più fasi in base alle risorse vSphere. Ad esempio, per ridimensionare un cluster da 3 a 500 nodi, valuta di scalarlo in più fasi da 150 a 350 a 500, riducendo il carico sull'infrastruttura vSphere.

Ottimizza prestazioni I/O disco etcd

etcd è un archivio chiave-valore utilizzato come Kubernetes' backup per tutti i dati del cluster. Le sue prestazioni e stabilità sono fondamentali per l'integrità del cluster e sono sensibili alla latenza di I/O di disco e rete.

  • Ottimizza le prestazioni di 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 per gli avvisi per le seguenti metriche di latenza I/O eccd:

    • 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 l'archiviazione temporanea per le loro operazioni interne, ad esempio per 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 dai cluster Anthos sul file system del nodo VMware, che è supportato dal disco di avvio del nodo.

Poiché non esiste un isolamento I/O di archiviazione sui nodi Kubernetes, le applicazioni che consumano I/O estremamente elevati nell'archiviazione temporanea possono potenzialmente causare instabilità del nodo eliminando gli elementi dei sistemi 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 offrire le giuste prestazioni per l'utilizzo dell'archiviazione temporanea e del traffico di logging da parte dell'applicazione.

Monitora contese risorse fisiche

Tieni presente le proporzioni vCPU/pCPU e l'overcommitment della memoria. Un rapporto non ottimale o una conflitto di memoria negli host fisici può 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.