Questa pagina illustra le quote di Google Distributed Cloud release 1.29 e per progetti, cluster e nodi di Google Cloud.
Limiti
Le sezioni seguenti descrivono alcuni limiti di base per i cluster. Prendi questi devi tenere conto dei limiti quando si progettano le tue applicazioni Google Distributed Cloud.
Numero massimo di cluster utente per cluster di amministrazione
I cluster di amministrazione gestiscono il ciclo di vita dei cluster utente e dei relativi cluster associati nodi. I cluster di amministrazione controllano le operazioni critiche del cluster utente, ad esempio il cluster creazione e reimpostazione del cluster o dei nodi, upgrade e aggiornamenti del cluster. La il numero totale di nodi del cluster utente è uno dei principali fattori che limitano le prestazioni e l'affidabilità.
Sulla base di test in corso, un cluster di amministrazione può supportare in modo affidabile un massimo di 100 cluster utente con 10 nodi ciascuno per un totale di 1000 nodi.
Numero massimo di pod per cluster utente
Ti consigliamo di limitare a 15.000 il numero di pod per cluster utente di meno. Ad esempio, se il tuo cluster ha 200 nodi, devi limitare di pod per nodo fino a un massimo di 75. Allo stesso modo, se vuoi eseguire 110 pod per nodo, devi limitare il numero di nodi nel tuo cluster a 136 di meno. La tabella seguente fornisce esempi di configurazioni che sono: non sono consigliati.
| Pod per nodo | Nodi per cluster | Pod per cluster | Risultato |
|---|---|---|---|
| 110 | 200 | 22.000 | Troppi pod, sconsigliato |
| 110 | 136 | 14.960 | Entro il limite |
| 100 | 150 | 15.000 | Entro il limite |
| 75 | 200 | 15.000 | Entro il limite |
Il numero massimo di pod per suggerimento di cluster utente ha la precedenza sul suggerimenti per i pod per nodo e i nodi per cluster utente nel seguente sezioni.
Numero massimo di nodi per cluster utente
Testiamo Google Distributed Cloud per eseguire carichi di lavoro con un massimo di 500 nodi. Tuttavia, per garantire prestazioni e affidabilità ottimali, ti consigliamo di non superare i 200 nodi per cluster quando vengono eseguiti carichi di lavoro in produzione.
| Tipo di cluster | Numero minimo di nodi | Numero massimo di nodi consigliato | Nodi massimi assoluti |
|---|---|---|---|
| Utente, autonomo o ibrido | 1 | 200 | 500 |
Per i cluster a nodo singolo, devi rimuovere
node-role.kubernetes.io/master:NoSchedule è incompatibilità per l'esecuzione di carichi di lavoro sul nodo.
Per maggiori dettagli, vedi
Incompatibilità e tolleranze di Kubernetes.
Numero massimo di pod per nodo
Google Distributed Cloud supporta la configurazione del numero massimo di pod per nodo in
l'impostazione nodeConfig.PodDensity.MaxPodsPerNode della configurazione del cluster
un file YAML. La
la tabella seguente mostra i valori minimo e massimo supportati per
MaxPodsPerNode, che include pod che eseguono servizi aggiuntivi:
| Tipo di cluster | Valore minimo consentito | Valore massimo consigliato | Valore massimo consentito |
|---|---|---|---|
| Tutti i cluster ad alta disponibilità e i cluster utente non ad alta disponibilità | 32 | 110 | 250 |
| Tutti gli altri cluster non ad alta disponibilità | 64 | 110 | 250 |
Numero massimo di endpoint
Su Red Hat Enterprise Linux (RHEL), esiste un limite a livello di cluster
100.000 endpoint. Questo numero è la somma di tutti i pod a cui fa riferimento un
completamente gestito di Kubernetes. Se due servizi fanno riferimento allo stesso insieme di pod,
conta come due insiemi separati di endpoint. L'elemento nftable sottostante
l'implementazione su RHEL causa questa limitazione; non è una limitazione intrinseca
di Google Distributed Cloud.
Mitigazione
Per RHEL, non sono previste mitigazioni. Per i sistemi Ubuntu e Debian consigliamo
passaggio dal modello nftables predefinito alla versione precedente
iptables attivo
e cluster su larga scala.
GKE Dataplane V2
Google Distributed Cloud utilizza GKE Dataplane V2, un cluster un dataplane implementato con Cilium e eBPF, ottimizzato per Kubernetes networking.
Limiti NetworkPolicy di GKE Dataplane V2
GKE Dataplane V2 utilizza Cilium per gestire le risorse NetworkPolicy di Kubernetes. La
ai tuoi cluster Google Distributed Cloud si applicano i seguenti limiti:
| Dimensioni | Limiti supportati |
|---|---|
| Frequenza massima di modifica per le etichette dello spazio dei nomi | Al massimo, una modifica all'ora per ogni spazio dei nomi.
Nella maggior parte dei casi, questo limite non è necessario. Purché le modifiche non siano frequenti, ad esempio ogni secondo, o il numero di identità cilium (set di etichette univoche) non è vicino al limite: 16.000 set di etichette con consenti tutti i criteri di rete o 65.535 set di etichette per cluster. |
| Numero massimo di endpoint di servizio per cluster | 100.000 endpoint è il limite testato e consigliato. Lo strumento hardcoded per gli endpoint di servizio è di 262.000. |
| Numero massimo di criteri e regole di rete | Al massimo 40.000 criteri di rete e 80.000 regole. Ad esempio, specificare 40.000 criteri di rete con due regole ciascuno, specificare 20.000 criteri con quattro regole ciascuno. |
| Frequenza massima di modifica per i criteri di rete | Al massimo 20 modifiche (creazioni o delezioni) al secondo. |
| Numero massimo di set di etichette di pod univoci | 65.535 (216-1). Questo è il limite per Cilium Security Identity. |
| Numero massimo di set di etichette di pod univoci selezionati dai selettori di criteri | 16.000 (le dimensioni della mappa eBPF fisse). Una determinata voce della mappa del selettore di criteri è composto da: security-identity, porta e protocollo. |
Limite eBPF GKE Dataplane V2
Il numero massimo di voci nel lbmap BPF per Dataplane V2 è 65.536. Gli aumenti nelle seguenti aree possono causare l'aumento del numero totale di voci:
- Numero di servizi
- Numero di porte per servizio
- Numero di backend per servizio
Ti consigliamo di monitorare il numero effettivo di voci utilizzate dal cluster per assicurarti di non superare il limite. Utilizza il seguente comando per ottenere voci correnti:
kubectl get po -n kube-system -l k8s-app=cilium | cut -d " " -f1 | grep anetd | head -n1 | \
xargs -I % kubectl -n kube-system exec % -- cilium bpf lb list | wc -l
Ti consigliamo inoltre di utilizzare la tua pipeline di monitoraggio per raccogliere le metriche
dal DaemonSet anetd. Monitora le seguenti condizioni per identificare
quando il numero di voci causano problemi:
cilium_bpf_map_ops_total{map_name="lb4_services_v2",operation="update",outcome="fail" } > 0
cilium_bpf_map_ops_total{map_name="lb4_backends_v2",operation="update",outcome="fail" } > 0
Limite di porte di LoadBalancer e Servizi NodePort
Il limite di porte per i servizi LoadBalancer e NodePort è 2768. Il valore predefinito
l'intervallo di porte è 30000-32767. Se superi il limite, non potrai crearne di nuovi
LoadBalancer o NodePort e non puoi aggiungere nuove porte nodo per
e i servizi esistenti.
Per impostazione predefinita, Kubernetes alloca le porte dei nodi ai servizi di tipo LoadBalancer.
Queste allocazioni possono esaurire rapidamente le porte dei nodi disponibili dai 2768
allocati al cluster. Per salvare le porte del nodo, disabilita la porta del nodo del bilanciatore del carico
di allocazione impostando il campo allocateLoadBalancerNodePorts su false nel
la specifica del servizio LoadBalancer.
Questa impostazione impedisce a Kubernetes di allocare le porte dei nodi a LoadBalancer
Servizi. Per ulteriori informazioni, vedi
Disabilitazione dell'allocazione NodePort del bilanciatore del carico
nella documentazione di Kubernetes.
Utilizza il comando seguente per verificare il numero di porte allocate:
kubectl get svc -A | grep : | tr -s ' ' | cut -d ' ' -f6 | tr ',' '\n' | wc -l
Limiti di connessione dei nodi del bilanciatore del carico in bundle
Il numero di connessioni consentite per ogni nodo utilizzato per il bilanciamento del carico in bundle (MetalLB) è 28.000. L'intervallo predefinito di porte temporanee per queste connessioni è 32768-60999. Se superi il limite di connessioni, vengono richieste al LoadBalancer Il servizio potrebbe non riuscire.
Se devi esporre un servizio di bilanciamento del carico in grado di gestire un un numero considerevole di connessioni (ad esempio Ingress), consigliamo di prendi in considerazione un metodo di bilanciamento del carico alternativo per evitare questa limitazione MetalLB.
Quote cluster
Puoi registrare un massimo di 15 cluster per impostazione predefinita. Per registrare altri cluster in GKE Hub, puoi inviare una richiesta di aumento della quota Console Google Cloud:
Informazioni sulla scalabilità
Le informazioni contenute in questo documento sono pertinenti per pianificare come fare lo scale up cluster. Per ulteriori informazioni, consulta Fai lo scale up dei cluster Google Distributed Cloud.
Non hai trovato quello che stavi cercando? Fai clic su Invia feedback e segnalacelo. cosa manca.