Questa pagina descrive le best practice che puoi seguire durante la pianificazione e la progettazione di cluster di dimensioni molto grandi.
Perché pianificare cluster GKE di grandi dimensioni
Ogni sistema informatico, incluso Kubernetes, ha dei limiti architetturali. Il superamento dei limiti potrebbe influire sulle prestazioni del cluster o, in alcuni casi, causare anche tempi di inattività. Segui le best practice ed esegui le azioni consigliate per assicurarti che i cluster eseguano i workload in modo affidabile su larga scala.
Limitazioni dei cluster GKE di grandi dimensioni
Quando GKE scala un cluster a un numero elevato di nodi, si impegna a modificare la quantità di risorse disponibili in modo che corrispondano alle esigenze del sistema, rimanendo entro gli obiettivi del livello di servizio (SLO).Google Cloud supporta i cluster di grandi dimensioni. Tuttavia, in base al tuo caso d'uso, devi tenere conto delle limitazioni dei cluster di grandi dimensioni per rispondere meglio ai requisiti di scalabilità dell'infrastruttura.
Questa sezione descrive le limitazioni e le considerazioni da tenere presenti quando progetti cluster GKE di grandi dimensioni in base al numero previsto di nodi.
Cluster con un massimo di 5000 nodi
Quando progetti l'architettura del cluster per scalare fino a 5000 nodi, considera le seguenti condizioni:
- Disponibile solo per il cluster regionale.
- Disponibile solo per i cluster che utilizzano Private Service Connect.
- La migrazione dai cluster di zona a quelli regionali richiede la ricreazione del cluster per sbloccare un livello di quota dei nodi più elevato.
Se prevedi di scalare il cluster oltre 5000 nodi, contatta l'assistenza clienti Google Cloud per aumentare le dimensioni del cluster e il limite di quota.
Cluster con più di 5000 nodi
GKE supporta cluster Standard di grandi dimensioni fino a 15.000 nodi. Nella versione 1.31 e successive, GKE supporta cluster di grandi dimensioni fino a 65.000 nodi. Il limite di 65.000 è pensato per l'esecuzione di carichi di lavoro AI su larga scala.
Se prevedi di scalare il cluster a 15.000 o 65.000 nodi, completa le seguenti attività:
Tieni presenti le seguenti limitazioni:
- Il gestore della scalabilità automatica dei cluster non è supportato. Scala i pool di nodi verso l'alto o verso il basso utilizzando l'API GKE.
- Multi-network non è supportato.
- I servizi con più di 100 pod devono essere headless.
- Ogni pod deve essere eseguito sul proprio nodo, ad eccezione dei DaemonSet di sistema. Per definire la pianificazione dei pod su nodi specifici, puoi utilizzare l'affinità o l'anti-affinità dei pod di Kubernetes.
- La migrazione dai cluster di zona a quelli regionali richiede la ricreazione del cluster per sbloccare un livello di quota dei nodi più elevato.
- La migrazione ai cluster che utilizzano Private Service Connect richiede la ricreazione del cluster per sbloccare il livello di quota dei nodi più elevato.
Contatta l'assistenza clienti cloud per aumentare le dimensioni del cluster e il limite di quota a 15.000 nodi o a 65.000 nodi, a seconda delle tue esigenze di scalabilità.
Best practice per la suddivisione dei carichi di lavoro tra più cluster
Puoi eseguire i carichi di lavoro su un singolo cluster di grandi dimensioni. Questo approccio è più facile da gestire, più conveniente e offre un migliore utilizzo delle risorse rispetto a più cluster. Tuttavia, in alcuni casi devi considerare di dividere il carico di lavoro in più cluster:
- Consulta Casi d'uso multi-cluster per scoprire di più sui requisiti generali e sugli scenari per l'utilizzo di più cluster.
- Inoltre, dal punto di vista della scalabilità, dividi il cluster quando potrebbe superare uno dei limiti descritti nella sezione seguente o una delle quote GKE. Ridurre qualsiasi rischio di raggiungere i limiti di GKE riduce il rischio di tempi di inattività o altri problemi di affidabilità.
Se decidi di dividere il cluster, utilizza Fleet management per semplificare la gestione di un parco risorse multi-cluster.
Limiti e best practice
Per assicurarti che la tua architettura supporti cluster GKE su larga scala, rivedi i seguenti limiti e le best practice correlate. Il superamento di questi limiti può causare un peggioramento delle prestazioni del cluster o problemi di affidabilità.
Queste best practice si applicano a qualsiasi cluster Kubernetes predefinito senza estensioni installate. L'estensione dei cluster Kubernetes con webhook o definizioni di risorse personalizzate (CRD) è comune, ma può limitare la capacità di scalare il cluster.
La seguente tabella estende le principali quote e limiti di GKE. Devi anche familiarizzare con i limiti di Kubernetes open source per i cluster su larga scala.
I requisiti di versione di GKE menzionati nella tabella si applicano sia ai nodi sia al control plane.
| Limite GKE | Descrizione | Best practice |
|---|---|---|
| Dimensioni del database etcd | La dimensione massima del database etcd è 6 GB. Ti consigliamo di monitorare in modo proattivo le dimensioni del database etcd del cluster e configurare avvisi per ricevere notifiche quando l'utilizzo si avvicina a questo limite. Il superamento del limite può causare problemi al control plane. | Puoi utilizzare le seguenti risorse per monitorare l'utilizzo:
Per saperne di più su come rispondere quando ti avvicini al limite, vedi Identificare i cluster in cui l'utilizzo di etcd si sta avvicinando al limite. |
| Dimensioni totali degli oggetti etcd per tipo | La dimensione totale di tutti gli oggetti del tipo di risorsa specificato non deve superare 800 MB. Ad esempio, puoi creare 750 MB di istanze Pod e 750 MB di secret, ma non puoi creare 850 MB di secret. Se crei più di 800 MB di oggetti, l'inizializzazione di Kubernetes o dei controller personalizzati potrebbe non riuscire e causare interruzioni. |
Mantieni la dimensione totale di tutti gli oggetti di ogni tipo archiviati in etcd al di sotto di 800 MB. Ciò vale soprattutto per i cluster che utilizzano molti Secret o ConfigMap di grandi dimensioni o un volume elevato di CRD. |
| Numero di servizi per i cluster in cui GKE Dataplane V2 non è abilitato | Il rendimento di iptables utilizzato da kube-proxy peggiora se si verifica una delle seguenti condizioni:
Questo limite viene eliminato quando è abilitato GKE Dataplane V2. |
Mantieni il numero di servizi nel cluster al di sotto di 10.000. Per saperne di più, consulta la sezione Esporre le applicazioni utilizzando i servizi. |
| Numero di servizi per spazio dei nomi | Il numero di variabili di ambiente generate per i servizi potrebbe superare i limiti della shell. Ciò potrebbe causare l'arresto anomalo dei pod all'avvio. |
Mantieni il numero di servizi per spazio dei nomi inferiore a 5000. Puoi disattivare il popolamento di queste variabili di ambiente. Consulta la documentazione per scoprire come impostare Per saperne di più, consulta la sezione Esporre le applicazioni utilizzando i servizi. |
| Numero di pod dietro un singolo servizio per i cluster in cui GKE Dataplane V2 non è abilitato |
Ogni nodo esegue un kube-proxy che utilizza watch per monitorare qualsiasi modifica del servizio. Più grande è un cluster, più dati relativi alle modifiche vengono elaborati dall'agente. Ciò è particolarmente visibile nei cluster con più di 500 nodi. Le informazioni sugli endpoint sono suddivise
in Gli oggetti endpoint sono ancora disponibili per i componenti, ma qualsiasi endpoint sopra i 1000 pod viene automaticamente troncato. |
Mantieni il numero di pod dietro un singolo servizio inferiore a 10.000. Per saperne di più, consulta la sezione Esporre le applicazioni utilizzando i servizi. |
| Numero di pod dietro un singolo servizio per i cluster in cui è abilitato GKE Dataplane V2 |
GKE Dataplane V2 contiene limiti al numero di pod esposti da un singolo servizio. Lo stesso limite è applicabile ai cluster Autopilot, in quanto utilizzano GKE Dataplane V2. |
In GKE 1.23 e versioni precedenti, mantieni il numero di pod dietro un singolo servizio inferiore a 1000. In GKE 1.24 e versioni successive, mantieni il numero di pod dietro un singolo servizio inferiore a 10.000. Per saperne di più, consulta la sezione Esporre le applicazioni utilizzando i servizi. |
| Record DNS per servizio headless |
Il numero di record DNS per servizio headless è limitato sia per kube-dns che per Cloud DNS. |
Mantieni il numero di record DNS per servizio headless inferiore a 1000 per kube-dns e 3500/2000 (IPv4/IPv6) per Cloud DNS. |
| Numero di tutti gli endpoint di servizio | Il numero di endpoint in tutti i servizi potrebbe raggiungere i limiti. Ciò potrebbe aumentare la latenza di programmazione o impedire del tutto la programmazione di nuovi endpoint. |
Mantieni il numero di tutti gli endpoint in tutti i servizi al di sotto di 260.000. GKE Dataplane V2, che è il dataplane predefinito per GKE Autopilot, si basa su mappe eBPF attualmente limitate a 260.000 endpoint in tutti i servizi. |
| Numero di oggetti Horizontal Pod Autoscaler per cluster |
Ogni Horizontal Pod Autoscaler (HPA) viene elaborato ogni 15 secondi. Più di 300 oggetti HPA possono causare un peggioramento lineare delle prestazioni. |
Mantieni il numero di oggetti HPA entro questo limite, altrimenti potresti riscontrare un degrado lineare della frequenza di elaborazione HPA. Ad esempio,in GKE 1.22 con 2000 HPA, una singola HPA verrà rielaborata ogni 1 minuto e 40 secondi. Per saperne di più, consulta Scalabilità automatica basata sull'utilizzo delle risorse e Scalabilità automatica orizzontale dei pod. |
| Numero di pod per nodo | GKE ha un limite rigido di 256 pod per nodo. Ciò presuppone una media di due o meno container per pod. Se aumenti il numero di container per pod, questo limite potrebbe essere inferiore perché GKE alloca più risorse per container. |
Ti consigliamo di utilizzare nodi worker con almeno una vCPU ogni 10 pod. Per saperne di più, consulta l'articolo Aggiornamento manuale di un cluster o di un pool di nodi. |
| Tasso di modifiche al pod |
Kubernetes ha limiti interni che influiscono sulla velocità di creazione o eliminazione dei pod (churn dei pod) in risposta alle richieste di scalabilità. Anche altri fattori, come l'eliminazione di un pod che fa parte di un servizio, possono influire sul tasso di abbandono dei pod. Per i cluster con un massimo di 500 nodi, puoi prevedere una velocità media di 20 pod creati al secondo e 20 pod eliminati al secondo. Per i cluster con più di 500 nodi, puoi prevedere una velocità media di 100 pod creati al secondo e 100 pod eliminati al secondo. |
Tieni presente il limite di frequenza di creazione ed eliminazione dei pod quando pianifichi lo scaling dei carichi di lavoro. I pod condividono la stessa velocità effettiva di eliminazione con altri tipi di risorse (ad esempio EndpointSlice). Puoi ridurre la velocità effettiva di eliminazione quando definisci i pod come parte di un servizio. Per consentire al gestore della scalabilità automatica dei cluster di rimuovere efficacemente i pod dai nodi sottoutilizzati, evita PodDisruptionBudgets troppo restrittivi e periodi di tolleranza del termine lunghi. Sono sconsigliate anche le tolleranze con caratteri jolly, in quanto possono causare la pianificazione dei carichi di lavoro sui nodi in fase di rimozione. |
| Numero di smartwatch aperti | I nodi creano un'osservazione per ogni Secret e ConfigMaps che configuri per i pod. La quantità combinata di watch creati da tutti i nodi potrebbe generare un carico notevole sul control plane del cluster. Avere più di 200.000 osservazioni per cluster potrebbe influire sul tempo di inizializzazione del cluster. Questo problema può causare il riavvio frequente del control plane. |
Definisci nodi più grandi per ridurre la probabilità e la gravità dei problemi causati da un numero elevato di visualizzazioni. Una densità di pod più elevata (meno nodi di grandi dimensioni) potrebbe ridurre il numero di visualizzazioni e mitigare la gravità del problema. Per saperne di più, consulta il confronto tra le serie di macchine. |
| Numero di secret per cluster se la crittografia dei secret a livello di applicazione è abilitata | Un cluster deve decriptare tutti i secret durante l'avvio del cluster quando è abilitata la crittografia dei secret a livello di applicazione. Se memorizzi più di 30.000 secret, il cluster potrebbe diventare instabile durante l'avvio o gli upgrade, causando interruzioni del workload. | Archivia meno di 30.000 secret quando utilizzi la crittografia dei secret a livello di applicazione. Per saperne di più, consulta la sezione Crittografia dei secret a livello di applicazione. |
| Larghezza di banda dei log per nodo |
Esiste un limite alla quantità massima di log inviati da ogni nodo all'API Cloud Logging. Il limite predefinito varia tra 100 Kbps e 500 Kbps, a seconda del carico. Per i cluster Standard, puoi aumentare il limite a 10 MiB eseguendo il deployment di una configurazione dell'agente Logging ad alta velocità effettiva. Il superamento di questo limite potrebbe causare l'eliminazione delle voci di log. |
Configura Logging in modo da rispettare i limiti predefiniti o configura un agente Logging ad alto rendimento. Per saperne di più, vedi Regolazione della velocità effettiva dei log. |
| Pool di nodi | Un numero elevato di node pool può influire sulla latenza della scalabilità automatica dell'infrastruttura perché aumenta l'insieme di nodi che possono essere potenzialmente aggiunti al cluster. Funzionalità come la separazione dei workload o le classi di computing personalizzate aumentano il numero di node pool. | Mantieni il numero di node pool inferiore a 200. |
| Limiti di Backup per GKE |
Puoi utilizzare Backup per GKE per eseguire il backup e il ripristino dei tuoi carichi di lavoro GKE. Backup per GKE è soggetto a limiti da tenere presente quando definisci i tuoi piani di backup. |
Esamina i limiti di Backup per GKE. Se è possibile che il tuo carico di lavoro superi questi limiti, ti consigliamo di creare più piani di backup per partizionare il backup e rimanere entro i limiti. |
| Limiti di Config Connector |
Puoi utilizzare Config Connector per gestire le risorse Google Cloud tramite Kubernetes. Config Connector ha due modalità di funzionamento:
|
Per informazioni dettagliate sui limiti delle risorse, consulta Linee guida per la scalabilità di Config Controller. Per informazioni sulla gestione di un numero elevato di risorse, consulta le best practice di Config Connector. |