Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE

Questo documento illustra le funzionalità e le opzioni di Google Kubernetes Engine (GKE), nonché le best practice per eseguire le applicazioni con ottimizzazione dei costi su GKE al fine di sfruttare la flessibilità offerta da Google Cloud. Questo documento presuppone che tu conosca Kubernetes, Google Cloud, GKE e la scalabilità automatica.

Introduzione

Man mano che Kubernetes viene adottato su larga scala, un numero crescente di aziende e provider di Platform as a Service (PaaS) e Software as a Service (SaaS) utilizza cluster Kubernetes multi-tenant per i propri carichi di lavoro. Ciò significa che un singolo cluster potrebbe eseguire applicazioni appartenenti a team, reparti, clienti o ambienti diversi. Il multi-tenancy fornito da Kubernetes consente alle aziende di gestire pochi cluster di grandi dimensioni, anziché più cluster più piccoli, con vantaggi quali l'utilizzo appropriato delle risorse, il controllo di gestione semplificato e la riduzione della frammentazione.

Nel tempo, alcune di queste aziende con cluster Kubernetes in rapida crescita iniziano a riscontrare un aumento sproporzionato dei costi. Ciò accade perché le aziende tradizionali che adottano soluzioni basate su cloud come Kubernetes non dispongono di sviluppatori e operatori con competenze nel cloud. Questa mancanza di preparazione al cloud porta le applicazioni a diventare instabili durante la scalabilità automatica (ad esempio, volatilità del traffico durante un normale periodo della giornata), picchi improvvisi o aumenti (come spot pubblicitari televisivi o eventi di scalabilità di picco come il Black Friday e il Cyber Monday). Nel tentativo di "risolvere" il problema, queste aziende tendono a eseguire il provisioning eccessivo dei cluster come facevano in un ambiente non elastico. Il provisioning eccessivo comporta un'allocazione di CPU e memoria notevolmente superiore a quella utilizzata dalle applicazioni per la maggior parte della giornata.

Questo documento fornisce le best practice per l'esecuzione di carichi di lavoro Kubernetes con ottimizzazione dei costi su GKE. Il seguente diagramma illustra questo approccio.

La base per la creazione di applicazioni ottimizzate per i costi è la diffusione della cultura del risparmio tra i team. Oltre a spostare le discussioni sui costi all'inizio del processo di sviluppo, questo approccio ti costringe a comprendere meglio l'ambiente in cui vengono eseguite le tue applicazioni, in questo contesto l'ambiente GKE.

Per ottenere costi contenuti e stabilità dell'applicazione, devi impostare o ottimizzare correttamente alcune funzionalità e configurazioni (come scalabilità automatica, tipi di macchina e selezione della regione). Un altro aspetto importante da considerare è il tipo di carico di lavoro perché, a seconda del tipo di carico di lavoro e dei requisiti dell'applicazione, devi applicare configurazioni diverse per ridurre ulteriormente i costi. Infine, devi monitorare la spesa e creare misure di salvaguardia per poter applicare le best practice nelle prime fasi del ciclo di sviluppo.

La seguente tabella riassume le sfide che GKE ti aiuta a risolvere. Ti consigliamo di leggere l'intero documento, ma questa tabella presenta una mappa degli argomenti trattati.

Funzionalità e opzioni di ottimizzazione dei costi di GKE

Le applicazioni Kubernetes con ottimizzazione dei costi si basano in gran parte sullo scaling automatico di GKE. Per bilanciare costi, affidabilità e prestazioni di scalabilità su GKE, devi capire come funziona la scalabilità automatica e quali opzioni hai a disposizione. Questa sezione descrive lo scaling automatico di GKE e altre configurazioni utili con ottimizzazione dei costi per i carichi di lavoro di serving e batch.

Ottimizzare la scalabilità automatica di GKE

La scalabilità automatica è la strategia utilizzata da GKE per consentire ai clienti di pagare solo ciò di cui hanno bisogno riducendo al minimo il tempo di attività dell'infrastruttura.Google Cloud In altre parole, la scalabilità automatica consente di risparmiare sui costi 1) avviando i workload e la relativa infrastruttura prima che la domanda aumenti e 2) arrestandoli quando la domanda diminuisce.

Il seguente diagramma illustra questo concetto. In Kubernetes, i tuoi carichi di lavoro sono applicazioni containerizzate in esecuzione all'interno di pod e l'infrastruttura sottostante, composta da un insieme di nodi, deve fornire una capacità di calcolo sufficiente per eseguire i carichi di lavoro.

Come mostra il seguente diagramma, questo ambiente ha quattro dimensioni di scalabilità. Il carico di lavoro e l'infrastruttura possono essere scalati orizzontalmente aggiungendo e rimuovendo pod o nodi e verticalmente aumentando e diminuendo le dimensioni di pod o nodi.

GKE gestisce questi scenari di scalabilità automatica utilizzando funzionalità come le seguenti:

• Horizontal Pod Autoscaler (HPA), per aggiungere e rimuovere pod in base alle metriche di utilizzo.
• Scalabilità automatica pod verticale (VPA), per dimensionare i pod.
• Cluster Autoscaler, per aggiungere e rimuovere nodi in base al workload pianificato.
• Provisioning automatico dei nodi, per creare dinamicamente nuovi pool di nodi con nodi che corrispondono alle esigenze dei pod degli utenti.

Il seguente diagramma illustra questi scenari.

Il resto di questa sezione descrive in modo più dettagliato queste funzionalità di scalabilità automatica di GKE e copre altre configurazioni utili con ottimizzazione dei costi per i carichi di lavoro di serving e batch.

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) è progettato per scalare le applicazioni in esecuzione nei pod in base a metriche che esprimono il carico. Puoi configurare l'utilizzo della CPU o altre metriche personalizzate (ad esempio, richieste al secondo). In breve, HPA aggiunge ed elimina repliche di pod ed è più adatto a worker stateless che possono avviarsi rapidamente per reagire ai picchi di utilizzo e arrestarsi in modo controllato per evitare l'instabilità del carico di lavoro.

Come mostra l'immagine precedente, HPA richiede una soglia di utilizzo target, espressa in percentuale, che ti consente di personalizzare quando attivare automaticamente lo scaling. In questo esempio, l'utilizzo della CPU target è del 70%. Ciò significa che il tuo workload ha un buffer della CPU del 30% per la gestione delle richieste mentre vengono avviate nuove repliche. Un piccolo buffer impedisce gli aumenti di scala anticipati, ma può sovraccaricare l'applicazione durante i picchi. Tuttavia, un buffer di grandi dimensioni causa uno spreco di risorse, aumentando i costi. Il target esatto è specifico dell'applicazione e devi considerare che la dimensione del buffer sia sufficiente per gestire le richieste per due o tre minuti durante un picco. Anche se garantisci che la tua applicazione possa avviarsi in pochi secondi, questo tempo aggiuntivo è necessario quando Cluster Autoscaler aggiunge nuovi nodi al cluster o quando i pod vengono limitati a causa della mancanza di risorse.

Di seguito sono riportate le best practice per l'attivazione di HPA nella tua applicazione:

• Dimensiona correttamente l'applicazione impostando limiti e richieste appropriati per la risorsa.
• Imposta l'utilizzo target per riservare un buffer in grado di gestire le richieste durante un picco.
• Assicurati che la tua applicazione si avvii il più rapidamente possibile e si arresti in base alle aspettative di Kubernetes.
• Imposta probe di idoneità e di attività significativi.
• Assicurati che il server delle metriche sia sempre attivo e funzionante.
• Informa i client della tua applicazione che devono prendere in considerazione l'implementazione di tentativi esponenziali per la gestione dei problemi temporanei.

