Scalabilità

In questa pagina vengono descritte le best practice per creare, configurare e utilizzare creati mediante Google Distributed Cloud (solo software) per consentire a VMware per supportare carichi di lavoro che si avvicinano ai limiti di scalabilità di Kubernetes.

Regole per i nomi dei cluster

Per ogni progetto Google Cloud:

  • Ogni cluster utente deve avere un nome univoco in tutti i cluster di amministrazione nell'ambito di un progetto Google Cloud.

Limiti di scalabilità

Tieni conto dei seguenti limiti durante la progettazione delle applicazioni:

Informazioni sui limiti

Poiché Google Distributed Cloud è un sistema complesso con una vasta area di integrazione, la scalabilità del cluster coinvolge molte dimensioni interconnesse. Ad esempio: Google Distributed Cloud può scalare attraverso il numero di nodi, pod Servizi. L'estensione di più dimensioni contemporaneamente può causare problemi anche in cluster più piccoli. Ad esempio, la pianificazione di 110 pod per nodo in un cluster di 500 nodi può sovraccaricare il numero di pod, pod per nodo e nodi.

Per ulteriori dettagli, consulta la sezione Soglie di scalabilità di Kubernetes.

I limiti di scalabilità sono sensibili anche alla configurazione e all'hardware vSphere su cui è in esecuzione il cluster. Questi limiti vengono verificati in un ambiente probabilmente diverse dalla tua. Pertanto, potresti non riprodurre i numeri esatti quando l'ambiente sottostante è il fattore limitante.

Preparazione alla scalabilità

Quando ti prepari a scalare i cluster di amministrazione o i cluster utente, tieni conto dei seguenti requisiti e limitazioni.

Requisiti di CPU, memoria e spazio di archiviazione

Vedi 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 con un'intensità di dati elevata e alcuni componenti del piano di controllo sono sensibili alla latenza di I/O del disco e della rete. Ad esempio, in genere sono necessari 500 IOPS sequenziali (ad esempio un'unità SSD locale tipica o un dispositivo a blocchi virtualizzato ad alte prestazioni) per le prestazioni e la stabilità di etcd in un cluster con dozzine di nodi e migliaia di pod.

Indirizzo IP del nodo

Ogni nodo richiede un indirizzo DHCP o un indirizzo IP assegnato in modo statico.

Ad esempio, sono necessari 307 indirizzi IP in una configurazione con un cluster utente non HA con 50 nodi e un cluster utente HA 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 3
VM del piano di controllo del cluster utente 1 (non ad alta disponibilità) 1
VM del nodo worker del cluster utente 1 50
VM del piano di controllo del cluster utente 2 (HA) 3
VM del nodo worker del cluster utente 2 250
Totale 307

Esecuzione di molti cluster utente in un cluster di amministrazione

Quando ti prepari a eseguire molti cluster utente in un cluster di amministrazione, svolgi i seguenti passaggi durante la creazione del cluster di amministrazione.

Blocco CIDR del pod nel cluster di amministrazione

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

In questo intervallo, a ogni nodo vengono assegnati blocchi /24 più piccoli. Se in tutti i tuoi cluster utente è attivato Controlplane V2, il tuo cluster di amministrazione ha solo tre nodi e sono disponibili molti indirizzi IP dei pod. Tuttavia, ogni volta che crei un cluster utente che utilizza kubeception anziché Controlplane v2, vengono aggiunti uno o tre nodi al cluster di amministrazione:

  • Ogni cluster utente kubeception ad alta disponibilità aggiunge tre nodi del cluster di amministrazione.

  • Ogni cluster utente kubeception non HA aggiunge un nodo al cluster di amministrazione.

Se hai bisogno di un cluster amministrativo di N nodi, devi assicurarti che il blocco CIDR del pod sia sufficientemente grande da supportare N blocchi /24.

La tabella seguente descrive il numero massimo di nodi supportati da diversi dimensioni dei blocchi CIDR del pod:

Dimensione blocco CIDR pod Numero massimo di nodi supportati
/18 64
/17 128
/16 256
/15 512

Il blocco CIDR dei 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 kubeception ad alta disponibilità, sono disponibili tre dei nodi del piano di controllo del cluster e di 300 nodi del piano di controllo del cluster utente. Il totale di nodi è 303 (più di 256). Pertanto, devi aggiornare il blocco CIDR del pod su /15 per supportare fino a 100 cluster di utenti kubeception HA.

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

Blocco CIDR del servizio nel cluster di amministrazione

