Questa pagina descrive le best practice che puoi seguire durante la pianificazione e la progettazione di cluster di dimensioni molto grandi.
Perché pianificare per cluster GKE di grandi dimensioni
Ogni sistema informatico, incluso Kubernetes, ha dei limiti di architettura. Il superamento dei limiti può influire sulle prestazioni del cluster o, nello stesso caso, causare anche tempi di inattività. Segui le best practice ed esegui le azioni consigliate per assicurarti 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 singolo cluster di grandi dimensioni. Questo approccio è più facile da gestire, più economico e fornisce un migliore utilizzo delle risorse rispetto a più cluster. Tuttavia, in alcuni casi devi considerare la possibilità di suddividere il carico di lavoro in più cluster:
- Esamina i 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à, suddividi il cluster quando potrebbe superare uno dei limiti descritti nella sezione di seguito o una delle quote di GKE. La riduzione di qualsiasi rischio per il raggiungimento dei 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 l'architettura supporti i cluster GKE su larga scala, rivedi i limiti seguenti 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 con definizioni di risorse personalizzate (CRD) è comune, ma può limitare la capacità di scalabilità del cluster.
La tabella seguente estende le quote e i limiti principali di GKE. Dovresti inoltre acquisire familiarità 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 che al piano di controllo.
| Limite GKE | Descrizione | best practice |
|---|---|---|
| Dimensioni del database etcd | La dimensione massima del database etcd è 6 GB. Se stai eseguendo un cluster molto grande con decine di migliaia di risorse, le istanze etcd potrebbero superare questo limite. Puoi controllare il livello di utilizzo per i tuoi cluster nella console Google Cloud. | Se superi questo limite, GKE potrebbe contrassegnare le istanze etcd come non integri. Ciò fa sì che il piano di controllo dei cluster non risponda.
Se superi questo limite, contatta l'assistenza Google Cloud. |
| Dimensioni totali 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 di Kubernetes o dei controller personalizzati potrebbe non andare a buon fine, con conseguenti interruzioni. |
Mantieni le dimensioni totali di tutti gli oggetti di ogni tipo archiviati in etcd al di sotto di 800 MB. Ciò è particolarmente applicabile ai cluster che utilizzano molti secret o ConfigMap di grandi dimensioni oppure un volume elevato di CRD. |
| Numero di servizi per i cluster in cui GKE Dataplane V2 non è abilitato | Le prestazioni di iptables utilizzati da kube-proxy si riducono se si verifica una delle seguenti condizioni:
Questo limite viene eliminato quando è abilitato GKE Dataplane V2. |
Mantieni il numero di servizi nel cluster inferiore a 10.000. Per scoprire di più, vedi Esposizione di applicazioni mediante l'utilizzo dei servizi. |
| Numero di servizi per spazio dei nomi | Il numero di variabili di ambiente generate per i servizi potrebbe superare i limiti di 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 la compilazione di queste variabili di ambiente. Consulta la documentazione per sapere come impostare Per scoprire di più, vedi Esposizione di applicazioni mediante 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 gli watches per il monitoraggio di qualsiasi modifica al servizio. Più un cluster è grande, più dati correlati alle modifiche vengono elaborati dall'agente. Ciò è visibile soprattutto nei cluster con più di 500 nodi. Le informazioni sugli endpoint vengono suddivise tra Gli oggetti endpoint sono ancora disponibili per i componenti, ma qualsiasi endpoint superiore a 1000 pod viene troncato automaticamente. |
Mantieni inferiore a 10.000 il numero di pod dietro un singolo servizio. Per scoprire di più, vedi Esposizione delle applicazioni mediante 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. Ai cluster Autopilot si applica lo stesso limite quando utilizzano GKE Dataplane V2. |
In GKE 1.23 e versioni precedenti, mantieni inferiore a 1000 il numero di pod dietro un singolo servizio. In GKE 1.24 e versioni successive, mantieni inferiore a 10.000 il numero di pod dietro un singolo servizio. Per scoprire di più, vedi Esposizione di applicazioni mediante l'utilizzo dei 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 al di sotto di 1000 per kube-dns e 3500/2000 (IPv4/IPv6) per Cloud DNS. |
| Numero di tutti gli endpoint del servizio | Il numero di endpoint in tutti i servizi può 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 64.000. GKE Dataplane V2, che è il piano dati predefinito per GKE, si basa su mappe eBPF attualmente limitate a 64.000 endpoint tra 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 dell'elaborazione HPA. Ad esempio,in GKE 1.22 con 2000 HPA, un singolo HPA verrà rielaborato ogni 1 minuto e 40 secondi. Per scoprire di più, consulta la pagina sulla scalabilità automatica basata sull'utilizzo delle risorse e sulla scalabilità orizzontale della scalabilità automatica dei pod. |
| Numero di pod per nodo | GKE ha un limite fisso 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 sull'upgrade manuale di un cluster o di un pool di nodi. |
| Percentuale di modifiche dei pod |
Kubernetes ha limiti interni che influiscono sulla frequenza di creazione o eliminazione dei pod (abbandono dei pod) in risposta alle richieste di scalabilità. Anche fattori aggiuntivi 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 aspettarti una frequenza media di 20 pod creati al secondo e 20 pod eliminati al secondo. Per i cluster più grandi di 500 nodi, puoi aspettarti una frequenza media di 100 pod creati al secondo e 100 pod eliminati al secondo. |
Quando pianifichi la scalabilità dei tuoi carichi di lavoro, considera il limite relativo alla percentuale di creazione e eliminazione dei pod. 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 del cluster di rimuovere in modo efficace i pod dai nodi sottoutilizzati, evita PodDisruptionBudgets e periodi di tolleranza per la terminazione troppo restrittivi. Anche le tolleranze con caratteri jolly sono sconsigliate, poiché possono causare la pianificazione dei carichi di lavoro sui nodi in fase di rimozione. |
| 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 potrebbe generare un carico considerevole 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à dei pod (meno nodi di grandi dimensioni) potrebbe ridurre il numero di smartwatch e mitigare la gravità del problema. Per scoprire di più, consulta il confronto delle 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 se è 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. | 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 del log per nodo |
Esiste un limite alla quantità massima di log inviati da ciascun nodo all'API Cloud Logging. Il limite predefinito varia tra 100 Kbps e 500 Kbps in base al carico. Puoi aumentare il limite a 10 Mbps eseguendo il deployment di una configurazione dell'agente Logging ad alta velocità effettiva. Superare questo limite potrebbe causare la perdita di voci di log. |
Configura il logging per rimanere entro i limiti predefiniti o configura un agente Logging a velocità effettiva elevata. Per saperne di più, consulta Aumentare la velocità effettiva dell'agente Logging. |
| Limiti di Backup per 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 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 usare Config Connector per gestire le risorse Google Cloud tramite Kubernetes. Config Connector ha due modalità di funzionamento:
|
Ogni istanza di Config Connector ha una richiesta di CPU di 0,1 e un limite di memoria di 512 MB. Di conseguenza, non consente una buona scalabilità su una grande quantità di risorse gestite. Ti consigliamo di non avere più di 25.000 risorse Google Cloud per singola istanza di Config Connector. Questa limitazione è solo a scopo di riferimento perché la quantità di memoria utilizzata dipende dal tipo di risorsa e da casi d'uso specifici. Quando gestisci un numero maggiore di risorse gestite, ti consigliamo di utilizzare la modalità dello spazio dei nomi per limitare il numero di risorse gestite da ogni istanza di Config Connector. Ti consigliamo di utilizzare fino a 500 spazi dei nomi con Config Connector in modalità dello spazio dei nomi.
Ogni istanza di Config Connector apre molte connessioni watch a kube-apiserver. Un numero elevato di queste istanze potrebbe sovraccaricare il piano di controllo del cluster GKE, soprattutto durante gli upgrade del piano di controllo, quando è necessario reinizializzare le connessioni dello smartwatch. Ti consigliamo di utilizzare più cluster GKE per gestire il numero di risorse che non è stato possibile suddividere per rientrare nei limiti specificati sopra. Per maggiori dettagli, consulta le linee guida sulla scalabilità di Config Controller. |