Per maggiori informazioni, consulta Configurazione di un gestore della scalabilità automatica del pod orizzontale.

Gestore di scalabilità automatica pod verticale

A differenza di HPA, che aggiunge ed elimina repliche di pod per reagire rapidamente ai picchi di utilizzo, la scalabilità automatica pod verticale (VPA) osserva i pod nel tempo e trova gradualmente le risorse di CPU e memoria ottimali richieste dai pod. L'impostazione delle risorse giuste è importante per la stabilità e l'efficienza in termini di costi. Se le risorse del pod sono troppo piccole, l'applicazione può essere limitata o non funzionare a causa di errori di memoria insufficiente. Se le risorse sono troppo grandi, si verificano sprechi e, di conseguenza, le fatture sono più alte. VPA è pensato per i workload stateless e stateful non gestiti da HPA o quando non conosci le richieste di risorse Pod corrette.

Come mostra l'immagine precedente, VPA rileva che il pod viene eseguito costantemente ai suoi limiti e lo ricrea con risorse più grandi. Si verifica anche il contrario quando il pod è costantemente sottoutilizzato: viene attivato uno scale down.

L'assistente vocale può funzionare in tre modalità diverse:

• Off. In questa modalità, nota anche come modalità di raccomandazione, VPA non applica alcuna modifica al tuo Pod. I consigli vengono calcolati e possono essere esaminati nell'oggetto VPA.
• Iniziale: VPA assegna le richieste di risorse solo al momento della creazione del pod e non le modifica in un secondo momento.
• Auto: VPA aggiorna le richieste di CPU e memoria durante il ciclo di vita di un pod. Ciò significa che il pod viene eliminato, la CPU e la memoria vengono regolate e quindi viene avviato un nuovo pod.

Se prevedi di utilizzare l'aggiustamento della posizione, la best practice è iniziare con la modalità Off per recuperare i consigli sull'aggiustamento della posizione. Assicurati che sia in esecuzione per 24 ore, idealmente una settimana o più, prima di estrarre i consigli. Poi, solo quando ti senti sicuro, valuta di passare alla modalità Iniziale o Automatica.

Segui queste best practice per attivare l'assistente virtuale integrato, in modalità Iniziale o Automatica, nella tua applicazione:

• Non utilizzare la modalità Iniziale o Automatica di VPA se devi gestire picchi improvvisi di traffico. Utilizza HPA invece.
• Assicurati che la tua applicazione possa crescere verticalmente.
• Imposta le dimensioni minime e massime dei container negli oggetti VPA per evitare che il gestore della scalabilità automatica apporti modifiche significative quando l'applicazione non riceve traffico.
• Non apportare modifiche brusche, ad esempio riducendo le repliche del pod da 30 a 5 contemporaneamente. Questo tipo di modifica richiede un nuovo deployment, un nuovo set di etichette e un nuovo oggetto VPA.
• Assicurati che la tua applicazione si avvii il più rapidamente possibile e si arresti in base alle aspettative di Kubernetes.
• Imposta probe di idoneità e di attività significativi.
• Assicurati che il server delle metriche sia sempre attivo e funzionante.
• Informa i client della tua applicazione che devono prendere in considerazione l'implementazione di tentativi esponenziali per la gestione dei problemi temporanei.
• Valuta la possibilità di utilizzare il provisioning automatico dei nodi insieme a VPA in modo che, se un pod diventa abbastanza grande da adattarsi ai tipi di macchina esistenti, il gestore della scalabilità automatica dei cluster esegua il provisioning di macchine più grandi per adattarsi al nuovo pod.

Se stai valutando di utilizzare la modalità Auto, assicurati di seguire anche queste pratiche:

• Assicurati che l'applicazione possa essere riavviata durante la ricezione del traffico.
• Aggiungi un budget di interruzione dei pod (PDB) per controllare quanti pod possono essere disattivati contemporaneamente.

Per ulteriori informazioni, consulta la sezione Configurazione della scalabilità automatica del pod verticale.

Combinazione di HPA e VPA

La raccomandazione ufficiale è di non combinare VPA e HPA per CPU o memoria. Tuttavia, puoi combinarli in modo sicuro quando utilizzi la modalità di raccomandazione in VPA o metriche personalizzate in HPA, ad esempio le richieste al secondo. Quando combini VPA con HPA, assicurati che i tuoi deployment ricevano traffico sufficiente, ovvero che vengano eseguiti in modo coerente al di sopra di min-replicas di HPA. In questo modo, l'assistente virtuale può comprendere le esigenze di risorse del tuo Pod.

Per ulteriori informazioni sulle limitazioni di VPA, consulta Limitazioni per la scalabilità automatica verticale dei pod.

Programma di scalabilità automatica del cluster

Il gestore della scalabilità automatica dei cluster (CA) ridimensiona automaticamente l'infrastruttura di calcolo sottostante. CA fornisce nodi per i pod che non hanno un posto in cui essere eseguiti nel cluster e rimuove i nodi sottoutilizzati. CA è ottimizzato per il costo dell'infrastruttura. In altre parole, se nel cluster sono presenti due o più tipi di nodi, CA sceglie quello meno costoso che soddisfa la domanda.

A differenza di HPA e VPA, CA non dipende dalle metriche di carico. Si basa invece sulla simulazione della pianificazione e sulle richieste di pod dichiarate. È una best practice attivare CA ogni volta che utilizzi HPA o VPA. Questa pratica garantisce che se i gestori della scalabilità automatica dei pod determinano che hai bisogno di più capacità, la tua infrastruttura sottostante cresce di conseguenza.

Come mostrano questi diagrammi, CA aggiunge e rimuove automaticamente la capacità di calcolo per gestire i picchi di traffico e farti risparmiare denaro quando i tuoi clienti dormono. È una best practice definire il budget di interruzione dei pod (PDB) per tutte le tue applicazioni. È particolarmente importante durante la fase di riduzione della CA, quando PDB controlla il numero di repliche che possono essere arrestate contemporaneamente.

Alcuni pod non possono essere riavviati da nessun gestore della scalabilità automatica quando causano un'interruzione temporanea, quindi il nodo su cui vengono eseguiti non può essere eliminato. Ad esempio, i pod di sistema (come metrics-server e kube-dns) e i pod che utilizzano l'archiviazione locale non verranno riavviati. Tuttavia, puoi modificare questo comportamento definendo i PDB per questi pod di sistema e impostando l'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" per i pod che utilizzano l'archiviazione locale che possono essere riavviati in sicurezza dal gestore della scalabilità automatica. Inoltre, valuta la possibilità di eseguire pod di lunga durata che non possono essere riavviati in un pool di nodi separato, in modo che non blocchino lo scale down di altri nodi. Infine, scopri come analizzare gli eventi CA nei log per capire perché una determinata attività di scalabilità non è avvenuta come previsto.

Se i tuoi workload sono resilienti al riavvio involontario dei nodi e alle perdite di capacità, puoi risparmiare di più creando un cluster o un pool di nodi con VM spot. Affinché CA funzioni come previsto, le richieste di risorse del pod devono essere sufficientemente grandi da consentire al pod di funzionare normalmente. Se le richieste di risorse sono troppo piccole, i nodi potrebbero non avere risorse sufficienti e i pod potrebbero arrestarsi in modo anomalo o avere problemi durante l'esecuzione.