Il blocco CIDR del servizio è il blocco CIDR per tutti i servizi in un cluster amministrativo. Viene configurato tramite il campo network.serviceCIDR nella admin-cluster.yaml.

La tabella seguente descrive il numero massimo di servizi supportati da dimensioni dei blocchi CIDR dei servizi diverse:

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 kubeception utilizza 6 servizi e il control plane del cluster di amministrazione utilizza 14 servizi. Pertanto, per eseguire 100 cluster di utenti kubeception, devi modificare il blocco CIDR del servizio nel cluster di amministrazione in modo da utilizzare 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 dei componenti di logging e monitoraggio di cui è stato eseguito il deployment in un la scalabilità del cluster di amministrazione in base al numero di cluster utente kubeception.

La tabella seguente descrive la quantità di CPU e memoria dei nodi del cluster di amministrazione necessaria per eseguire un numero elevato di cluster utente kubeception:

Numero di cluster di utenti kubeception CPU del nodo del cluster di amministrazione Memoria del nodo del 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 90 GB

Ad esempio, se sono presenti 2 nodi del cluster di amministrazione e ciascuno ha 4 CPU e 16 GB di memoria, puoi eseguire da 0 a 10 cluster utente kubeception. Per creare più di 20 cluster utente kubeception, devi prima ridimensionare la memoria del nodo del cluster di amministrazione da 16 GB a 90 GB.

GKE Hub

Per impostazione predefinita, puoi registrare un massimo di 250 cluster con adesioni globali per parco risorse. Per registrare altri cluster in GKE Hub, puoi inviare una richiesta a Aumenta la quota nella console Google Cloud:

Vai a Quote

Per ulteriori informazioni sulle quote del cluster in base alle impostazioni di appartenenza, consulta Quote di allocazione.

Eseguire molti nodi e pod in un cluster utente

Mentre ti prepari a eseguire molti nodi e pod in un cluster utente, esegui le i seguenti passaggi durante la creazione del cluster utente.

Blocco CIDR dei pod nel cluster utente

Il blocco CIDR dei pod è il blocco CIDR per tutti i pod in un cluster utente. Viene configurato tramite il campo network.podCIDR in user-cluster.yaml.

A questo intervallo viene assegnato un blocco /24 più piccolo a ogni nodo. Se hai bisogno di N/24 di nodi, devi assicurarti che questo blocco sia abbastanza grande da supportare N/24 isolati.

La tabella seguente descrive il numero massimo di nodi supportati da diversi dimensioni dei blocchi CIDR del pod:

Dimensione blocco CIDR pod Numero massimo di nodi supportati
/18 64
/17 128
/16 256
/15 512

Il blocco CIDR predefinito dei pod è 192.168.0.0/16, che supporta 256 nodi. Ad esempio, per creare un cluster con 500 nodi, devi modificare il blocco CIDR del pod nel cluster utente in modo da utilizzare un intervallo /15.

Blocco CIDR del servizio nel cluster utente

Il blocco CIDR del servizio è il blocco CIDR per tutti i servizi in un cluster di utenti. Viene configurato tramite il campo network.serviceCIDR in user-cluster.yaml.

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

Dimensione blocco CIDR servizio Numero massimo di servizi supportati
/21 2048
/20 4096
/19 8.192
/18 16.384

Nodi del control plane del cluster utente

L'utilizzo di memoria dei componenti del piano di controllo del cluster utente varia in base al numero di nodi nel cluster utente.

La tabella seguente fornisce la CPU e la memoria necessarie per un cluster utente nodo del piano di controllo in base alle dimensioni del cluster utente:

Numero di nodi del cluster utente CPU del nodo del piano di controllo Memoria del nodo del control plane
Da 0 a 20 3 CPU 5 GB
Da 21 a 75 3 CPU 6 GB
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 le risorse dai nodi del piano di controllo del cluster 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 di 500 nodi che utilizzano Dataplane V2, consigliamo 120 GB di memoria e 32 core della 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 risorse.

L'utilizzo di CPU e memoria degli agenti in-cluster di cui è stato eseguito il deployment in un cluster utente è proporzionale al numero di nodi e pod in un cluster utente.

Componenti di Cloud Logging e Monitoring come prometheus-server e stackdriver-prometheus-sidecar hanno un utilizzo delle risorse di CPU e memoria diverso in base al numero di nodi e al numero di pod. Prima di eseguire l'upgrade del cluster, imposta la richiesta e il limite di risorse in base all'utilizzo medio stimato di questi componenti. La seguente tabella mostra le stime per la quantità media di utilizzo per ogni componente:

