In questa pagina vengono descritte le best practice che puoi seguire quando pianificare e progettare cluster di grandi dimensioni.
Perché pianificare cluster GKE di grandi dimensioni
Ogni sistema informatico, incluso Kubernetes, presenta alcuni limiti di architettura. Il superamento dei limiti potrebbe influire sulle prestazioni del cluster o negli stessi casi o causare tempi di inattività. Segui le best practice ed esegui le azioni consigliate per garantire che i tuoi cluster eseguano i carichi di lavoro in modo affidabile su larga scala.
Best practice per la suddivisione dei carichi di lavoro tra più cluster
Puoi eseguire i tuoi carichi di lavoro su un unico cluster di grandi dimensioni. Questo approccio è più facile da gestire, più economico e offre un utilizzo migliore delle risorse rispetto a più cluster. Tuttavia, in alcuni casi è necessario valutare la suddivisione dei in più cluster:
- Consulta i casi d'uso multi-cluster per saperne di più sui requisiti generali e sugli scenari per l'utilizzo di più cluster.
- Inoltre, dal punto di vista della scalabilità, suddividi il cluster quando potrebbe superare uno dei limiti descritti nella sezione di seguito o uno dei Quote di GKE. Ridurre qualsiasi rischio a il raggiungimento dei limiti GKE, riduce il rischio di tempi di inattività o problemi di affidabilità.
Se decidi di suddividere il cluster, utilizza la gestione del parco risorse per semplificare la gestione di un parco risorse multi-cluster.
Limiti e best practice
Per assicurarti che la tua architettura supporti i cluster GKE su larga scala, esamina i seguenti limiti e le best practice correlate. Superato questi limiti possono causare il degrado 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 è una pratica comune, ma può limitare la possibilità di eseguire lo scale del cluster.
La tabella seguente estende le Quote e limiti di GKE. Inoltre, devi conoscere 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 piano di controllo.
| Limite GKE | Descrizione | Best practice |
|---|---|---|
| Dimensione del database etcd | La dimensione massima del database etcd è di 6 GB. Se gestisci un modello di un cluster con decine di migliaia di risorse, le tue istanze etcd potrebbero superare questo limite. Puoi controllare il livello di utilizzo per i cluster nella console Google Cloud. | Se superi questo limite, GKE potrebbe contrassegnare le tue istanze etcd
in stato non integro. Di conseguenza, il piano di controllo
dei cluster non risponde.
Se superi questo limite, contatta l'assistenza Google Cloud. |
| Dimensione totale degli oggetti etcd per tipo | La dimensione totale di tutti gli oggetti del tipo di risorsa specificato non deve superare gli 800 MB. Ad esempio, puoi creare 750 MB di istanze di pod e 750 MB di secret, ma non puoi creare 850 MB di secret. Se crei più di 800 MB di oggetti, l'inizializzazione dei controller Kubernetes o personalizzati potrebbe causare interruzioni. |
Mantieni sotto la dimensione totale di tutti gli oggetti di ogni tipo archiviati in etcd 800 MB. Questo è particolarmente applicabile ai 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 scoprire di più, consulta Esposizione delle 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 al di sotto di 5000. Puoi disattivare il completamento di queste variabili di ambiente. Consulta la documentazione su come impostare Per scoprire di più, consulta Esposizione delle 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 i watch per monitorare qualsiasi modifica del servizio. Più grande è un cluster, più e i dati correlati al cambiamento elaborati dall'agente. Questo è particolarmente evidente nei cluster con più di 500 nodi. Le informazioni sugli endpoint sono suddivise
tra Gli oggetti endpoint sono ancora disponibili per i componenti, ma qualsiasi endpoint superiore a 1000 pod viene troncato automaticamente. |
Mantieni il numero di pod dietro un singolo servizio inferiore a 10.000. Per scoprire di più, consulta la sezione Esporre le applicazioni che utilizzano 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 si applica 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 scoprire 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 sia per Cloud DNS. |
Mantieni il numero di record DNS per servizio headless inferiore a 1000 per kube-dns e a 3500/2000 (IPv4/IPv6) per Cloud DNS. |
| Numero di tutti gli endpoint di servizio | Il numero di endpoint in tutti i Servizi può raggiungere i limiti. Ciò potrebbe aumentare la latenza di programmazione o determinare l'impossibilità di programmare nuovi endpoint. |
Mantieni il numero di tutti gli endpoint in tutti i servizi al di sotto di 260.000. GKE Dataplane V2, che è il piano dati predefinito per GKE Autopilot, si basa su mappe eBPF che attualmente sono 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; in caso contrario, potresti riscontrare un degrado lineare della frequenza di elaborazione dell'HPA. Ad esempio, in GKE 1.22 con 2000 HPA, un singolo HPA verrà elaborato di nuovo ogni 1 minuto e 40 secondi. Per scoprire di più, consulta la scalabilità automatica in base all'utilizzo delle risorse e la scalabilità della scalabilità automatica orizzontale dei pod. |
| Numero di pod per nodo | GKE ha un limite massimo di 256 pod per nodo. Questo valore presuppone una media di due o meno di 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 per ogni 10 pod. Per saperne di più, consulta l'articolo sull'upgrade manuale di un cluster o di un pool di nodi. |
| Frequenza delle modifiche ai pod |
Kubernetes prevede limiti interni che influiscono sulla frequenza di creazione o eliminazione di pod (abbandono 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 su questo tasso di abbandono dei pod. Per i cluster con un massimo di 500 nodi, puoi prevedere una frequenza media di 20 pod creati al secondo ed eliminazione di 20 pod al secondo. Per i cluster con più di 500 nodi, puoi aspettarti una frequenza media di 100 pod creati e 100 pod eliminati al secondo. |
Quando pianifichi la scalabilità dei tuoi carichi di lavoro, tieni in considerazione il limite di frequenza di creazione ed eliminazione dei pod. I pod condividono lo stesso throughput di eliminazione con altri tipi di risorse (ad esempio EndpointSlices). Puoi ridurre il throughput di eliminazione quando definisci i pod all'interno di un servizio. Per consentire a Cluster Autoscaler di rimuovere efficacemente i pod dai nodi sottoutilizzati, evita PodDisruptionBudget troppo restrittivi e periodi di tolleranza per la terminazione lunghi. Anche le tolleranze con caratteri jolly sono sconsigliate, in quanto possono causare la pianificazione di carichi di lavoro su nodi che stanno per essere rimossi. |
| Numero di orologi aperti | I nodi creano un watch per ogni Secret e ConfigMaps che configuri per i pod. La quantità combinata di smartwatch creati da tutti i nodi può generare un carico sostanziale sul piano di controllo del cluster. Avere più di 200.000 smartwatch per cluster potrebbe influire sul tempo di inizializzazione del cluster. Questo problema può causare il riavvio frequente del piano di controllo. |
Definisci nodi più grandi per ridurre la probabilità e la gravità dei problemi causati da un numero elevato di smartwatch. Una maggiore densità di pod (meno nodi di grandi dimensioni) potrebbe ridurre il numero di smartwatch e mitigare la gravità del problema. Per saperne di più, consulta il confronto delle serie di macchine. |
| Numero di secret per cluster se la crittografia dei secret a livello di applicazione è attivata | Un cluster deve decriptare tutti i secret durante l'avvio, quando è abilitata la crittografia dei secret a livello di applicazione. Se archivi più di 30.000 secret, il cluster potrebbe diventare instabile durante l'avvio o gli upgrade, causando interruzioni dei carichi di lavoro. | Memorizza meno di 30.000 secret quando utilizzi la crittografia dei secret a livello di applicazione. Per saperne di più, consulta l'articolo sulla crittografia dei secret a livello di applicazione. |
| Larghezza di banda del log per nodo |
Esiste un limite alla quantità massima di log inviati da ciascun nodo all'API Cloud Logging. Il limite predefinito varia da 100 a 500 Kbps a seconda del carico. Puoi aumentare il limite a 10 Mbps eseguendo il deployment di una configurazione di agente Logging a velocità effettiva elevata. Superare questo limite può causare l'eliminazione delle voci di log. |
Configura il tuo logging in modo che rimanga entro i limiti predefiniti o configura un agente Logging a velocità effettiva elevata. Per scoprire di più, consulta Aumento del throughput dell'agente Logging. |
| Limiti di Backup for GKE |
Puoi utilizzare Backup per GKE per eseguire il backup e il ripristino dei carichi di lavoro GKE. Backup per GKE è soggetto a limiti che devi tenere a mente al momento di definire i piani di backup. |
Esamina i limiti di Backup for 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 rispettare 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 maggiori dettagli sui limiti delle risorse, consulta le linee guida sulla scalabilità di Config Controller. Per informazioni sulla gestione di un numero elevato di risorse, consulta le best practice per Config Connector. |