Di seguito è riportato un riepilogo delle best practice per l'attivazione di Cluster Autoscaler nel cluster:

• Utilizza HPA o VPA per la scalabilità automatica dei workload.
• Assicurati di seguire le best practice descritte nello strumento di scalabilità automatica dei pod scelto.
• Dimensiona correttamente l'applicazione impostando limiti e richieste di risorse appropriati o utilizza VPA.
• Definisci un PDB per le tue applicazioni.
• Definisci il PDB per i pod di sistema che potrebbero bloccare la riduzione delle dimensioni. Ad esempio, kube-dns. Per evitare interruzioni temporanee nel cluster, non impostare PDB per i pod di sistema che hanno una sola replica (ad esempio metrics-server).
• Esegui pod di breve durata e pod che possono essere riavviati in pool di nodi separati, in modo che i pod di lunga durata non blocchino lo scale down.
• Evita l'over-provisioning configurando i nodi inattivi nel cluster. Per farlo, devi conoscere la tua capacità minima, che per molte aziende si verifica di notte, e impostare il numero minimo di nodi nei tuoi node pool per supportare questa capacità.
• Se hai bisogno di capacità aggiuntiva per gestire le richieste durante i picchi, utilizza i pod di pausa, descritti in Scalabilità automatica e provisioning eccessivo.

Per ulteriori informazioni, consulta Scalabilità automatica di un cluster.

Provisioning automatico dei nodi

Il provisioning automatico dei nodi (NAP) è un meccanismo di Cluster Autoscaler che aggiunge automaticamente nuovi node pool, oltre a gestirne le dimensioni per conto dell'utente. Senza il provisioning automatico dei nodi, GKE considera l'avvio di nuovi nodi solo dal set di node pool creati dall'utente. Con il provisioning automatico dei nodi, GKE può creare ed eliminare automaticamente nuovi node pool.

Il provisioning automatico dei nodi tende a ridurre lo spreco di risorse creando dinamicamente node pool più adatti ai workload pianificati. Tuttavia, la latenza della scalabilità automatica può essere leggermente superiore quando è necessario creare nuovi node pool. Se i tuoi workload sono resilienti al riavvio involontario dei nodi e alle perdite di capacità, puoi ridurre ulteriormente i costi configurando la tolleranza delle VM spot nel pod.

Di seguito sono riportate le best practice per l'attivazione del provisioning automatico dei nodi:

• Segui tutte le best practice del gestore della scalabilità automatica dei cluster.
• Imposta le dimensioni minime e massime delle risorse per evitare che NAP apporti modifiche significative al cluster quando l'applicazione non riceve traffico.
• Quando utilizzi Horizontal Pod Autoscaler per i carichi di lavoro di pubblicazione, valuta la possibilità di riservare un buffer di utilizzo target leggermente più grande, perché NAP potrebbe aumentare la latenza della scalabilità automatica in alcuni casi.

Per saperne di più, consulta Utilizzo del provisioning automatico dei nodi e Funzionalità non supportate.

Gestore della scalabilità automatica e overprovisioning

Per controllare i costi, ti consigliamo vivamente di attivare lo strumento di scalabilità automatica in base alle sezioni precedenti. Nessuna configurazione è adatta a tutti gli scenari possibili, quindi devi ottimizzare le impostazioni per il tuo carico di lavoro per assicurarti che gli autoscaler rispondano correttamente agli aumenti di traffico.

Tuttavia, come indicato nella sezione Scalabilità automatica orizzontale dei pod, gli scale up potrebbero richiedere un po' di tempo a causa del provisioning dell'infrastruttura. Per visualizzare questa differenza nel tempo e i possibili scenari di scalabilità, considera l'immagine seguente.

Quando il cluster ha spazio sufficiente per il deployment di nuovi pod, viene attivato uno degli scenari di scalabilità verticale del workload. Ciò significa che se un nodo esistente non ha mai eseguito il deployment della tua applicazione, deve scaricare le immagini container prima di avviare il pod (scenario 1). Tuttavia, se lo stesso nodo deve avviare una nuova replica del pod della tua applicazione, il tempo totale di scalabilità aumenta perché non è necessario scaricare alcuna immagine (scenario 2).

Quando il cluster non ha spazio sufficiente per il deployment di nuovi pod, viene attivato uno degli scenari di scalabilità verticale dell'infrastruttura e del workload. Ciò significa che Cluster Autoscaler deve eseguire il provisioning di nuovi nodi e avviare il software richiesto prima di avvicinarsi all'applicazione (scenario 1). Se utilizzi il provisioning automatico dei nodi, a seconda del carico di lavoro pianificato, potrebbero essere necessari nuovi pool di nodi. In questa situazione, il tempo totale di scale up aumenta perché il gestore della scalabilità automatica dei cluster deve eseguire il provisioning di nodi e node pool (scenario 2).

Per gli scenari in cui è necessaria una nuova infrastruttura, non comprimere troppo il cluster, ovvero devi eseguire l'overprovisioning, ma solo per riservare il buffer necessario per gestire i picchi di richieste previsti durante gli aumenti di scalabilità.

Esistono due strategie principali per questo tipo di overprovisioning:

• Ottimizza il target di utilizzo di HPA. La seguente equazione è un modo semplice e sicuro per trovare un buon target CPU:

  (1 - buff)/(1 + perc)

  • buff è un buffer di sicurezza che puoi impostare per evitare di raggiungere il 100% di CPU. Questa variabile è utile perché raggiungere il 100% di CPU significa che la latenza dell'elaborazione delle richieste è molto più elevata del solito.
  • perc è la percentuale di crescita del traffico che prevedi in due o tre minuti.

  Ad esempio, se prevedi una crescita del 30% delle richieste e vuoi evitare di raggiungere il 100% della CPU definendo un buffer di sicurezza del 10%, la formula sarà simile a questa:

  (1 - 0,1)/(1 + 0,3) = 0,69

• Configurare i pod di pausa. Non è possibile configurare il gestore della scalabilità automatica del cluster per avviare i nodi in anticipo. In alternativa, puoi impostare una destinazione di utilizzo HPA per fornire un buffer per gestire i picchi di carico. Tuttavia, se prevedi picchi di utilizzo elevati, impostare un target di utilizzo HPA ridotto potrebbe non essere sufficiente o potrebbe diventare troppo costoso.

  Una soluzione alternativa a questo problema è utilizzare pause Pods. I pod di pausa sono deployment a bassa priorità che non fanno altro che riservare spazio nel cluster. Ogni volta che viene pianificato un pod con priorità elevata, i pod in pausa vengono rimossi e il pod con priorità elevata prende immediatamente il loro posto. I pod di pausa rimossi vengono quindi riprogrammati e, se non c'è spazio nel cluster, il gestore della scalabilità automatica del cluster crea nuovi nodi per inserirli. È consigliabile avere un solo pod di pausa per nodo. Ad esempio, se utilizzi 4 nodi CPU, configura la richiesta di CPU dei pod di pausa con circa 3200 m.

Scegliere il tipo di macchina giusto

Oltre alla scalabilità automatica, altre configurazioni possono aiutarti a eseguire applicazioni Kubernetes con ottimizzazione dei costi su GKE. Questa sezione descrive come scegliere il tipo di macchina giusto.

