Best practice per la distribuzione dei carichi di lavoro GKE su più Google Cloud progetti
Per definire meglio la struttura del progetto 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: Google Cloud
- Segui le indicazioni riportate in Decidere una gerarchia delle risorse per la Google Cloud landing zone per prendere le decisioni iniziali relative alla 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 limiti organizzativi o ai criteri di accesso.
- Valuta se devi dividere i carichi di lavoro a causa delle quote di progetto. Google Cloud utilizza le quote per progetto per limitare l'utilizzo delle risorse condivise. Devi seguire le indicazioni descritte 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 delle quote e dei carichi di lavoro.
- Valuta se prevedi di eseguire carichi di lavoro di dimensioni 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 della zona. In questi casi, contatta il tuo Account Manager per ricevere assistenza e consigli speciali.
Best practice per la modifica delle quote per i carichi di lavoro GKE di grandi dimensioni
Questa sezione descrive le linee guida per la modifica delle quote per Google Cloud le risorse 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 Google Cloud console, consulta Visualizzare e gestire le quote.
Quote e best practice di Compute Engine
I cluster GKE, in esecuzione sia in modalità Autopilot che Standard, utilizzano le risorse di 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 di 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 sono condivise anche con altre risorse di Compute Engine (non correlate a GKE) (come istanze VM autonome o gruppi di istanze).
I valori delle quote predefinite possono supportare diverse centinaia di nodi worker e richiedono una modifica per i 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. Quando valuti o modifichi i valori delle quote, devi anche tenere conto delle esigenze future delle risorse.
Quote per le risorse di Compute Engine utilizzate dai nodi worker GKE
La tabella seguente elenca le quote per le risorse di Compute Engine più comuni utilizzate dai nodi worker GKE. Queste quote sono configurate per progetto e per regione. Le quote devono coprire la dimensione combinata massima dei nodi worker GKE utilizzati dal carico di lavoro e anche altre risorse di 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 utilizzata 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) | Dimensione totale dei dischi di avvio permanenti standard collegati a tutti i nodi worker. |
| SSD Persistent Disk (GB) | Dimensione totale dei dischi di avvio permanenti SSD collegati a tutti i nodi worker. |
| SSD locale (GB) | Dimensione totale dei dischi effimeri SSD locali collegati a tutti i nodi worker. |
Assicurati di modificare anche le quote utilizzate dalle risorse che il carico di lavoro 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à come:
- Controllo dello stato delle risorse di calcolo.
- 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:
- Osserva il consumo storico delle quote.
- Modifica le quote in base alle esigenze, mantenendo un buffer ragionevole. Puoi fare riferimento alle seguenti raccomandazioni sulle best practice come punto di partenza e modificare le quote in base alle esigenze del carico di lavoro.
- 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, indipendentemente 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 i progetti e le 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 dell'API Cloud Logging e dell'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. Se superi 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:
- 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 API Cloud Logging e API 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 frequenza 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 la pagina relativa alla gestione dei log 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 relativa alla gestione delle metriche GKE. |
Limiti e quote di scalabilità dei nodi GKE
I cluster GKE Standard supportano la scalabilità fino a 65.000 nodi. A seconda del numero di nodi di destinazione, esistono requisiti di infrastruttura specifici e potresti dover contattare l'assistenza clienti Google Cloud. Per informazioni dettagliate, consulta Limiti e requisiti delle dimensioni del cluster.
Quando ti prepari per la scalabilità, devi anche completare le seguenti attività:
- Esamina le quote e i limiti di GKE per confermare i livelli di supporto complessivi.
- Aggiorna e aumenta le quote di Compute Engine in base alle esigenze del carico di lavoro scalato.
Best practice per evitare altri limiti per i 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à (le zone e le regioni vengono 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 che hanno solo indirizzi interni.
Per risolvere il problema, puoi utilizzare i 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:
- 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 del piano di controllo utilizzando il parametro
enable-private-endpointa livello di cluster. Per saperne di più, consulta Personalizzare l'isolamento di rete.
In alternativa, contatta il Google Cloud team di assistenza per aumentare il limite di 75 cluster che utilizzano 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.
Ottimizzare 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 singola connessione. In questo modo si 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 richiede una connessione separata. Se una connessione presenta problemi, può ritardare o interrompere la richiesta. Ad esempio, se una connessione TCP elimina pacchetti o riscontra 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 aiuta a evitare la congestione della rete.
Frame ping: i frame ping sono segnali leggeri che verificano se una connessione è ancora attiva. Questi segnali aiutano a mantenere le connessioni permanenti e a evitare le connessioni interrotte causate da sistemi intermedi (come firewall o proxy) che potrebbero chiudere le connessioni inattive.
In HTTP/1.1, le connessioni possono essere interrotte in modo imprevisto se non c'è traffico per un 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 sequenza. Questo problema può causare una race condition. HTTP/2 impedisce questo problema eseguendo il multiplexing di 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ù, consulta Come funzionano le connessioni.
- Monitora il traffico per assicurarti che utilizzi HTTP/2.
Per saperne di più, consulta Supporto di HTTP/2 in Cloud Load Balancing.
Passaggi successivi
- Guarda i nostri episodi sulla creazione di cluster GKE di grandi dimensioni.