Questa pagina spiega i cluster Anthos sulle quote della release 1.8 e sui limiti di Bare Metal per i progetti, i cluster e i nodi di Google Cloud.
Limiti
Tieni presente i seguenti limiti e suggerimenti per i cluster.
Numero massimo di pod per cluster
Ti consigliamo di limitare il numero di pod per cluster a un massimo di 15.000. 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 seguente tabella 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 | Entro i limiti |
| 100 | 150 | 15.000 | Entro i limiti |
| 75 | 200 | 15.000 | Entro i limiti |
Il numero massimo di pod per consiglio del cluster ha la precedenza sui suggerimenti per i pod per nodo e i nodi per cluster nelle sezioni seguenti.
Numero massimo di nodi per cluster
Testiamo cluster Anthos su Bare Metal 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 durante l'esecuzione dei carichi di lavoro in produzione.
| Tipo di cluster | Numero minimo di nodi | Numero massimo consigliato di nodi | Numero massimo assoluto di nodi |
|---|---|---|---|
| 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, consulta Incompatibilità e tolleranze Kubernetes.
Numero massimo di pod per nodo
I cluster Anthos su Bare Metal supportano la configurazione del numero massimo di pod per nodo nell'impostazione nodeConfig.PodDensity.MaxPodsPerNode del file di configurazione del cluster. La seguente tabella 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 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 RHEL e CentOS, esiste una limitazione a livello di cluster di 100.000 endpoint.
Questo numero è la somma di tutti i pod a cui si fa riferimento in un servizio Kubernetes.
Se due servizi fanno riferimento allo stesso insieme di pod, questa situazione viene conteggiata come due insiemi separati di endpoint. L'implementazione nftable sottostante su RHEL e
CentOS causa questa limitazione; non è una limitazione intrinseca dei
cluster Anthos su Bare Metal.
Attenuazione
Per RHEL e CentOS, non ci sono mitigazioni. Per i sistemi Ubuntu e Debian, ti consigliamo di passare dal metodo predefinito iptables al precedente iptables sui cluster su larga scala.
Limite eBPF V2 piano dati
Il numero massimo di voci nella lbmap BPF per Dataplane V2 è 65.536. L'aumento nelle seguenti aree può causare la crescita 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 comando seguente per ottenere le 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 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 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 potrai creare nuovi servizi LoadBalancer o NodePort e non potrai aggiungere nuove porte dei nodi per i servizi esistenti.
Utilizza il comando seguente per verificare il numero di porte attualmente assegnate:
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 ciascun nodo utilizzato per il bilanciamento del carico in bundle (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 considerevole di connessioni (ad esempio per Ingress), ti consigliamo di prendere in considerazione un metodo alternativo di bilanciamento del carico per evitare questa limitazione con MetalLB.
Quote di cluster
Puoi registrare un massimo di 15 cluster per impostazione predefinita. Per registrare altri cluster in GKE Hub, puoi inviare una richiesta per aumentare la quota in Google Cloud Console:
Non hai trovato quello che stavi cercando? Fai clic su Invia feedback e facci sapere cosa manca.