VM spot

Le VM spot sono istanze di VM di Compute Engine che non offrono garanzie di disponibilità. Le VM spot sono fino al 91% più economiche rispetto alle VM Compute Engine standard, ma ti consigliamo di utilizzarle con cautela nei cluster GKE. Le Spot VM su GKE sono più adatte per l'esecuzione di job batch o a tolleranza di errore che sono meno sensibili alla natura temporanea e non garantita delle Spot VM. I workload stateful e di serving non devono utilizzare VM spot, a meno che tu non prepari il sistema e l'architettura per gestire i vincoli delle VM spot.

Indipendentemente dal tipo di workload, devi prestare attenzione ai seguenti vincoli:

• Il budget per l'interruzione potrebbe non essere rispettato perché le VM spot possono essere arrestate inavvertitamente.
• Non è garantito che i pod vengano arrestati normalmente una volta che la preemption dei nodi ignora il periodo di tolleranza del pod.
• Potrebbero essere necessari diversi minuti prima che GKE rilevi che il nodo è stato interrotto e che i pod non sono più in esecuzione, il che ritarda la riprogrammazione dei pod su un nuovo nodo.

A partire da GKE v1.20, lo spegnimento controllato dei nodi è abilitato per impostazione predefinita per fornire una notifica ai workload in esecuzione.

Le VM spot non hanno disponibilità garantita, il che significa che possono esaurirsi facilmente in alcune regioni. Per superare questa limitazione, ti consigliamo di impostare un pool di nodi di backup senza VM spot. Cluster Autoscaler dà la preferenza alle VM spot perché è ottimizzato per il costo dell'infrastruttura.

Per saperne di più, consulta Esecuzione di carichi di lavoro a tolleranza di errore a costi inferiori con le VM spot, Esecuzione di carichi di lavoro a tolleranza di errore a costi inferiori nei pod spot e Esecuzione di applicazioni web su GKE utilizzando VM spot ottimizzate per i costi.

Tipi di macchine E2

I tipi di macchine E2 (VM E2) sono VM ottimizzate per i costi che ti offrono un risparmio del 31% rispetto ai tipi di macchine N1. Le VM E2 sono adatte a un'ampia gamma di carichi di lavoro, tra cui server web, microservizi, applicazioni business critical, database di piccole e medie dimensioni e ambienti di sviluppo.

Per saperne di più sulle VM E2 e sul loro confronto con altri Google Cloud tipi di macchine, consulta Gestione dinamica delle risorse basata sulle prestazioni nelle VM E2 e Tipi di macchine.

Seleziona la regione appropriata.

Quando il costo è un vincolo, la posizione in cui esegui i cluster GKE è importante. A causa di molti fattori, il costo varia in base alla regione di computing. Assicurati quindi di eseguire il tuo workload nell'opzione meno costosa, ma in cui la latenza non influisce sul tuo cliente. Se il tuo workload richiede la copia dei dati da una regione all'altra, ad esempio per eseguire un job batch, devi anche considerare il costo del trasferimento di questi dati.

Per saperne di più su come scegliere la regione giusta, consulta Best practice per la scelta delle regioni di Compute Engine.

Registrarsi per usufruire degli sconti per impegno di utilizzo

Se intendi rimanere con Google Cloud per alcuni anni, ti consigliamo vivamente di acquistare sconti per impegno di utilizzo in cambio di prezzi molto scontati per l'utilizzo delle VM. Quando firmi un contratto basato su impegno di utilizzo, acquisti risorse di calcolo a un prezzo scontato (fino al 70% di sconto) in cambio dell'impegno a pagare per queste risorse per uno o tre anni. Se non sai con certezza a quante risorse impegnarti, esamina il tuo utilizzo minimo di calcolo, ad esempio durante la notte, e impegna il pagamento per quell'importo.

Per saperne di più sui prezzi per impegno di utilizzo per diversi tipi di macchine, consulta Prezzi delle istanze VM.

Esamina i piccoli cluster di sviluppo

Per i piccoli cluster di sviluppo in cui devi ridurre al minimo i costi, valuta la possibilità di utilizzare cluster Autopilot. Con i cluster in questa modalità operativa, non ti vengono addebitati costi per i pod di sistema, il sistema operativo o i workload non pianificati.

Rivedere le strategie di logging e monitoraggio

Se utilizzi Cloud Logging e Cloud Monitoring per fornire osservabilità alle tue applicazioni e alla tua infrastruttura, paghi solo ciò che utilizzi. Tuttavia, più log vengono generati dalla tua infrastruttura e dalle tue applicazioni e più a lungo li conservi, più paghi. Allo stesso modo, più metriche esterne e personalizzate hai, più alti sono i costi.

Esamina il traffico in uscita tra regioni nei cluster regionali e multi-zona

I tipi di cluster GKE disponibili sono a zona singola, multi-zona e regionale. Grazie all'elevata disponibilità dei nodi nelle zone, i cluster regionali e multizona sono adatti agli ambienti di produzione. Tuttavia, ti viene addebitato il traffico in uscita tra zone. Per gli ambienti di produzione, ti consigliamo di monitorare il carico di traffico nelle zone e migliorare le API per ridurlo al minimo. Valuta anche l'utilizzo di configurazioni di affinità e anti-affinità tra pod per collocare i pod dipendenti di servizi diversi negli stessi nodi o nella stessa zona di disponibilità per ridurre al minimo i costi e la latenza di rete tra loro. Il modo consigliato per monitorare questo traffico è abilitare la misurazione dell'utilizzo di GKE e il relativo agente di uscita dalla rete, che è disabilitato per impostazione predefinita.

Per gli ambienti non di produzione, la best practice per il risparmio dei costi è il deployment di cluster a zona singola.

Preparare l'ambiente in base al tipo di workload

Le aziende hanno requisiti di costo e disponibilità diversi. I loro carichi di lavoro possono essere suddivisi in carichi di lavoro di gestione, che devono rispondere rapidamente a picchi o aumenti improvvisi, e carichi di lavoro batch, che riguardano il lavoro da svolgere. I carichi di lavoro di serving richiedono una latenza di scalabilità ridotta, mentre i carichi di lavoro batch sono più tolleranti alla latenza. Le diverse aspettative per questi tipi di carichi di lavoro rendono più flessibile la scelta di metodi di risparmio dei costi diversi.

Workload batch

Poiché i carichi di lavoro batch si occupano del lavoro finale, consentono di risparmiare sui costi su GKE perché i carichi di lavoro sono generalmente tolleranti a una certa latenza al momento dell'avvio del job. Questa tolleranza consente al gestore della scalabilità automatica dei cluster di avviare nuovi nodi solo quando i job sono pianificati e di arrestarli al termine dei job.

La prima best practice consigliata è separare i carichi di lavoro batch in diversi pool di nodi utilizzando etichette e selettori e taint e tolleranze. Il motivo è il seguente:

• Il gestore della scalabilità automatica dei cluster può eliminare i nodi vuoti più rapidamente quando non è necessario riavviare i pod. Man mano che i job batch terminano, il cluster accelera il processo di riduzione delle dimensioni se il workload è in esecuzione su nodi dedicati ora vuoti. Per migliorare ulteriormente la velocità di riduzione della scalabilità, valuta la possibilità di configurare il profilo di ottimizzazione dell'utilizzo di CA.
• Alcuni pod non possono essere riavviati, quindi bloccano definitivamente lo scale down dei relativi nodi. Questi pod, inclusi i pod di sistema, devono essere eseguiti su node pool diversi in modo da non influire sulla riduzione della scalabilità.

