Questa pagina descrive le best practice da seguire per la gestione di carichi di lavoro di grandi dimensioni su più cluster GKE. Queste best practice riguardano considerazioni relative alla distribuzione dei carichi di lavoro su più progetti e alla regolazione delle quote richieste.
Best practice per la distribuzione di carichi di lavoro GKE tra più progetti Google Cloud
Per definire meglio la struttura del progetto Google Cloud e la distribuzione dei carichi di lavoro GKE, in base alle tue esigenze aziendali, ti consigliamo di prendere in considerazione le seguenti azioni di progettazione e pianificazione:
- Segui le best practice per la gestione delle risorse cloud per prendere decisioni iniziali relative alla struttura della tua organizzazione per cartelle e progetti. Google Cloud consiglia di utilizzare gli elementi della gerarchia delle risorse, come cartelle e progetti, per suddividere il carico di lavoro in base ai confini dell'organizzazione o ai criteri di accesso.
- Valuta se devi suddividere i carichi di lavoro a causa delle quote del progetto. Google Cloud utilizza le quote per progetto per limitare l'utilizzo delle risorse condivise. Devi seguire i suggerimenti descritti di seguito e modificare le quote di progetto per carichi di lavoro di grandi dimensioni. Per la maggior parte dei carichi di lavoro, dovresti essere in grado di raggiungere quote più elevate e richieste in un singolo progetto. Ciò significa che le quote non devono essere il motore principale per la suddivisione del carico di lavoro tra più progetti. Mantenere i carichi di lavoro in un numero minore di progetti semplifica l'amministrazione delle quote e dei carichi di lavoro.
- Valuta se prevedi di eseguire carichi di lavoro molto grandi (su una 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à di 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 regolazione delle quote per carichi di lavoro GKE di grandi dimensioni
Questa sezione descrive le linee guida per modificare le 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 informazioni su come gestire la quota utilizzando la console Google Cloud, consulta Utilizzo delle quote.
Quote e best practice di Compute Engine
I cluster GKE, in esecuzione sia in modalità Autopilot che 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 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 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 richiedere un aggiustamento per carichi di lavoro più grandi. Tuttavia, in qualità di amministratore della piattaforma, puoi regolare in modo proattivo le quote di Compute Engine per assicurarti che i cluster GKE dispongano di risorse sufficienti. Quando valuti o modifichi i valori delle quote, dovresti anche tenere conto delle esigenze future delle risorse.
Quote per le risorse Compute Engine utilizzate dai nodi worker GKE
La seguente tabella elenca le quote delle risorse per le risorse 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 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. |
| Standard Persistent Disk (GB) | Dimensione totale dei dischi di avvio permanente standard collegati a tutti i nodi worker. |
| SSD Persistent Disk (GB) | Dimensione totale dei dischi di avvio permanente SSD collegati a tutti i nodi worker. |
| SSD locale (GB) | Dimensione totale dei dischi temporanei SSD locali collegati a tutti i nodi worker. |
Assicurati di regolare anche le quote utilizzate dalle risorse che potrebbero richiedere il carico di lavoro, come GPU, indirizzi IP o risorse preventive.
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 in corso.
- Aggiunta o rimozione di nuovi nodi nel cluster.
- Aggiunta o rimozione di nuovi pool di nodi.
- Etichettatura periodica delle risorse.
Quando pianifichi l'architettura del tuo cluster di grandi dimensioni, ti consigliamo di seguire questi passaggi:
- Osserva il consumo storico delle quote.
- Modifica le quote secondo necessità mantenendo un buffer ragionevole. Puoi fare riferimento ai seguenti suggerimenti di best practice come punto di partenza e regolare le quote in base alle esigenze del tuo carico di lavoro.
- Poiché le quote sono configurate in base alla 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 area geografica. 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 computing. |
Per progetti e regioni con diverse centinaia di nodi dinamici, modifica questo valore su 3500. Per progetti e regioni con diverse migliaia di nodi altamente dinamici, modifica questo valore impostandolo su 6000. |
| Richieste di lettura al minuto per regione dell'utente | Queste chiamate vengono utilizzate da GKE per monitorare lo stato delle istanze VM (nodi). |
Per progetti e regioni con diverse centinaia di nodi, modifica questo valore su 12.000. Per i progetti e le regioni con migliaia di nodi, modifica 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 progetti e 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, modifica questo valore impostandolo su 2500. |
| Richieste referrer elenco istanze al minuto per regione | Queste chiamate vengono utilizzate da GKE per ottenere informazioni sull'esecuzione di istanze VM (nodi). |
Per progetti e regioni con migliaia di nodi altamente dinamici, modifica questo valore impostandolo su 6000. |
| Richieste di lettura delle operazioni al minuto per regione | Queste chiamate vengono utilizzate da GKE per ottenere informazioni sulle operazioni in corso dell'API Compute Engine. |
Per progetti e regioni con migliaia di nodi altamente dinamici, modifica questo valore su 3000. |
Quote e best practice per le API Cloud Logging e Cloud Monitoring
A seconda della configurazione del cluster, carichi di lavoro di grandi dimensioni in esecuzione sui cluster GKE potrebbero generare un volume elevato di informazioni diagnostiche. Al superamento delle quote dell'API Cloud Logging o API Cloud Monitoring, i dati di logging e monitoraggio potrebbero andare persi. Ti consigliamo di configurare le livello di dettaglio dei log e 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, consigliamo di seguire questi passaggi:
- Osserva il consumo storico delle quote.
- Modifica le quote o la configurazione di logging e monitoraggio in base alle esigenze. Mantieni un margine ragionevole in caso di problemi imprevisti.
La tabella seguente elenca le quote per le chiamate alle 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 percentuale di inserimento dei log dipende dalla quantità di log generati dai pod nel cluster. Aumenta la quota in base al numero di pod, alle livello di dettaglio del logging delle applicazioni e alla configurazione del logging. Per saperne di più, consulta Gestire i log di GKE. |
| API Cloud Monitoring | Richieste di importazione di serie temporali al minuto |
GKE utilizza questa quota per l'invio delle metriche Prometheus a Cloud Monitoring:
|
Monitora e modifica questa quota in base alle esigenze. Per saperne di più, consulta Gestire le metriche GKE. |
Quota di nodi e best practice di GKE
GKE supporta fino a 15.000 nodi in un singolo cluster con la quota predefinita impostata su 5000 nodi. Questa quota è impostata separatamente per ogni cluster GKE e non per progetto insieme alle altre quote. Se prevedi di scalare il cluster oltre i 5000 nodi, segui questi passaggi:
- Identifica il cluster che vuoi scalare oltre i 5000 nodi.
- Assicurati che il carico di lavoro rispetti i limiti del cluster e le quote di GKE dopo la scalabilità.
- Assicurati di aumentare le quote di Compute Engine come necessario per il carico di lavoro scalato.
- Assicurati che il tipo di disponibilità del cluster sia a livello di regione e che l'isolamento della rete sia privato.
- Richiedi l'aumento della quota per il numero di nodi per cluster creando un richiesta di assistenza.
Il team di GKE ti contatterà per assicurarti che il tuo carico di lavoro segua le best practice per la scalabilità e sia pronto per la scalabilità 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 privati che utilizzano il peering di rete VPC nella stessa rete VPC per ogni località (le zone e le regioni vengono trattate come località separate). I tentativi di creare cluster aggiuntivi oltre il limite avranno esito negativo con 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 privati GKE 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 cluster che utilizzano la connettività Private Service Connect (PSC). I cluster con connettività PSC forniscono lo stesso isolamento di un cluster privato senza la limitazione di 75 cluster. I cluster basati su 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:
- Crea un cluster PSC utilizzando il parametro
no-enable-private-nodesdurante la creazione del cluster. - Configura l'isolamento per i pool di nodi per renderli privati utilizzando il parametro
enable-private-nodesper ogni pool di nodi. - Facoltativamente, configura l'isolamento per il piano di controllo utilizzando il parametro
enable-private-endpointa livello di cluster. Per saperne di più, consulta Modificare l'isolamento del cluster.
In alternativa, contatta il team di assistenza di Google Cloud per aumentare il limite di 75 cluster privati 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.
Che cosa succede dopo?
- Guarda le nostre puntate sulla creazione di grandi cluster GKE.