Numero di nodi Nome container Utilizzo stimato della CPU Utilizzo memoria stimato
0 pod/nodo 30 pod/nodo 0 pod/nodo 30 pod/nodo
Da 3 a 50 prometheus-server 100m 390m 650 mln 1,3 G
stackdriver-prometheus-sidecar 100 m 340m 1,5 G 1,6 G
Da 51 a 100 prometheus-server 160 min 500 m 1,8 G 5,5G
sidecar-stackdriver-prometheus 200 m 500 m 1,9 G 5,7 G
Da 101 a 250 prometheus-server 400 m 2.500 m 6,5 G 16 GB
stackdriver-prometheus-sidecar 400m 1.300 m 7,5 G 12 G
Da 250 a 500 prometheus-server 1200 m 2.600 m 22 G 25 G
stackdriver-prometheus-sidecar 400 m 2250m 65 G 78 G

Assicurati di avere nodi abbastanza grandi da pianificare i componenti di Cloud Logging e Cloud Monitoring. Un modo per farlo è creare prima un piccolo cluster, modificare le risorse dei componenti Cloud Logging e Cloud Monitoring in base alla tabella sopra, creare un pool di nodi per ospitare i componenti e poi eseguire gradualmente lo scale up del cluster a una dimensione maggiore.

Puoi scegliere di mantenere un pool di nodi sufficientemente grande per i componenti di monitoraggio e logging 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

In questo modo, si impedisce la pianificazione di altri componenti nel pool di nodi e si impedisce l'espulsione dei carichi di lavoro degli utenti a causa del consumo di risorse dei componenti di monitoraggio.

Bilanciatore del carico

I servizi descritti in questa sezione si riferiscono ai servizi Kubernetes di tipo LoadBalancer.

Esiste un limite al numero di nodi nel cluster e al numero di Service che puoi configurare sul bilanciatore del carico.

Per il bilanciamento del carico in bundle (Seesaw), esiste anche un limite al numero e controlli di integrità. Il numero di controlli di integrità dipende dal numero di nodi e dal numero di servizi locali per il traffico. Un servizio locale di traffico è un servizio per il quale è impostato externalTrafficPolicy su Local.

La tabella seguente descrive il numero massimo di servizi, nodi e integrità verifica 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)
Max Services 500 250 2
N. massimo di nodi 500 250 2
Controlli di integrità massimi N + (L * N) <= 10.000, dove N è il numero di nodi e L è il numero di servizi locali di traffico 1 N/D 2

1 Ad esempio, supponiamo che tu abbia 100 nodi e 99 traffico locale Servizi. Il numero di controlli di integrità è 100 + (99 * 100) = 10.000, rientra quindi nel limite di 10.000.

2 Per ulteriori informazioni, contatta F5. Questo numero dipende da vari fattori come il numero di modello hardware F5, la CPU/memoria dell'istanza virtuale e le licenze.

Componenti di sistema con scalabilità automatica

