Perché pianificare cluster GKE di grandi dimensioni
Ogni sistema informatico, incluso Kubernetes, ha alcuni limiti architetturali. Il superamento dei limiti può influire sul rendimento del cluster o, in alcuni casi, persino causare 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 esegue lo scale up di 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 considerare le 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 di nodi previsto.
Considerazioni generali sulla migrazione dei cluster
Indipendentemente dalle dimensioni del cluster di destinazione, tieni presente quanto segue quando esegui la migrazione a limiti di nodi più elevati:
- La migrazione dai cluster Standard di zona a quelli regionali richiede la ricreazione del cluster per accedere a limiti di quota dei nodi più elevati.
- La migrazione ai cluster che utilizzano Private Service Connect richiede la ricreazione del cluster per accedere al limite di quota dei nodi più elevato.
Limiti e requisiti delle dimensioni dei cluster
La tabella seguente riassume i limiti e i requisiti di scalabilità di GKE, in base al numero di nodi di destinazione:
| Limite di nodi | Requisiti dell'infrastruttura | Requisiti di networking | Restrizioni di accesso | Esempi di casi d'uso |
|---|---|---|---|---|
| Fino a 1000 | Disponibile per tutti i cluster. | Nessun altro requisito. | Nessuno. Lo scale up fino a 1000 nodi è automatico. | Workload generali, sviluppo e test. |
| Da 1000 a 5000 | Disponibile per i cluster Standard regionali e i cluster Autopilot. |
|
Nessuno. Lo scale up fino a 5000 nodi è automatico se soddisfi gli altri requisiti. | Job ad alto volume e di breve durata e servizi aziendali. |
| Da 5000 a 15.000 |
|
|
Per aumentare le dimensioni del cluster e il limite di quota, contatta l'assistenza clienti Google Cloud. | Workload di HPC e trattamento dei dati. |
| Da 15.000 a 65.000 |
|
|
Per richiedere un aumento della quota e ricevere assistenza per lo scale up fino ai limiti più elevati, contatta l'assistenza clienti Google Cloud. | Addestramento di modelli di grandi dimensioni. |
Best practice per la suddivisione dei workload tra più cluster
Puoi eseguire i workload 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 prendere in considerazione la suddivisione del workload in più cluster:
- Consulta Casi d'uso multi-cluster per scoprire di più sui requisiti e sugli scenari generali 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 seguente o una delle quote di GKE. La riduzione del rischio di raggiungere i limiti di GKE riduce il rischio di tempi di inattività o altri 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. Il superamento di questi limiti può causare un peggioramento del rendimento 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 tabella seguente estende le principali quote e i limiti di GKE. Dovresti anche familiarizzare con i limiti di Kubernetes open source per i cluster su larga scala.
I requisiti della versione di GKE indicati nella tabella si applicano sia ai nodi sia al piano di controllo.
| Limite di GKE | Descrizione | Best practice |
|---|---|---|
| Dimensioni del database etcd | La dimensione massima del database etcd è di 6 GB. Devi monitorare in modo proattivo le dimensioni del database etcd del cluster e configurare gli avvisi per ricevere una notifica quando l'utilizzo si avvicina a questo limite. Il superamento del limite può causare problemi al piano di controllo. | Puoi utilizzare le seguenti risorse per monitorare l'utilizzo:
Per ulteriori informazioni su come rispondere quando ti avvicini al limite, consulta 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 di pod e 750 MB di secret, ma non puoi creare 850 MB di secret. Se crei più di 800 MB di oggetti, i controller Kubernetes o personalizzati potrebbero non riuscire a inizializzarsi e causare interruzioni. |
Mantieni la dimensione totale di tutti gli oggetti di ogni tipo archiviati in etcd al di sotto 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 GKE Dataplane V2 è abilitato. |
Mantieni il numero di servizi nel cluster al di sotto di 10.000. Per scoprire di più, consulta 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 al di sotto di 5000. Puoi disattivare il popolamento di queste variabili di ambiente. Consulta la documentazione per scoprire come impostare Per scoprire di più, consulta 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 osservazioni per monitorare eventuali modifiche del servizio. Più grande è un cluster, più dati relativi alle modifiche vengono elaborati dall'agente. Questo è particolarmente visibile 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 sopra i 1000 pod viene automaticamente troncato. |
Mantieni il numero di pod dietro un singolo servizio inferiore a 10.000. Per scoprire di più, consulta Esporre le applicazioni utilizzando i servizi. |
| Numero di pod dietro un singolo servizio per i cluster in cui GKE Dataplane V2 è abilitato |
GKE Dataplane V2 contiene limiti al numero di pod esposti da un singolo servizio. Lo stesso limite è applicabile ai cluster Autopilot perché 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 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 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 comportare 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 attualmente limitate a 260.000 endpoint in tutti i servizi. |
| Numero di oggetti HorizontalPodAutoscaler per cluster |
Ogni HorizontalPodAutoscaler (HPA) viene elaborato ogni 15 secondi. Per impostazione predefinita, GKE supporta fino a 300 oggetti HPA. Per limiti più elevati, il profilo HPA Performance aumenta il supporto a 1000 oggetti HPA nella versione 1.31 e successive e fino a 5000 oggetti HPA nella versione 1.33 e successive. Il superamento di questi limiti può causare un peggioramento lineare del rendimento. |
Mantieni il numero di oggetti HPA entro il limite supportato per il profilo del cluster (300, 1000 o 5000 oggetti). In caso contrario, potresti riscontrare un peggioramento lineare della frequenza di elaborazione HPA. Ad esempio, 2000 HPA con impostazioni standard fanno sì che ogni HPA venga rielaborato solo una volta ogni 1 minuto e 40 secondi. Per scoprire di più, consulta Scalabilità automatica basata sull'utilizzo delle risorse, Scalabilità automatica orizzontale dei pod e Configurare il profilo HPA Performance. |
| Numero di pod per nodo | GKE ha un limite rigido di 256 pod per nodo. Questo 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 per ogni 10 pod. Per scoprire di più, consulta Aggiornamento manuale di un cluster o di un pool di nodi. |
| Tasso di modifiche dei 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 su questo tasso di churn 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 velocità di creazione ed eliminazione dei pod quando pianifichi la scalabilità dei workload. 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 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 di terminazione lunghi. Anche le tolleranze con caratteri jolly Tolerations sono sconsigliate, in quanto possono causare la pianificazione dei workload su nodi in fase di rimozione. |
| Numero di osservazioni aperte watches | I nodi creano un'osservazione per ogni secret e ConfigMaps configurato per i pod. La quantità combinata di osservazioni create da tutti i nodi potrebbe generare un carico sostanziale sul piano di controllo 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 piano di controllo. |
Definisci nodi più grandi per ridurre la probabilità e la gravità dei problemi causati da un numero elevato di osservazioni. Una maggiore densità dei pod (meno nodi di grandi dimensioni) potrebbe ridurre il numero di osservazioni e attenuare la gravità del problema. Per scoprire di più, consulta Confronto delle serie di macchine. |
| Numero di secret per cluster se la crittografia dei secret a livello di applicazione è abilitata | Quando la crittografia dei secret a livello di applicazione è abilitata, un cluster deve decriptare tutti i secret durante l'avvio del cluster. Se archivi più di 30.000 secret, il cluster potrebbe diventare instabile durante l'avvio o gli upgrade, causando interruzioni dei workload. | Archivia meno di 30.000 secret quando utilizzi la crittografia dei secret a livello di applicazione. Per scoprire di più, consulta 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 da 100 Kbps a 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 alto throughput. Il superamento di questo limite potrebbe causare l'eliminazione delle voci di log. |
Configura Logging in modo da rimanere entro i limiti predefiniti o configura un agente Logging con throughput elevato. Per scoprire di più, consulta Modificare il throughput dei log. |
| Node pool | 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 ComputeClass personalizzate aumentano il numero di node pool. | Mantieni il numero di node pool al di sotto di 200. |
| Ritardo medio e massimo del webhook di ammissione |
I webhook di ammissione vengono chiamati in parallelo (convalida) o in sequenza (mutazione). In ogni caso, a ogni richiesta configurata che corrisponde ai selettori del webhook viene aggiunto un ritardo. Quando esegui il webhook, ritardi brevi e coerenti, ad esempio 50-100 ms, possono causare un peggioramento significativo del rendimento. |
Configura i webhook in modo che la latenza di esecuzione sia in media inferiore a 10 ms. Specifica l'operazione, i tipi di risorse e gli spazi dei nomi a cui deve fare riferimento il webhook. Evita di acquisire eventi perché ciò può causare problemi di rendimento, ad esempio il precaricamento più lento delle immagini. Esegui più istanze di endpoint webhook su nodi separati dal workload e mantieni una bassa latenza. Valuta la possibilità di eseguire |
| Limiti di Backup per GKE |
Puoi utilizzare Backup per GKE per eseguire il backup e il ripristino dei workload GKE. Backup per GKE è soggetto a limiti che devi tenere presenti quando definisci i piani di backup. |
Esamina i limiti di Backup per GKE. Se è possibile che il workload 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 Google Cloud le risorse tramite Kubernetes. Config Connector ha due modalità di funzionamento:
|
Per i 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 di Config Connector. |