Distributed Cloud (solo software) per bare metal applica quote e limiti a Google Cloud progetti, cluster e nodi. Queste soglie definiscono le registrazioni dei parchi risorse, le capacità dei cluster e i limiti delle risorse dei nodi supportati per aiutarti a pianificare e scalare i deployment bare metal.
Limiti
Le sezioni seguenti descrivono alcuni limiti di base per i cluster. Tieni conto di questi limiti quando progetti le tue applicazioni da eseguire 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 dei cluster utente, come la creazione, la reimpostazione, l'upgrade e l'aggiornamento dei cluster o dei nodi. Il numero totale di nodi del cluster utente è uno dei fattori principali 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. Analogamente, se vuoi eseguire 110 pod per nodo, devi limitare il numero di nodi nel cluster a 136 o meno. La tabella seguente fornisce esempi di configurazioni consigliate e non consigliate.
| Pod per nodo | Nodi per cluster | Pod per cluster | Risultato |
|---|---|---|---|
| 110 | 200 | 22.000 | Troppi pod, non consigliato |
| 110 | 136 | 14.960 | Nei limiti |
| 100 | 150 | 15.000 | Nei limiti |
| 75 | 200 | 15.000 | Nei limiti |
Il suggerimento sul numero massimo di pod per cluster utente ha la precedenza sui suggerimenti per i pod per nodo e i nodi per cluster utente nelle sezioni seguenti.
Numero massimo di nodi per cluster utente
Testiamo Google Distributed Cloud per eseguire workload con un massimo di 500 nodi. Tuttavia, per garantire prestazioni e affidabilità ottimali, ti consigliamo di non superare i 200 nodi per cluster durante l'esecuzione dei workload in produzione.
| Tipo di cluster | Numero minimo di nodi | Numero massimo di nodi consigliato | Numero massimo assoluto di nodi |
|---|---|---|---|
| Utente, autonomo o ibrido | 1 | 200 | 500 |
Per i cluster a nodo singolo, devi rimuovere la contaminazione node-role.kubernetes.io/master:NoSchedule per eseguire i workload sul nodo.
Per maggiori dettagli, consulta Tolleranze e incompatibilità 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 minimi e massimi 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 viene conteggiata come due insiemi di endpoint separati. L'implementazione nftable sottostante su RHEL causa questa limitazione, che non è una limitazione intrinseca di Google Distributed Cloud.
Mitigazione
Per RHEL, non sono previste mitigazioni. Per i sistemi Ubuntu e Debian, ti consigliamo di
passare dal valore predefinito nftables al valore legacy
iptables sui
cluster su larga scala.
Dataplane V2
Google Distributed Cloud utilizza Dataplane V2, un piano dati del cluster implementato con Cilium ed eBPF, ottimizzato per il networking di Kubernetes.
Limiti di Dataplane V2 NetworkPolicy
Dataplane V2 utilizza Cilium per gestire le risorse NetworkPolicy di Kubernetes. I seguenti limiti si applicano ai tuoi cluster:
| Dimensioni | Limiti supportati |
|---|---|
| Frequenza di modifica massima 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. A condizione che le modifiche non siano frequenti, ad esempio ogni secondo, o che il numero di identità Cilium (insiemi di etichette univoci) non sia vicino al limite: 16.000 insiemi di etichette con policy di rete Consenti tutto o 65.535 insiemi 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 policy di rete e regole | Al massimo, 40.000 policy di rete e 80.000 regole. Ad esempio, puoi specificare 40.000 policy di rete con due regole ciascuna o 20.000 policy con quattro regole ciascuna. |
| Frequenza massima di modifica per le policy di rete | Al massimo, 20 modifiche (creazioni o eliminazioni) al secondo. |
| Numero massimo di set di etichette dei pod univoci | 65.535 (216-1). Questo è il limite dell'identità di sicurezza Cilium. |
| Numero massimo di set di etichette di pod univoci selezionati dai selettori di policy | 16.000 (la dimensione fissa della mappa eBPF). Una determinata voce della mappa del selettore delle policy è costituita da: security-identity, port e protocol. |
Limite eBPF di Dataplane V2
Il numero massimo di voci nella mappa lbmap BPF per Dataplane V2 è 65.536. Gli aumenti nelle seguenti aree possono causare un 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 tuo cluster per assicurarti di non superare il limite. Utilizza il seguente comando per ottenere 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 causa 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 dei servizi LoadBalancer e 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 tra le 2768 assegnate al tuo cluster. Per salvare le porte dei nodi, disattiva l'allocazione delle porte dei nodi del bilanciatore del carico impostando il campo allocateLoadBalancerNodePorts su false nella specifica del servizio LoadBalancer.
Questa impostazione impedisce a Kubernetes di allocare porte dei nodi ai servizi LoadBalancer. Per saperne di più, consulta
Disattivazione dell'allocazione NodePort del bilanciatore del carico
nella documentazione di Kubernetes.
Utilizza il seguente comando per controllare 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 integrato (MetalLB) è 28.000. L'intervallo di porte temporanee predefinito per queste connessioni è 32768-60999. Se superi il limite di connessioni, le richieste al servizio LoadBalancer potrebbero non riuscire.
Se devi esporre un servizio di bilanciamento del carico in grado di gestire un numero elevato di connessioni (ad esempio per Ingress), ti consigliamo di prendere in considerazione un metodo di bilanciamento del carico alternativo per evitare questa limitazione con MetalLB.
Quote dei cluster
Per impostazione predefinita, puoi registrare un massimo di 250 cluster con appartenenze globali per parco risorse. Per registrare più cluster in GKE Hub, puoi inviare una richiesta per aumentare la quota nella console Google Cloud :
Per ulteriori informazioni sulle quote dei cluster in base alle impostazioni di appartenenza, consulta Quote di allocazione.
Informazioni sulla scalabilità
Le informazioni contenute in questo documento sono utili per pianificare lo scale up dei cluster. Per saperne di più, consulta Fai lo scale up dei cluster Google Distributed Cloud.
Non hai trovato quello che stavi cercando? Fai clic su Invia feedback e comunicaci cosa manca.