Best practice per la pianificazione di cluster GKE di grandi dimensioni

Puoi utilizzare le seguenti risorse per monitorare l'utilizzo:

• Per visualizzare l'utilizzo attuale, vai alla pagina Quote per visualizzare un elenco prefiltrato di quote di GKE.
• Utilizza approfondimenti e consigli per ricevere avvisi per i cluster con un livello di consumo dell'80%, 90% e 95%.

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.

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.

• Ci sono troppi servizi.
• Il numero di backend dietro un servizio è elevato.

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.

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

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

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 EndpointSlices separate. Questa suddivisione riduce la quantità di dati trasferiti a ogni modifica.

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.

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 scoprire di più, consulta Esporre le applicazioni utilizzando i servizi.

Il numero di record DNS per servizio senza interfaccia è limitato sia per kube-dns sia per Cloud DNS.

Mantieni il numero di record DNS per servizio senza interfaccia inferiore a 1000 per kube-dns e 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 piano dati predefinito per GKE Autopilot, si basa su mappe eBPF attualmente limitate a 260.000 endpoint in tutti i servizi.

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 peggioramento lineare della frequenza di 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 Scalabilità automatica basata sull'utilizzo delle risorse e Scalabilità automatica pod orizzontale.

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.

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 la stessa velocità effettiva di eliminazione con altri tipi di risorse (ad esempio, EndpointSlices). 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 di terminazione lunghi.

Anche le tolleranze con caratteri jolly non sono consigliate, in quanto possono causare la pianificazione dei workload su nodi in fase di rimozione.

I nodi creano un'osservazione per ogni secret e ConfigMaps configurati 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 mitigare la gravità del problema.

Per scoprire 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 scoprire 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 alta velocità effettiva. 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 la velocità effettiva dei log.

Puoi utilizzare Backup per GKE per eseguire il backup e il ripristino dei workload GKE.

Backup per GKE è soggetto a limiti di cui devi tenere conto 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.

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

• Modalità cluster, in cui è presente 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 di Config Connector separata.

  In questa modalità, puoi partizionare le risorse gestite tramite gli 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 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.