La seconda best practice consigliata è utilizzare il provisioning automatico dei nodi per creare automaticamente pool di nodi dedicati per i job con un taint o una tolleranza corrispondenti. In questo modo, puoi separare molti carichi di lavoro diversi senza dover configurare tutti questi pool di nodi diversi.

Ti consigliamo di utilizzare le VM spot solo se esegui job a tolleranza di errore che risentono meno della natura temporanea e non garantita delle VM spot.

Workload di pubblicazione

A differenza dei carichi di lavoro batch, i carichi di lavoro di serving devono rispondere il più rapidamente possibile a burst o picchi. Questi improvvisi aumenti di traffico potrebbero essere dovuti a molti fattori, ad esempio spot TV, eventi di picco come il Black Friday o notizie dell'ultima ora. La tua applicazione deve essere preparata per gestirli.

I problemi nella gestione di questi picchi sono comunemente correlati a uno o più dei seguenti motivi:

• Applicazioni non pronte per l'esecuzione su Kubernetes, ad esempio app con dimensioni delle immagini elevate, tempi di avvio lenti o configurazioni Kubernetes non ottimali.
• Applicazioni che dipendono da un'infrastruttura che richiede tempo per il provisioning, come le GPU.
• Gestori della scalabilità automatica e overprovisioning non impostati correttamente.

Prepara le applicazioni Kubernetes basate sul cloud

Alcune delle best practice descritte in questa sezione possono farti risparmiare denaro. Tuttavia, poiché la maggior parte di queste pratiche ha lo scopo di far funzionare in modo affidabile la tua applicazione con gli autoscaler, ti consigliamo vivamente di implementarle.

Comprendere la capacità dell'applicazione

Quando pianifichi la capacità dell'applicazione, scopri quante richieste simultanee può gestire la tua applicazione, quanta CPU e memoria richiede e come risponde in condizioni di carico elevato. La maggior parte dei team non conosce queste capacità, pertanto ti consigliamo di testare il comportamento della tua applicazione sotto pressione. Prova a isolare una singola replica del pod dell'applicazione con la scalabilità automatica disattivata, quindi esegui i test simulando un carico di utilizzo reale. In questo modo puoi capire la capacità per pod. Ti consigliamo poi di configurare Cluster Autoscaler, le richieste e i limiti delle risorse e HPA o VPA. Quindi, metti di nuovo sotto stress l'applicazione, ma con più forza per simulare picchi improvvisi.

Idealmente, per eliminare i problemi di latenza, questi test devono essere eseguiti dalla stessa regione o zona in cui è in esecuzione l'applicazione Google Cloud. Puoi utilizzare lo strumento che preferisci per questi test, che si tratti di uno script creato in autonomia o di uno strumento per il rendimento più avanzato, come Apache Benchmark, JMeter o Locust.

Per un esempio di come eseguire i test, consulta Test di carico distribuito con Google Kubernetes Engine.

Assicurati che la tua applicazione possa crescere verticalmente e orizzontalmente

Assicurati che la tua applicazione possa aumentare e diminuire. Ciò significa che puoi scegliere di gestire gli aumenti di traffico aggiungendo più CPU e memoria o più repliche di pod. In questo modo, puoi sperimentare ciò che si adatta meglio alla tua applicazione, che si tratti di una configurazione diversa dello scalatore automatico o di una dimensione del nodo diversa. Purtroppo, alcune applicazioni sono single-thread o limitate da un numero fisso di worker o sottoprocessi che rendono questo esperimento impossibile senza un refactoring completo della loro architettura.

Imposta limiti e richieste di risorse appropriati

Comprendendo la capacità della tua applicazione, puoi determinare cosa configurare nelle risorse del container. Risorse in Kubernetes sono principalmente definite come CPU e memoria (RAM). Configuri la CPU o la memoria come quantità necessaria per eseguire l'applicazione utilizzando la richiesta spec.containers[].resources.requests.<cpu|memory> e configuri il limite utilizzando la richiesta spec.containers[].resources.limits.<cpu|memory>. Per maggiori informazioni su come configurare le richieste di risorse, consulta Impostare manualmente le richieste di risorse del pod.

Quando hai impostato correttamente le richieste di risorse, lo scheduler Kubernetes può utilizzarle per decidere il nodo in cui posizionare il pod. In questo modo, i pod vengono inseriti in nodi che possono farli funzionare normalmente, in modo da garantire una maggiore stabilità e ridurre lo spreco di risorse. Inoltre, la definizione dei limiti delle risorse contribuisce a garantire che queste applicazioni non utilizzino mai tutta l'infrastruttura sottostante disponibile fornita dai nodi di calcolo.

Utilizza le seguenti best practice per impostare le richieste e i limiti delle risorse del container:

• Memoria: imposta la stessa quantità di memoria per la richiesta e il limite.
• CPU: per la richiesta, specifica la CPU minima necessaria per garantire il corretto funzionamento, in base ai tuoi SLO. Imposta un limite di CPU senza limiti.

Prendi come esempio il seguente deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

Il ragionamento alla base del pattern precedente si basa sul funzionamento della gestione delle risorse esaurite di Kubernetes. In breve, quando le risorse del computer sono esaurite, i nodi diventano instabili. Per evitare questa situazione, kubelet monitora e impedisce la totale carenza di queste risorse classificando i pod che consumano più risorse. Quando la CPU è contesa, questi pod possono essere limitati alle richieste. Tuttavia, poiché la memoria è una risorsa incomprimibile, quando la memoria è esaurita, il pod deve essere arrestato. Per evitare l'arresto dei pod e, di conseguenza, la destabilizzazione dell'ambiente, devi impostare la memoria richiesta sul limite di memoria. Puoi identificare i carichi di lavoro per i quali non sono configurate richieste o limiti delle risorse per i container visualizzando gli approfondimenti del sottotipo REQUEST_OR_LIMIT_NOT_SET. Per saperne di più, vedi Identificare i carichi di lavoro senza richieste o limiti di risorse.

Puoi anche utilizzare VPA in modalità di suggerimento per determinare l'utilizzo di CPU e memoria per una determinata applicazione. Per saperne di più, consulta Analizzare le richieste di risorse.

Poiché VPA fornisce questi suggerimenti in base all'utilizzo dell'applicazione, ti consigliamo di utilizzare VPA in modalità di suggerimento in un ambiente simile alla produzione per affrontare il traffico reale. Lo stato di VPA genera quindi un report con le richieste e i limiti delle risorse suggeriti, che puoi specificare staticamente nel manifest di deployment. Se la tua applicazione definisce già HPA, consulta Combinazione di HPA e VPA.

Assicurati che il container sia il più snello possibile

Quando esegui i container su Kubernetes, l'applicazione può avviarsi e arrestarsi in qualsiasi momento. Per questo motivo, è importante seguire queste best practice:

• Avere l'immagine più piccola possibile. È una best practice avere immagini di piccole dimensioni perché ogni volta che Cluster Autoscaler esegue il provisioning di un nuovo nodo per il cluster, il nodo deve scaricare le immagini che verranno eseguite in quel nodo. Più piccola è l'immagine, più velocemente il nodo può scaricarla.

