Best practice per la pianificazione di cluster GKE di grandi dimensioni

• È richiesto GKE Dataplane V2. Per saperne di più, consulta Limiti dei nodi di GKE Dataplane V2.
• È richiesto Private Service Connect.

• Disponibile solo per i cluster standard regionali.
• Ti consigliamo di utilizzare GKE versione 1.36 o successive per sfruttare i miglioramenti delle prestazioni per lo scaling di cluster di grandi dimensioni.

• È richiesto GKE Dataplane V2. Per maggiori informazioni, consulta Limiti dei nodi GKE Dataplane V2.
• Private Service Connect richiesto.

• Richiede GKE 1.31 o versioni successive.
• Ti consigliamo di utilizzare GKE versione 1.36 o successive per sfruttare i miglioramenti delle prestazioni per lo scaling di cluster di grandi dimensioni.
• Disponibile solo per i cluster standard regionali.
• Il gestore della scalabilità automatica dei cluster non è supportato. In alternativa, aumenta o riduci le dimensioni dei pool di nodi utilizzando l'API GKE.
• 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 pianificare i pod su nodi specifici, utilizza l'affinità o l'anti-affinità dei pod di Kubernetes.

• È richiesto GKE Dataplane V2. Per maggiori informazioni, consulta Limiti dei nodi GKE Dataplane V2.
• Private Service Connect richiesto.
• Il supporto di più reti per i pod non è disponibile.

Puoi utilizzare le seguenti risorse per monitorare l'utilizzo:

• Per visualizzare l'utilizzo attuale, vai alla pagina Quote per visualizzare un elenco pre-filtrato delle quote di GKE.
• Utilizza approfondimenti e consigli per ricevere avvisi per i cluster ai livelli di consumo dell'80%, 90% e 95%.

Per saperne di più su come rispondere quando ti avvicini al limite, consulta Identificare i cluster in cui l'utilizzo di etcd si sta avvicinando al limite.

Mantieni le dimensioni totali di tutti gli oggetti di ogni tipo archiviati in etcd al di sotto di 800 MB. Questo vale in particolare per i cluster che utilizzano molti secret o ConfigMap di grandi dimensioni o un volume elevato di CRD.

• Sono presenti troppi servizi.
• Il numero di backend dietro un servizio è elevato.

Questo limite viene eliminato quando è abilitato GKE Dataplane V2.

Mantieni il numero di servizi nel cluster inferiore a 10.000.

Per saperne di più, consulta Esposizione di applicazioni utilizzando i servizi.

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 scoprire come impostare enableServiceLinks su false in PodSpec.

Per saperne di più, consulta Esporre le applicazioni utilizzando i servizi.

Ogni nodo esegue un kube-proxy che utilizza i 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 tra EndpointSlices separati. Questa suddivisione riduce la quantità di dati trasferiti a ogni modifica.

Gli oggetti endpoint sono ancora disponibili per i componenti, ma qualsiasi endpoint con più di 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.

GKE Dataplane V2 contiene limiti al numero di pod esposti da un singolo servizio.

Lo stesso limite è applicabile ai cluster Autopilot, poiché 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 Esposizione di applicazioni utilizzando i servizi.

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 a 3500/2000 (IPv4/IPv6) per Cloud DNS.

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.

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 fino 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 delle prestazioni.

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 degrado lineare della frequenza di elaborazione delle 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 saperne di più, consulta Scalabilità automatica basata sull'utilizzo delle risorse, Scalabilità automatica orizzontale dei pod e Configurare il profilo HPA per il rendimento.

Ti consigliamo di utilizzare nodi worker con almeno una vCPU ogni 10 pod.

Per saperne di più, consulta la sezione Eseguire l'upgrade manuale di un cluster o di un node pool.

Kubernetes ha limiti interni che influiscono sulla frequenza 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 questa frequenza 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 aspettarti 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 per la terminazione lunghi.

Sono sconsigliate anche le tolleranze con caratteri jolly, in quanto possono causare la pianificazione dei carichi di lavoro su nodi in fase di rimozione.

I nodi creano un'osservazione per ogni Secret e ConfigMaps che configuri per i pod. La quantità combinata di osservazioni create da tutti i nodi potrebbe generare un carico notevole sul control plane del cluster.

Avere più di 200.000 orologi 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.

Archivia meno di 30.000 secret quando utilizzi la crittografia dei secret a livello di applicazione.

Per saperne di più, consulta Crittografia dei secret a livello di applicazione.

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 alto throughput. 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 con throughput elevato.

Per saperne di più, vedi Regolazione della velocità effettiva dei log.

I webhook di ammissione vengono chiamati in parallelo (convalida) o in sequenza (mutazione). In ogni caso, viene aggiunto un ritardo a ogni richiesta configurata che corrisponde ai selettori webhook. Durante l'esecuzione del webhook, brevi ritardi costanti, ad esempio di 50-100 ms, possono causare un significativo calo delle prestazioni.

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 prestazioni, ad esempio un precaricamento più lento delle immagini. Esegui più istanze di endpoint webhook su nodi separati dal workload e mantieni una latenza bassa. Valuta la possibilità di eseguire failurePolicy: Ignore e un timeout basso (configurato con timeoutSeconds).

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 B per partizionare il backup e rimanere entro i limiti.

Puoi utilizzare Config Connector per gestire le risorse Cloud de Confiance tramite Kubernetes. Config Connector ha due modalità di funzionamento:

• Modalità Cluster, in cui esiste una singola istanza di Config Connector per cluster GKE.

  In questa modalità, una singola istanza di Config Connector carica tutte le risorse.

• Modalità Spazio dei nomi, in cui ogni spazio dei nomi all'interno di un cluster ha un'istanza Config Connector separata.

  In questa modalità, puoi partizionare le risorse gestite tramite spazi dei nomi. Questa configurazione riduce la quantità di risorse che una singola istanza di Config Connector deve gestire, riducendo l'utilizzo di CPU e memoria utilizzata.

Per informazioni dettagliate sui limiti delle risorse, consulta le 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.