Anthos clusters on bare metal è ora Google Distributed Cloud (solo software) per bare metal. Per ulteriori informazioni, consulta la panoramica del prodotto.

Questa pagina è stata tradotta dall'API Cloud Translation.

Quote e limiti

Questa pagina illustra le quote e i limiti della release 1.29 di Google Distributed Cloud per progetti, cluster e nodi di Google Cloud.

Limiti

Le sezioni seguenti descrivono alcuni limiti di base per i cluster. Tieni conto di questi limiti quando progetti le applicazioni per l'esecuzione su 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 nodi associati. I cluster di amministrazione controllano le operazioni critiche del cluster utente, come la creazione del cluster, la reimpostazione di cluster o nodi, gli upgrade dei cluster e gli aggiornamenti dei cluster. Il numero totale di nodi del cluster utente è uno dei principali fattori che limitano le prestazioni e l'affidabilità.

In base ai 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 il numero di pod per cluster utente a 15.000 o meno. Ad esempio, se il cluster ha 200 nodi, devi limitare il numero di pod per nodo a 75 o meno. Allo stesso modo, se vuoi eseguire 110 pod per nodo, devi limitare il numero di nodi nel cluster a 136 o meno. La seguente tabella fornisce esempi di configurazioni consigliate e sconsigliate.

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 sui suggerimenti relativi a pod per nodo e nodi per cluster utente nelle sezioni seguenti.

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 esegui 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 l'incompatibilità node-role.kubernetes.io/master:NoSchedule per eseguire i 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 nell'impostazione nodeConfig.PodDensity.MaxPodsPerNode del file di configurazione del cluster. La tabella seguente mostra i valori minimo e massimo supportati per MaxPodsPerNode, che include i 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 di 100.000 endpoint. Questo numero è la somma di tutti i pod a cui fa riferimento un servizio Kubernetes. Se due servizi fanno riferimento allo stesso insieme di pod, questa situazione conta come due insiemi separati di endpoint. L'implementazione nftable sottostante su RHEL causa questa limitazione; non è un limite intrinseco di Google Distributed Cloud.

Mitigazione

Per RHEL, non sono previste mitigazioni. Per i sistemi Ubuntu e Debian ti consigliamo di passare dal modello nftables predefinito alla versione legacy iptables sui cluster su larga scala.

GKE Dataplane V2

Google Distributed Cloud utilizza GKE Dataplane V2, un dataplane del cluster implementato con Cilium ed eBPF, ottimizzato per il networking di Kubernetes.

Limiti `NetworkPolicy` di GKE Dataplane V2

GKE Dataplane V2 utilizza Cilium per gestire le risorse NetworkPolicy di Kubernetes. I seguenti limiti si applicano ai tuoi cluster GKE on Bare Metal:

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. Se le modifiche non sono frequenti, ad esempio ogni secondo, o se il numero di identità cilium (set di etichette univoche) non è vicino al limite: 16.000 set di etichette con criteri di rete allow all o 65.535 set di etichette per cluster.
Numero massimo di endpoint di servizio per cluster	100.000 endpoint è il limite testato e consigliato. Il limite impostato come hardcoded per gli endpoint di servizio è 262.000.
Numero massimo di criteri e regole di rete	Al massimo 40.000 criteri di rete e 80.000 regole. Ad esempio, puoi specificare 40.000 criteri di rete con due regole ciascuno oppure 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 (2¹⁶-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 è composta da quanto segue: 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 questo comando per recuperare le voci attuali:

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. L'intervallo di porte predefinito è 30000-32767. Se superi il limite, non puoi creare nuovi servizi LoadBalancer o NodePort e non puoi aggiungere nuove porte dei nodi per 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 dalle 2768 allocate al tuo cluster. Per salvare le porte del nodo, disabilita l'allocazione delle porte del nodo del bilanciatore del carico impostando il campo allocateLoadBalancerNodePorts su false nella specifica del servizio LoadBalancer. Questa impostazione impedisce a Kubernetes di allocare le porte del nodo ai servizi LoadBalancer. Per ulteriori informazioni, consulta 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, le richieste al servizio LoadBalancer potrebbero non riuscire.

Se hai bisogno di esporre un servizio di bilanciamento del carico in grado di gestire un numero considerevole di connessioni (per Ingress, ad esempio), ti consigliamo di prendere in considerazione un metodo di bilanciamento del carico alternativo per evitare questa limitazione con 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 nella console Google Cloud:

Vai a Quote

Informazioni sulla scalabilità

Le informazioni contenute in questo documento sono pertinenti per pianificare come fare lo scale up dei 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 facci sapere cosa manca.