• Avvia la procedura di richiesta il più rapidamente possibile. L'avvio di alcune applicazioni può richiedere minuti a causa del caricamento delle classi, della memorizzazione nella cache e così via. Quando un pod richiede un avvio lungo, le richieste dei tuoi clienti potrebbero non andare a buon fine mentre la tua applicazione è in fase di avvio.

Tieni in considerazione queste due pratiche quando progetti il tuo sistema, soprattutto se prevedi picchi o aumenti improvvisi. Un'immagine di piccole dimensioni e un avvio rapido ti aiutano a ridurre la latenza di scalabilità. Di conseguenza, puoi gestire meglio gli aumenti di traffico senza preoccuparti troppo dell'instabilità. Queste pratiche funzionano meglio con le best practice di scalabilità automatica descritte in Scalabilità automatica di GKE.

Aggiungi budget di interruzione dei pod alla tua applicazione

Il budget di interruzione dei pod (PDB) limita il numero di pod che possono essere disattivati contemporaneamente da un'interruzione volontaria. Ciò significa che il budget di interruzione definito viene rispettato durante le implementazioni, gli upgrade dei nodi e qualsiasi attività di scalabilità automatica. Tuttavia, questo budget non può essere garantito quando si verificano eventi involontari, come guasti hardware, panico del kernel o l'eliminazione accidentale di una VM.

Quando il PDB viene rispettato durante la fase di compattazione del gestore della scalabilità automatica dei cluster, è una best practice definire un budget per l'interruzione dei pod per ogni applicazione. In questo modo puoi controllare il numero minimo di repliche necessarie per supportare il carico in qualsiasi momento, anche quando CA riduce le dimensioni del cluster.

Per ulteriori informazioni, vedi Specifica di un budget di interruzione per l'applicazione.

Imposta probe di idoneità e attività significativi per la tua applicazione

L'impostazione di probe significativi garantisce che la tua applicazione riceva traffico solo quando è attiva e in esecuzione e pronta ad accettare il traffico. GKE utilizza probe di idoneità per determinare quando aggiungere o rimuovere pod dai bilanciatori del carico. GKE utilizza probe di attività per determinare quando riavviare i pod.

Il probe di attività è utile per comunicare a Kubernetes che un determinato pod non è in grado di fare progressi, ad esempio quando viene rilevato uno stato di deadlock. La sonda di idoneità è utile per comunicare a Kubernetes che la tua applicazione non è pronta a ricevere traffico, ad esempio durante il caricamento di grandi quantità di dati della cache all'avvio.

Per garantire il ciclo di vita corretto dell'applicazione durante le attività di scalabilità verticale, è importante:

• Definisci il probe di idoneità per tutti i tuoi container.
• Se la tua applicazione dipende dal caricamento di una cache all'avvio, il probe di idoneità deve indicare che è pronta solo dopo che la cache è stata caricata completamente.
• Se la tua applicazione può iniziare a pubblicare immediatamente, una buona implementazione del probe predefinito può essere il più semplice possibile, ad esempio un endpoint HTTP che restituisce un codice di stato 200.
• Se implementi un probe più avanzato, ad esempio per verificare se il pool di connessioni dispone di risorse disponibili, assicurati che il tasso di errore non aumenti rispetto a un'implementazione più semplice.
• Non consentire mai alla logica di probing di accedere ad altri servizi. Se questi servizi non rispondono tempestivamente, il ciclo di vita del pod potrebbe essere compromesso.

Per ulteriori informazioni, consulta Configurare i probe di attività, disponibilità e avvio.

Assicurati che le applicazioni vengano chiuse in base alle aspettative di Kubernetes

I gestori della scalabilità automatica ti aiutano a rispondere ai picchi creando nuovi pod e nodi ed eliminandoli al termine dei picchi. Ciò significa che, per evitare errori durante la pubblicazione, i pod devono essere preparati per un avvio rapido o un arresto controllato.

Poiché Kubernetes aggiorna in modo asincrono gli endpoint e i bilanciatori del carico, è importante seguire queste best practice per garantire arresti senza interruzioni:

• Non interrompere l'accettazione di nuove richieste subito dopo SIGTERM. La tua applicazione non deve arrestarsi immediatamente, ma deve completare tutte le richieste in corso e continuare ad ascoltare le connessioni in entrata che arrivano dopo l'inizio della terminazione del pod. Potrebbe volerci un po' di tempo prima che Kubernetes aggiorni tutti i kube-proxy e i bilanciatori del carico. Se l'applicazione termina prima dell'aggiornamento, alcune richieste potrebbero causare errori lato client.
• Se la tua applicazione non segue la pratica precedente, utilizza l'hook preStop. La maggior parte dei programmi non smette di accettare richieste immediatamente. Tuttavia, se utilizzi codice di terze parti o gestisci un sistema su cui non hai il controllo, ad esempio nginx, l'hook preStop è una buona opzione per attivare un arresto controllato senza modificare l'applicazione. Una strategia comune consiste nell'eseguire, nell'hook preStop, un'attesa di alcuni secondi per posticipare SIGTERM. In questo modo Kubernetes ha più tempo per completare il processo di eliminazione del pod e riduce gli errori di connessione lato client.
• Gestisci SIGTERM per le pulizie. Se la tua applicazione deve eseguire la pulizia o ha uno stato in memoria che deve essere reso persistente prima dell'interruzione del processo, questo è il momento di farlo. I diversi linguaggi di programmazione hanno modi diversi per rilevare questo segnale, quindi trova il modo giusto nel tuo linguaggio.
• Configura terminationGracePeriodSeconds in base alle esigenze della tua applicazione. Alcune applicazioni richiedono più dei 30 secondi predefiniti per essere completate. In questo caso, devi specificare terminationGracePeriodSeconds. Valori elevati potrebbero aumentare il tempo necessario per gli upgrade o i rollout dei nodi, ad esempio. Valori bassi potrebbero non lasciare abbastanza tempo a Kubernetes per completare la procedura di terminazione del pod. In ogni caso, ti consigliamo di impostare il periodo di terminazione dell'applicazione su meno di 10 minuti perché il gestore della scalabilità automatica dei cluster lo rispetta solo per 10 minuti.
• Se la tua applicazione utilizza il bilanciamento del carico nativo del container, inizia a non superare il probe di idoneità quando ricevi un SIGTERM. Questa azione segnala direttamente ai bilanciatori del carico di interrompere l'inoltro di nuove richieste al pod di backend. A seconda della corsa tra la configurazione del controllo di integrità e la programmazione dell'endpoint, il pod di backend potrebbe essere escluso dal traffico in precedenza.

Per saperne di più, consulta la sezione Best practice di Kubernetes: terminazione senza problemi.

Configura NodeLocal DNSCache

Il DNS gestito da GKE è implementato da kube-dns, un componente aggiuntivo di cui è stato eseguito il deployment in tutti i cluster GKE. Quando esegui applicazioni che utilizzano molte risorse DNS, la configurazione kube-dns-autoscaler predefinita, che modifica il numero di repliche kube-dns in base al numero di nodi e core nel cluster, potrebbe non essere sufficiente. In questo scenario, le query DNS possono rallentare o scadere. Per mitigare questo problema, le aziende sono abituate a ottimizzare il ConfigMap kube-dns-autoscaler per aumentare il numero di repliche kube-dns nei cluster. Sebbene questa strategia possa funzionare come previsto, aumenta l'utilizzo delle risorse e il costo totale di GKE.

