Questa pagina descrive le quote e i limiti della release 1.14 di GKE su Bare Metal per progetti, cluster e 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. Allo stesso modo, se vuoi eseguire 110 pod per nodo, devi limitare il numero di nodi nel cluster a 136 o meno. La tabella riportata di seguito fornisce esempi di configurazioni consigliate e sconsigliate.
| Pod per nodo | Nodi per cluster | Pod per cluster | Risultato |
|---|---|---|---|
| 110 | 200 | 22.000 | Troppi pod, opzione sconsigliata |
| 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 cluster consigliato ha la precedenza sui suggerimenti relativi a pod per nodo e nodi per cluster nelle sezioni seguenti.
Numero massimo di nodi per cluster
Testiamo GKE 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 di nodi consigliato | Numero massimo di nodi assoluto |
|---|---|---|---|
| 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 di Kubernetes.
Numero massimo di pod per nodo
GKE su Bare Metal 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 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 RHEL e CentOS è previsto un limite di 100.000 endpoint a livello di cluster.
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 sottostante di nftable su RHEL e CentOS causa questa limitazione; non è un limite intrinseco di GKE su Bare Metal.
Attenuazione
Per RHEL e CentOS non sono previste mitigazioni. Per i sistemi Ubuntu e Debian, ti consigliamo di passare dal valore predefinito nftables alla versione legacy iptables sui cluster su larga scala.
Limite eBPF Dataplane V2
Il numero massimo di voci nella mappa lbBPF 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 cluster per assicurarti di non superare il limite. Utilizza il seguente comando 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 dei servizi LoadBalancer e NodePort
Il limite di porte per i servizi LoadBalancer e NodePort è di 2768. L'intervallo di porte predefinito è 30.000-32.767. Se superi il limite, non potrai creare nuovi servizi LoadBalancer o NodePort né aggiungere nuove porte di nodo 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 assegnate al cluster. Per salvare le porte dei nodi, disabilita 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 assegnare le porte dei nodi ai servizi LoadBalancer. Per ulteriori informazioni, consulta Disabilitazione dell'allocazione di NodePort del bilanciatore del carico nella documentazione di Kubernetes.
Utilizza il comando seguente per verificare il numero di porte attualmente 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 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 di bilanciamento del carico alternativo per evitare questa limitazione con MetalLB.
Quote dei 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:
Problemi di scalabilità
Questa sezione descrive alcuni problemi da tenere presente durante la scalabilità dei cluster.
Risorse riservate per i daemon di sistema
A partire dalla versione 1.14, GKE su Bare Metal prenota automaticamente
le risorse su un nodo per i daemon di sistema come sshd o udev. Le risorse di CPU e memoria sono riservate su un nodo per i daemon di sistema, in modo che dispongano delle risorse necessarie. Senza questa funzionalità, abilitata per impostazione predefinita, i pod possono potenzialmente consumare la maggior parte delle risorse su un nodo, impedendo ai daemon di sistema di completare le proprie attività.
Nello specifico, GKE su Bare Metal riserva 50 millicore di CPU (50 mCPU) e 280 Mebibyte (280 MiB) di memoria su ciascun nodo per i daemon di sistema. Tieni presente che l'unità CPU "mCPU" è l'acronimo di "millesima di core", quindi il 50/1000 o il 5% di un core su ciascun nodo è riservato ai daemon di sistema. La quantità di risorse prenotate è ridotta e non ha un impatto significativo sulle prestazioni del pod. Tuttavia, il kubelet su un nodo potrebbe rimuovere i pod se il loro utilizzo di CPU o memoria supera le quantità allocate.
prestazioni etcd
La velocità del disco è fondamentale per la stabilità e le prestazioni di etcd. Un disco lento aumenta la latenza delle richieste etcd, che può portare a problemi di stabilità del cluster. Ti consigliamo di utilizzare un disco a stato solido (SSD) per l'archivio etcd. La documentazione etcd fornisce ulteriori consigli sull'hardware per garantire le migliori prestazioni etcd durante l'esecuzione dei cluster in produzione.
Per verificare le prestazioni etcd e del disco, utilizza le seguenti metriche di latenza I/O etcd in Metrics Explorer:
etcd_disk_backend_commit_duration_seconds: la durata dovrebbe essere inferiore a 25 millisecondi per il 99° percentile (p99).etcd_disk_wal_fsync_duration_seconds: la durata deve essere inferiore a 10 millisecondi per il 99° percentile (p99).
Per ulteriori informazioni sulle prestazioni etcd, consulta Che cosa significa l'avviso etcd "l'applicazione delle voci ha richiesto troppo tempo"? e Che cosa significa l'avviso etcd "Impossibile inviare l'heartbeat in tempo"?.
Non hai trovato quello che stavi cercando? Fai clic su Invia feedback e facci sapere cosa manca.