Questa pagina descrive le best practice che puoi seguire quando gestisci carichi di lavoro di grandi dimensioni su più cluster GKE. Queste best practice riguardano le considerazioni per la distribuzione dei workload su più progetti e la modifica delle quote richieste.
Best practice per la distribuzione dei carichi di lavoro GKE su più progetti Google Cloud
Per definire meglio la struttura del tuo progetto Google Cloud e la distribuzione dei carichi di lavoro GKE in base ai requisiti aziendali, ti consigliamo di prendere in considerazione le seguenti azioni di progettazione e pianificazione:
- Segui le indicazioni riportate in Decidere una gerarchia delle risorse per la tua Google Cloud landing zone per prendere le decisioni iniziali per la struttura della tua organizzazione per cartelle e progetti. Google Cloud Consiglia di utilizzare elementi della gerarchia delle risorse come cartelle e progetti per dividere il carico di lavoro in base ai tuoi confini organizzativi o criteri di accesso.
- Valuta se devi dividere i tuoi workload a causa delle quote di progetto. Google Cloud utilizza le quote per progetto per limitare l'utilizzo delle risorse condivise. Devi seguire i consigli descritti di seguito e modificare le quote di progetto per i carichi di lavoro di grandi dimensioni. Per la maggior parte dei carichi di lavoro dovresti essere in grado di raggiungere le quote richieste e più elevate in un solo progetto. Ciò significa che le quote non devono essere il fattore principale per la suddivisione del carico di lavoro tra più progetti. Mantenere i carichi di lavoro in un numero inferiore di progetti semplifica l'amministrazione di quote e carichi di lavoro.
- Valuta se prevedi di eseguire workload molto grandi (scala di centinaia di migliaia di CPU o più). In questo caso, la suddivisione del carico di lavoro in più progetti può aumentare la disponibilità delle risorse cloud (come CPU o GPU). Ciò è possibile grazie all'utilizzo della configurazione ottimizzata della virtualizzazione delle zone. In questi casi, contatta il tuo account manager per ricevere assistenza e consigli speciali.
Best practice per la modifica delle quote per i workload GKE di grandi dimensioni
Questa sezione descrive le linee guida per la modifica delle quote per le risorse Google Cloud utilizzate dai carichi di lavoro GKE. Modifica le quote per i tuoi progetti in base alle seguenti linee guida. Per scoprire come gestire la quota utilizzando la console Google Cloud , consulta Visualizza e gestisci le quote.
Quote e best practice di Compute Engine
I cluster GKE, eseguiti in modalità Autopilot e Standard, utilizzano le risorse Compute Engine per eseguire i carichi di lavoro. A differenza delle risorse del piano di controllo Kubernetes gestite internamente da Google Cloud, puoi gestire e valutare le quote Compute Engine utilizzate dai tuoi flussi di lavoro.
Le quote di Compute Engine, sia per le risorse che per le API, sono condivise da tutti i cluster GKE ospitati nello stesso progetto e nella stessa regione. Le stesse quote vengono condivise anche con altre risorse Compute Engine (non correlate a GKE), come istanze VM autonome o gruppi di istanze.
I valori di quota predefiniti possono supportare diverse centinaia di nodi worker e richiedono l'aggiustamento per carichi di lavoro più grandi. Tuttavia, in qualità di amministratore della piattaforma, puoi modificare in modo proattivo le quote di Compute Engine per assicurarti che i tuoi cluster GKE abbiano risorse sufficienti. Devi anche considerare le esigenze future di risorse quando valuti o modifichi i valori delle quote.
Quote per le risorse Compute Engine utilizzate dai nodi worker GKE
La tabella seguente elenca le quote di risorse per le risorse Compute Engine più comuni utilizzate dai nodi worker GKE. Queste quote vengono configurate per progetto e per regione. Le quote devono coprire le dimensioni combinate massime dei nodi worker GKE utilizzati dal tuo carico di lavoro e anche altre risorse Compute Engine non correlate a GKE.
| Quota per le risorse | Descrizione |
|---|---|
| CPU | Numero di CPU utilizzate da tutti i nodi worker di tutti i cluster. |
| Tipo di CPU | Numero di ogni tipo specifico di CPU utilizzato da tutti i nodi worker di tutti i cluster. |
| Istanze VM | Numero di tutti i nodi worker. Questa quota viene calcolata automaticamente come 10 volte il numero di CPU. |
| Istanze per rete VPC | Numero di tutti i nodi worker connessi alla rete VPC. |
| Persistent Disk standard (GB) | La dimensione totale dei dischi di avvio permanenti standard collegati a tutti i nodi worker. |
| SSD Persistent Disk (GB) | La dimensione totale dei dischi di avvio permanenti SSD collegati a tutti i nodi worker. |
| SSD locale (GB) | La dimensione totale dei dischi temporanei SSD locali collegati a tutti i nodi worker. |
Assicurati di modificare anche le quote utilizzate dalle risorse che il tuo workload potrebbe richiedere, come GPU, indirizzi IP o risorse preemptive.
Quote per le chiamate API Compute Engine
I cluster di grandi dimensioni o scalabili richiedono un numero maggiore di chiamate API Compute Engine. GKE effettua queste chiamate API Compute Engine durante attività quali:
- Controllo dello stato delle risorse di computing.
- Aggiunta o rimozione di nuovi nodi al cluster.
- Aggiunta o rimozione di nuovi pool di nodi.
- Etichettatura periodica delle risorse.
Quando pianifichi l'architettura del cluster di grandi dimensioni, ti consigliamo di procedere come segue:
- Osserva il consumo storico delle quote.
- Modifica le quote in base alle esigenze mantenendo un buffer ragionevole. Puoi fare riferimento ai seguenti consigli sulle best practice come punto di partenza e modificare le quote in base alle esigenze del tuo workload.
- Poiché le quote sono configurate per regione, modificale solo nelle regioni in cui prevedi di eseguire carichi di lavoro di grandi dimensioni.
La tabella seguente elenca le quote per le chiamate API Compute Engine. Queste quote sono configurate per progetto, in modo indipendente per ogni regione. Le quote sono condivise da tutti i cluster GKE ospitati nello stesso progetto e nella stessa regione.
| Quota API | Descrizione | Best practice |
|---|---|---|
| Query al minuto per regione | Queste chiamate vengono utilizzate da GKE per eseguire vari controlli sullo stato delle varie risorse di calcolo. |
Per i progetti e le regioni con diverse centinaia di nodi dinamici, imposta questo valore su 3500. Per i progetti e le regioni con diverse migliaia di nodi altamente dinamici, imposta questo valore su 6000. |
| Richieste di lettura al minuto per regione | Queste chiamate vengono utilizzate da GKE per monitorare lo stato delle istanze VM (nodi). |
Per i progetti e le regioni con diverse centinaia di nodi, imposta questo valore su 12.000. Per i progetti e le regioni con migliaia di nodi, imposta questo valore su 20.000. |
| Richieste di elenco al minuto per regione | Queste chiamate vengono utilizzate da GKE per monitorare lo stato dei gruppi di istanze (pool di nodi). |
Per i progetti e le regioni con diverse centinaia di nodi dinamici, non modificare il valore predefinito perché è sufficiente. Per progetti e regioni con migliaia di nodi altamente dinamici, in più pool di nodi, imposta questo valore su 2500. |
| Richieste di referrer dell'elenco di istanze al minuto per regione | Queste chiamate vengono utilizzate da GKE per ottenere informazioni sulle istanze VM (nodi) in esecuzione. |
Per i progetti e le regioni con migliaia di nodi altamente dinamici, imposta questo valore su 6000. |
| Richieste di lettura delle operazioni al minuto per regione | Queste chiamate vengono utilizzate da GKE per ottenere informazioni sulle operazioni API Compute Engine in corso. |
Per i progetti e le regioni con migliaia di nodi altamente dinamici, imposta questo valore su 3000. |
Quote e best practice per l'API Cloud Logging e l'API Cloud Monitoring
A seconda della configurazione del cluster, i carichi di lavoro di grandi dimensioni in esecuzione sui cluster GKE potrebbero generare un volume elevato di informazioni diagnostiche. Quando si superano le quote dell'API Cloud Logging o dell'API Cloud Monitoring, i dati di logging e monitoraggio potrebbero andare persi. Ti consigliamo di configurare la verbosità dei log e di modificare le quote dell'API Cloud Logging e dell'API Cloud Monitoring per acquisire le informazioni diagnostiche generate. Managed Service per Prometheus utilizza le quote di Cloud Monitoring.
Poiché ogni carico di lavoro è diverso, ti consigliamo di procedere come segue:
- Osserva il consumo storico delle quote.
- Modifica le quote o la configurazione di logging e monitoraggio in base alle esigenze. Mantieni un buffer ragionevole per problemi imprevisti.
La tabella seguente elenca le quote per le chiamate alle API Cloud Logging e Cloud Monitoring. Queste quote sono configurate per progetto e sono condivise da tutti i cluster GKE ospitati nello stesso progetto.
| Servizio | Quota | Descrizione | Best practice |
|---|---|---|---|
| API Cloud Logging | Richieste di scrittura al minuto | GKE utilizza questa quota quando aggiunge voci ai file di log archiviati in Cloud Logging. |
La velocità di inserimento dei log dipende dalla quantità di log generati dai pod nel cluster. Aumenta la quota in base al numero di pod, alla verbosità del logging delle applicazioni e alla configurazione del logging. Per saperne di più, consulta Gestione dei log di GKE. |
| API Cloud Monitoring | Richieste di importazione di serie temporali al minuto |
GKE utilizza questa quota quando invia le metriche di Prometheus a Cloud Monitoring:
|
Monitora e modifica questa quota in base alle esigenze. Per saperne di più, consulta la pagina Gestione delle metriche GKE. |
Quota e best practice per i nodi GKE
GKE supporta i seguenti limiti:
- Fino a 15.000 nodi in un singolo cluster con la quota predefinita impostata su 5000 nodi. Questa quota viene impostata separatamente per ciascun cluster GKE e non per progetto come le altre quote.
- Nella versione 1.31 e successive, GKE supporta cluster di grandi dimensioni fino a 65.000 nodi.
Se prevedi di scalare il cluster oltre i 5000 nodi, segui questi passaggi:
- Identifica il cluster di cui vuoi eseguire lo scale out oltre 5000 nodi.
- Assicurati che il carico di lavoro rientri nei limiti del cluster e nelle quote GKE dopo lo scaling.
- Assicurati di aumentare le quote di Compute Engine in base ai requisiti del tuo workload scalato.
- Assicurati che il tipo di disponibilità del cluster sia regionale e che il cluster utilizzi Private Service Connect.
- Per richiedere un aumento della quota per il numero di nodi per cluster, contatta l'assistenza clienti Google Cloud. Il team GKE ti contatterà per assicurarsi che il tuo workload segua le best practice di scalabilità e sia pronto per scalare oltre 5000 nodi su un singolo cluster.
Best practice per evitare altri limiti per carichi di lavoro di grandi dimensioni
Limite per il numero di cluster che utilizzano il peering di rete VPC per rete per località
Puoi creare un massimo di 75 cluster che utilizzano il peering di rete VPC nella stessa rete VPC per località (zone e regioni sono trattate come località separate). I tentativi di creare cluster aggiuntivi oltre il limite non andranno a buon fine e verrà visualizzato un errore simile al seguente:
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
I cluster GKE con nodi privati creati prima della versione 1.29 utilizzano il peering di rete VPC per fornire la comunicazione interna tra il server API Kubernetes (gestito da Google) e i nodi privati con solo indirizzi interni.
Per risolvere questo problema, puoi utilizzare cluster che utilizzano la connettività Private Service Connect (PSC). I cluster con connettività PSC forniscono lo stesso isolamento di un cluster che utilizza il peering di rete VPC, senza il limite di 75 cluster. I cluster con connettività PSC non utilizzano il peering di rete VPC e non sono interessati dal limite del numero di peering VPC.
Puoi utilizzare le istruzioni fornite in Riutilizzo del peering di rete VPC per identificare se i tuoi cluster utilizzano il peering di rete VPC.
Per evitare di raggiungere il limite durante la creazione di nuovi cluster, segui questi passaggi:
- Assicurati che il tuo cluster utilizzi PSC.
- Configura l'isolamento dei pool di nodi in modo che diventino privati utilizzando il parametro
enable-private-nodesper ogni pool di nodi. - (Facoltativo) Configura l'isolamento per il control plane utilizzando il parametro
enable-private-endpointa livello di cluster. Per saperne di più, vedi Personalizzare l'isolamento di rete.
In alternativa, contatta il team di assistenza di Google Cloud per aumentare il limite di 75 cluster utilizzando il peering di rete VPC. Queste richieste vengono valutate caso per caso e, quando è possibile aumentare il limite, viene applicato un aumento di una sola cifra.
Ottimizza per scalabilità e affidabilità con HTTP/2
Per eseguire carichi di lavoro su larga scala su GKE, utilizza HTTP/2 anziché HTTP/1.1. HTTP/2 migliora le prestazioni e l'affidabilità della connessione in ambienti con traffico elevato o latenza elevata.
Vantaggi di HTTP/2
Riduce il numero di connessioni: HTTP/2 consente di inviare molte richieste e ricevere molte risposte su una sola connessione. Ciò riduce il carico sui componenti di sistema come bilanciatori del carico, proxy e gateway NAT.
Migliora la coerenza delle prestazioni: con HTTP/1.1, ogni richiesta di solito necessita di una propria connessione. Se una connessione presenta problemi, la richiesta può essere ritardata o interrotta. Ad esempio, se una connessione TCP perde pacchetti o presenta una latenza elevata, potrebbe influire su tutte le richieste effettuate su quella connessione, causando ritardi o errori nell'applicazione. Con HTTP/2, più richieste condividono la stessa connessione, quindi i problemi di rete influiscono su tutte le richieste allo stesso modo, rendendo le prestazioni più prevedibili.
Include funzionalità integrate per mantenere affidabili le connessioni:
Controllo del flusso: il controllo del flusso consente di gestire la quantità di dati inviati contemporaneamente. Impedisce ai mittenti di sovraccaricare i destinatari e contribuisce a evitare la congestione della rete.
Ping frame: i ping frame sono segnali leggeri che verificano se una connessione è ancora attiva. Questi segnali aiutano a mantenere connessioni persistenti e a evitare interruzioni causate da sistemi intermedi (come firewall o proxy) che potrebbero chiudere le connessioni inattive.
In HTTP/1.1, le connessioni possono interrompersi inaspettatamente se non c'è traffico per un determinato periodo di tempo. Questa situazione è particolarmente comune quando i firewall o i proxy chiudono le connessioni inattive per liberare risorse. In HTTP/2, i frame ping mantengono attive le connessioni controllando regolarmente lo stato della connessione.
Multiplexing: in HTTP/1.1, quando vengono inviate più richieste contemporaneamente utilizzando connessioni separate, l'ordine in cui vengono ricevute le risposte può causare problemi se una richiesta dipende da un'altra. Ad esempio, se una richiesta viene completata per prima, ma un'altra ha un ritardo di rete, il risultato potrebbe essere una risposta errata o fuori ordine. Questo problema può causare una race condition. HTTP/2 impedisce questo problema multiplexando tutte le richieste su una singola connessione, il che contribuisce a garantire che le risposte siano allineate correttamente.
Best practice per l'utilizzo di HTTP/2
- Utilizza HTTP/2 per le applicazioni che gestiscono un volume elevato di traffico o che richiedono comunicazioni a bassa latenza.
- Configura i keepalive a livello di applicazione per mantenere aperte le connessioni. Per saperne di più, vedi Come funzionano le connessioni.
- Monitora il traffico per assicurarti che utilizzi HTTP/2.
Per ulteriori informazioni, consulta Supporto di HTTP/2 in Cloud Load Balancing.
Passaggi successivi
- Guarda i nostri episodi sulla creazione di cluster GKE di grandi dimensioni.