Un'altra alternativa più scalabile e ottimizzata per i costi è configurare NodeLocal DNSCache nel cluster. NodeLocal DNSCache è un componente aggiuntivo di GKE facoltativo che migliora la latenza di ricerca DNS, rende i tempi di ricerca DNS più coerenti e riduce il numero di query DNS a kube-dns eseguendo una cache DNS su ogni nodo del cluster.

Per maggiori informazioni, consulta Configurazione di NodeLocal DNSCache.

Utilizzare il bilanciamento del carico nativo del container tramite Ingress

Il bilanciamento del carico nativo del container consente ai bilanciatori del carico di scegliere come target direttamente i pod Kubernetes e di distribuire uniformemente il traffico ai pod utilizzando un modello dei dati chiamato gruppi di endpoint di rete (NEG). Questo approccio migliora le prestazioni di rete, aumenta la visibilità, attiva funzionalità di bilanciamento del carico avanzate e consente l'utilizzo di Cloud Service Mesh, il piano di controllo del traffico completamente gestito per mesh di servizi mesh.Google Cloud

Grazie a questi vantaggi, il bilanciamento del carico nativo del container è la soluzione consigliata per il bilanciamento del carico tramite Ingress. Quando i NEG vengono utilizzati con GKE Ingress, il controller Ingress facilita la creazione di tutti gli aspetti del bilanciatore del carico L7. Ciò include la creazione dell'indirizzo IP virtuale, delle regole di forwarding, dei controlli di integrità, delle regole firewall e altro ancora.

Il bilanciamento del carico nativo del container diventa ancora più importante quando si utilizza Cluster Autoscaler. Per i bilanciatori del carico non NEG, durante le riduzioni, la programmazione del bilanciamento del carico e lo svuotamento della connessione potrebbero non essere completati prima che Cluster Autoscaler termini le istanze dei nodi. Ciò potrebbe interrompere le connessioni in corso che passano attraverso il nodo anche quando i pod di backend non si trovano sul nodo.

Il bilanciamento del carico nativo del container è attivato per impostazione predefinita per i servizi quando sono vere tutte le seguenti condizioni:

• I servizi sono stati creati nei cluster GKE 1.17.6-gke.7 e versioni successive.
• Se utilizzi cluster nativi di VPC.
• Se non utilizzi un VPC condiviso.
• Se non utilizzi i criteri di rete GKE.

Per maggiori informazioni, consulta la documentazione di GKE Ingress e Utilizzo del bilanciamento del carico nativo dei container.

Valuta la possibilità di utilizzare i nuovi tentativi con backoff esponenziale

Nelle architetture di microservizi in esecuzione su Kubernetes, potrebbero verificarsi errori temporanei per vari motivi, ad esempio:

• Un grande picco che ha innescato un aumento ancora in corso
• Errori di rete
• Connessioni interrotte perché i pod non si arrestano
• Arresto involontario delle VM spot
• Applicazioni che raggiungono i limiti di valutazione

Questi problemi sono temporanei e puoi mitigarli chiamando di nuovo il servizio dopo un po' di tempo. Tuttavia, per evitare di sovraccaricare il servizio di destinazione con le richieste, è importante eseguire queste chiamate utilizzando un backoff esponenziale.

Per facilitare questo pattern di nuovi tentativi, molte librerie esistenti implementano la logica di nuovi tentativi esponenziali. Puoi utilizzare la libreria che preferisci o scrivere il tuo codice. Se utilizzi Istio o Cloud Service Mesh (ASM), puoi optare per il meccanismo di nuovo tentativo a livello di proxy, che esegue i nuovi tentativi in modo trasparente per tuo conto.

È importante pianificare l'applicazione in modo che supporti i nuovi tentativi di chiamata del servizio, ad esempio per evitare di inserire informazioni già inserite. Tieni presente che una catena di tentativi potrebbe influire sulla latenza dell'utente finale, che potrebbe andare in timeout se non pianificata correttamente.

Monitora il tuo ambiente e applica configurazioni e pratiche ottimizzate per i costi

In molte medie e grandi aziende, un team centralizzato di piattaforma e infrastruttura è spesso responsabile della creazione, della manutenzione e del monitoraggio dei cluster Kubernetes per l'intera azienda. Ciò indica una forte necessità di responsabilità per l'utilizzo delle risorse e di assicurarsi che tutti i team rispettino le norme aziendali. Questa sezione illustra le opzioni per monitorare e applicare le pratiche relative ai costi.

Osserva i tuoi cluster GKE e cerca i suggerimenti

Puoi controllare l'utilizzo delle risorse in un cluster Kubernetes esaminando i container, i pod e i servizi, nonché le caratteristiche del cluster nel suo complesso. Esistono molti modi per eseguire questa attività, ma l'approccio iniziale che consigliamo è osservare i cluster GKE tramite la dashboard di monitoraggio. In questo modo, puoi visualizzare i dati delle serie temporali sull'utilizzo del cluster, aggregarli e analizzarli in base a infrastruttura, carichi di lavoro e servizi.

Anche se questo è un buon punto di partenza, Google Cloud offre altre opzioni, ad esempio:

• Nella Google Cloud console, nella pagina Cluster GKE, guarda la colonna Notifiche. Se in un cluster si verifica un elevato spreco di risorse, l'interfaccia utente fornisce un suggerimento sulle informazioni complessive allocate rispetto a quelle richieste.

  Vai all'elenco dei cluster GKE

• Nella console Google Cloud , nella pagina Suggerimenti, cerca le schede dei suggerimenti Risparmio sui costi.

  Vai all'hub dei suggerimenti

Per maggiori dettagli, vedi Osservare i cluster GKE e Guida introduttiva a Recommendation Hub.

Abilita misurazione utilizzo GKE

Per un approccio più flessibile che ti consente di visualizzare ripartizioni approssimative dei costi, prova la misurazione dell'utilizzo di GKE. La misurazione dell'utilizzo di GKE ti consente di visualizzare i profili di utilizzo dei tuoi cluster GKE suddivisi in base a spazi dei nomi ed etichette. Tiene traccia delle informazioni sulle richieste di risorse e sul consumo di risorse dei carichi di lavoro del cluster, ad esempio CPU, GPU, TPU, memoria, spazio di archiviazione e, facoltativamente, uscita di rete.

La misurazione dell'utilizzo di GKE ti aiuta a comprendere la struttura complessiva dei costi dei tuoi cluster GKE, quale team o applicazione spende di più, quale ambiente o componente ha causato un improvviso picco di utilizzo o costi e quale team sta sprecando risorse. Confrontando le richieste di risorse con l'utilizzo effettivo, puoi capire quali workload sono sottodimensionati o sovradimensionati.

Puoi sfruttare i modelli predefiniti di Looker Studio oppure andare oltre e personalizzare le dashboard in base alle esigenze della tua organizzazione. Per saperne di più sulla misurazione dell'utilizzo di GKE e sui relativi prerequisiti, consulta Informazioni sull'utilizzo delle risorse del cluster.

Comprendere il funzionamento di Metrics Server e monitorarlo

Metrics Server è l'origine delle metriche delle risorse dei container per le pipeline di scalabilità automatica integrate di GKE. Metrics Server recupera le metriche da kubelet e le espone tramite l'API Metrics di Kubernetes. HPA e VPA utilizzano queste metriche per determinare quando attivare la scalabilità automatica.