Google Distributed Cloud scala automaticamente i componenti di sistema i cluster in base al numero di nodi senza dover apportare modifiche configurazioni. È possibile utilizzare le informazioni in questa sezione per predittiva dell'inventario.

  • Google Distributed Cloud esegue automaticamente la scalabilità verticale scalando la CPU richieste/limiti di memoria e richieste di memoria dei seguenti componenti di sistema utilizzando addon-resizer:

    • kube-state-metrics è un deployment in esecuzione sui nodi worker del cluster che rimane in ascolto del server API Kubernetes e genera metriche sugli lo stato desiderato degli oggetti. La richiesta di CPU e memoria e i limiti della scalabilità in base il numero di nodi.

      La tabella seguente descrive le richieste/i limiti di risorse impostati dal sistema, in base al numero di nodi in un cluster:

      Numero di nodi Approssimativamente1 richiesta/limite di CPU (milli) Richiesta/limite di memoria approssimativo1 (Mi)
      Da 3 a 5 105 110
      Da 6 a 500 100 + num_nodi 100 + (2 * num_nodes)

      1 Esiste un margine di +/-5% per ridurre il numero di riavvii dei componenti durante il ridimensionamento.

      Ad esempio, in un cluster con 50 nodi, la richiesta/il limite della CPU sono impostati su 150 m/150 m e la richiesta/il limite della memoria sono impostati su 200 Mi/200 Mi. In un cluster con 250 nodi, la richiesta/il limite di CPU è impostato su 350 m/350 m il limite/la richiesta di memoria è impostato su 600 Mi.

    • metrics-server è un deployment in esecuzione sui nodi worker del cluster utilizzato dalle pipeline di scalabilità automatica integrate di Kubernetes. CPU e memoria e limita la scalabilità in base al numero di nodi.

  • Google Distributed Cloud esegue automaticamente la scalabilità orizzontale sia nei cluster di amministrazione sia nei cluster utente ridimensionando il numero di repliche dei seguenti componenti di sistema:

    • core-dns è la soluzione DNS utilizzata per la Service Discovery. Viene eseguito come deployment sui nodi worker del cluster utente. Google Distributed Cloud scala automaticamente il numero di repliche in base al numero di nodi e core CPU nel cluster. A ogni aggiunta/eliminazione di 16 nodi o 256 core, viene utilizzata 1 replica aumentati/diminuiti. Se hai un cluster di N nodi e C core, puoi: sono previste max(N/16, C/256) repliche.

    • calico-typha è un componente per supportare il networking dei pod. Viene eseguito come deployment sui nodi worker del cluster utente. Google Distributed Cloud scala automaticamente il numero di repliche del calico-tifa in base al di nodi nel cluster:

      Numero di nodi (N) Numero di repliche di calico-typha
      N = 1 1
      1 < N < 200 2
      N >= 200 3 o più

    • Il gateway in entrata di Istio è il componente per supportare in entrata in un cluster e viene eseguito come deployment sul worker del cluster utente nodi. A seconda della quantità di traffico gestita dall'ingress-gateway, Google Distributed Cloud 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.

    • Il proxy di rete konnectivity (KNP) fornisce un proxy a livello di TCP per la gestione delle uscite dai nodi del piano di controllo del cluster utente. Tunnelizza il traffico in uscita di kube-apiserver destinato ai nodi del cluster utente. L'agente Konnectivity viene eseguito come deployment sul worker del cluster utente nodi. Google Distributed Cloud scala automaticamente il numero dell'agente di connettività in base al numero di nodi nel cluster.

      Numero di nodi (N) Numero di repliche dell'agente di connettività
      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 scalare le risorse.

Scala il 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 disco, che è un'operazione vSphere ad alta intensità di I/O. Non sono presenti Isolamento I/O tra l'operazione di clonazione e le operazioni di I/O del carico di lavoro. Se vengono creati troppi nodi contemporaneamente, le operazioni di clonazione richiedono molto tempo per essere completate e potrebbero influire sulle prestazioni e sulla stabilità del cluster e dei carichi di lavoro esistenti.

Assicurati che la scalabilità del cluster venga eseguita in fasi a seconda delle risorse vSphere. Ad esempio, per ridimensionare un cluster da 3 a 500 nodi, valuta la possibilità di eseguirlo in più fasi, da 150 a 350 e infine a 500, in modo da ridurre il carico sull'infrastruttura vSphere.

Ottimizzare le prestazioni di I/O disco di etcd

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

  • Ottimizza le prestazioni I/O del datastore vSphere utilizzato per il piano di controllo VM seguendo questi suggerimenti:

  • Una latenza di alcune centinaia di millisecondi indica un collo di bottiglia sull'I/O del disco o della rete e potrebbe comportare un cluster non integro. Monitora e imposta un avviso soglie per le seguenti metriche di latenza I/O etcd:

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

Ottimizza le prestazioni I/O del disco di avvio del nodo

I pod utilizzano lo spazio di archiviazione temporaneo per le loro operazioni interne, come il salvataggio di file temporanei. Lo spazio di archiviazione temporaneo viene utilizzato dal livello scrivibile del container, dalla directory dei log e dai volumi emptyDir. L'archiviazione temporanea proviene al file system del nodo, che è supportato dal disco di avvio del nodo.

In assenza di isolamento I/O di archiviazione sui nodi Kubernetes, consumano un I/O estremamente elevato nel loro spazio di archiviazione temporaneo instabilità causando la fame di componenti di sistema come Kubelet e il daemon Docker di Google Cloud.

Assicurati che le caratteristiche di prestazioni I/O del datastore su cui viene eseguito il provisioning dei dischi di avvio possano fornire le prestazioni giuste per l'utilizzo da parte dell'applicazione dello spazio di archiviazione temporaneo e del traffico di log.

Monitorare la contesa delle risorse fisiche

Tieni presente i rapporti tra vCPU e pCPU e il sovracommittmento della memoria. Un rapporto non ottimale o una contesa della memoria sugli host fisici possono causare un degrado delle prestazioni della VM. Devi monitorare l'utilizzo delle risorse fisiche a livello di host e allocare risorse sufficienti per eseguire i cluster di grandi dimensioni.