Per il corretto funzionamento della scalabilità automatica di GKE, devi disporre di un Metrics Server integro. Con il deployment di GKE metrics-server, viene installato un resizer, che fa crescere verticalmente il container Metrics Server aggiungendo o rimuovendo CPU e memoria in base al numero di nodi del cluster. L'aggiornamento in loco dei pod non è ancora supportato in Kubernetes, motivo per cui il nanny deve riavviare il pod metrics-server per applicare le nuove risorse richieste.

Sebbene il riavvio avvenga rapidamente, la latenza totale dei gestori della scalabilità automatica per rendersi conto di dover agire può aumentare leggermente dopo un ridimensionamento di metrics-server. Per evitare riavvii frequenti di Metrics Server nei cluster in rapida evoluzione, a partire da GKE 1.15.11-gke.9, il nanny supporta i ritardi di ridimensionamento.

Segui queste best practice quando utilizzi Metric Server:

• Scegli la versione GKE che supporta i ritardi nel ridimensionamento di metrics-server. Puoi verificarlo controllando se il file YAML di deployment di metrics-server ha la configurazione scale-down-delay nel container metrics-server-nanny.
• Monitora il deployment di metrics-server. Se Metrics Server non funziona, significa che la scalabilità automatica non funziona. Vuoi che i tuoi servizi di monitoraggio con priorità più alta monitorino questo deployment.
• Segui le best practice descritte in Scalabilità automatica di GKE.

Utilizzare le quote delle risorse Kubernetes

Nei cluster multi-tenant, in genere team diversi diventano responsabili delle applicazioni di cui è stato eseguito il deployment in spazi dei nomi diversi. Per un gruppo di infrastrutture e piattaforme centralizzate, è preoccupante che un team possa utilizzare più risorse del necessario. L'esaurimento di tutte le risorse di calcolo del cluster o l'attivazione di troppi aumenti di scalabilità può aumentare i costi.

Per risolvere questo problema, devi utilizzare le quote risorse. Le quote delle risorse gestiscono la quantità di risorse utilizzate dagli oggetti in uno spazio dei nomi. Puoi impostare le quote in termini di risorse di calcolo (CPU e memoria) e di archiviazione o in termini di conteggi degli oggetti. Le quote delle risorse ti consentono di assicurarti che nessun tenant utilizzi più della quota assegnata di risorse del cluster.

Per saperne di più, consulta Configurare le quote di memoria e CPU per uno spazio dei nomi.

Valuta la possibilità di utilizzare Policy Controller di GKE Enterprise

GKE Enterprise Policy Controller è un controller di ammissione dinamico Kubernetes che controlla, verifica e applica la conformità dei cluster a criteri relativi a sicurezza, normative o regole aziendali arbitrarie. Policy Controller utilizza i vincoli per applicare la conformità dei cluster. Ad esempio, puoi installare nel tuo cluster vincoli per molte delle best practice descritte nella sezione Preparare l'applicazione Kubernetes basata sul cloud. In questo modo, i deployment vengono rifiutati se non rispettano rigorosamente le tue pratiche Kubernetes. L'applicazione di queste regole aiuta a evitare picchi di costi imprevisti e riduce le possibilità di instabilità del carico di lavoro durante la scalabilità automatica.

Per saperne di più su come applicare e scrivere le tue regole, vedi Creazione di vincoli e Scrittura di un modello di vincolo. Se non sei un cliente GKE Enterprise, puoi prendere in considerazione l'utilizzo di Gatekeeper, il software open source su cui si basa Policy Controller.

Progettare la pipeline CI/CD per applicare pratiche di risparmio dei costi

Policy Controller di GKE Enterprise ti aiuta a evitare di eseguire il deployment di software non conforme nel tuo cluster GKE. Tuttavia, ti consigliamo di applicare questi vincoli delle norme all'inizio del ciclo di sviluppo, ad esempio nei controlli pre-commit, nei controlli delle pull request, nei flussi di lavoro di distribuzione o in qualsiasi passaggio che abbia senso nel tuo ambiente. Questa pratica ti consente di trovare e correggere rapidamente le configurazioni errate e ti aiuta a capire a cosa devi prestare attenzione creando delle barriere protettive.

Valuta anche l'utilizzo delle funzioni kpt nella pipeline CI/CD per verificare se i file di configurazione Kubernetes rispettano i vincoli imposti da GKE Enterprise Policy Controller e per stimare l'utilizzo delle risorse o il costo del deployment. In questo modo, puoi interrompere la pipeline quando viene rilevato un problema relativo ai costi. In alternativa, puoi creare un processo di approvazione del deployment diverso per le configurazioni che, ad esempio, aumentano il numero di repliche.

Per maggiori informazioni, consulta Utilizzo di Policy Controller in una pipeline CI e, per un esempio completo di una piattaforma di distribuzione, vedi CI/CD moderna con GKE Enterprise.

Diffondere la cultura del risparmio

Molte organizzazioni creano astrazioni e piattaforme per nascondere la complessità dell'infrastruttura. Si tratta di una pratica comune nelle aziende che eseguono la migrazione dei propri servizi dalle macchine virtuali a Kubernetes. A volte queste aziende consentono agli sviluppatori di configurare le proprie applicazioni in produzione. Tuttavia, non è insolito vedere sviluppatori che non hanno mai utilizzato un cluster Kubernetes.

Le pratiche che consigliamo in questa sezione non significano che devi smettere di fare astrazioni. ma ti aiutano a visualizzare la spesa per Google Cloud e a formare sviluppatori e operatori sulla tua infrastruttura. Puoi farlo creando incentivi e programmi di apprendimento in cui puoi utilizzare lezioni tradizionali o online, gruppi di discussione, revisioni tra pari, programmazione in coppia, CI/CD e gamification per il risparmio dei costi e altro ancora. Ad esempio, nel mondo Kubernetes, è importante comprendere l'impatto di un'applicazione di immagini da 3 GB, di una sonda di preparazione mancante o di una configurazione errata di HPA.

Infine, come mostrato nella ricerca DORA di Google, le capacità culturali sono alcuni dei principali fattori che determinano un miglioramento delle prestazioni organizzative, una riduzione del lavoro di rielaborazione, un minore burnout e così via. Il risparmio sui costi non fa eccezione. Consentire ai dipendenti di accedere alle proprie spese li allinea più strettamente agli obiettivi e ai vincoli aziendali.

Riepilogo delle best practice

La tabella seguente riepiloga le best practice consigliate in questo documento.

Passaggi successivi

• Trova suggerimenti di progettazione e best practice per ottimizzare i costi dei workload in Google Cloud Well-Architected Framework: ottimizzazione dei costi. Google Cloud
• Per scoprire come risparmiare denaro di notte o in altri momenti in cui l'utilizzo è inferiore, consulta il tutorial Riduzione dei costi mediante lo scale down dei cluster GKE durante le ore non di punta.
• Per scoprire di più sull'utilizzo delle VM spot, consulta il tutorial Esegui applicazioni web su GKE utilizzando VM spot ottimizzate per i costi.
• Per capire come risparmiare denaro su logging e monitoraggio, consulta Ottimizzare i costi: operazioni cloud.
• Per ridurre i costi in Google Cloud in generale, consulta Informazioni sui principi di ottimizzazione dei costi.
• Per una discussione più ampia sulla scalabilità, vedi Pattern per app scalabili e resilienti.
• Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
• Scopri di più sull'esecuzione di un'applicazione GKE su VM spot con nodi on demand come fallback.