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

Last reviewed 2024-09-11 UTC

Questo documento illustra le funzionalità e le opzioni di Google Kubernetes Engine (GKE), nonché le best practice per eseguire 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

Con l'adozione sempre più diffusa di Kubernetes, un numero crescente di aziende e provider di piattaforme e software as a service (SaaS) utilizzano 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. La multitenancy fornita da Kubernetes consente alle aziende di gestire alcuni cluster di grandi dimensioni anziché più piccoli, con vantaggi quali l'utilizzo appropriato delle risorse, il controllo della gestione semplificato e la frammentazione ridotta.

Nel tempo, alcune di queste aziende con cluster Kubernetes in rapida crescita iniziano a registrare un aumento sproporzionato dei costi. Questo accade perché le aziende tradizionali che adottano soluzioni basate su cloud come Kubernetes non dispongono di sviluppatori e operatori con competenze in materia di cloud. Questa mancanza di idoneità al cloud porta a un'instabilità delle applicazioni durante la scalabilità automatica (ad esempio, volatilità del traffico durante un periodo regolare della giornata), picchi improvvisi o picchi (come spot TV o eventi di picco come Black Friday e Cyber Monday). Nel tentativo di "risolvere" il problema, queste aziende tendono a eseguire un overprovisioning dei cluster come facevano in un ambiente non elastico. L'overprovisioning 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.

L'approccio per ottimizzare i costi delle applicazioni Kubernetes.

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

Per ottenere un costo ridotto e la stabilità dell'applicazione, devi impostare o ottimizzare correttamente alcune funzionalità e configurazioni (ad esempio la scalabilità automatica, i tipi di macchine e la selezione della regione). Un'altra considerazione importante è 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 dei limiti per poter applicare le best practice nelle prime fasi del ciclo di sviluppo.

La seguente tabella riassume le sfide che GKE aiuta a risolvere. Ti invitiamo a leggere l'intero documento, ma questa tabella presenta una mappa di ciò che è trattato.

La sfida Azione
Voglio esaminare i risparmi sui costi su GKE. Seleziona la regione appropriata, abbonati agli sconti per l'utilizzo vincolato e utilizza i tipi di macchine E2.
Ho bisogno di conoscere i miei costi GKE. Osserva i tuoi cluster GKE e tieni d'occhio i consigli e abilita la misurazione dell'utilizzo di GKE.
Voglio sfruttare al meglio l'elasticità di GKE per i miei workload esistenti. Leggi le informazioni su Horizontal Pod Autoscaler e Cluster Autoscaler e comprendi le best practice per Autoscaler e over-provisioning.
Voglio utilizzare i tipi di macchine più efficienti. Scegli il tipo di macchina giusto per il tuo carico di lavoro.
Molti nodi del mio cluster sono inutilizzati. Leggi le best practice per Cluster Autoscaler.
Devo migliorare i risparmi sui costi nei miei job batch. Leggi le best practice per i carichi di lavoro collettivi.
Devo migliorare i risparmi sui costi nei miei workload di pubblicazione. Leggi le best practice per il pubblicamento di workload.
Non so come determinare le dimensioni delle richieste di risorse del pod. Utilizza Vertical Pod Autoscaler (VPA), ma fai attenzione alle best practice per combinare Horizontal Pod Autoscaler (HPA) e VPA.
Le mie applicazioni sono instabili durante le attività di ridimensionamento automatico e manutenzione. Prepara le applicazioni basate su cloud per Kubernetes e scopri come funziona Metrics Server e come monitorarlo.
Come faccio a fare in modo che i miei sviluppatori prestino attenzione all'utilizzo delle risorse delle loro applicazioni? Diffondi la cultura del risparmio, valuta la possibilità di utilizzare GKE Enterprise Policy Controller, crea la pipeline CI/CD per applicare pratiche di risparmio e utilizza le quote delle risorse Kubernetes.
Cosa devo considerare per ridurre ulteriormente i costi dell'ecosistema? Esamina piccoli cluster di sviluppo, esamina le tue strategie di logging e monitoraggio ed esamina il traffico in uscita interregionale nei cluster regionali e multizonali.

Funzionalità e opzioni di ottimizzazione dei costi di GKE

Le applicazioni Kubernetes con ottimizzazione dei costi si basano molto sull'autoscaling 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 illustra l'autoscaling di GKE e altre configurazioni utili con ottimizzazione dei costi sia per i carichi di lavoro di pubblicazione sia per quelli batch.

Ottimizzare la scalabilità automatica di GKE

La scalabilità automatica è la strategia utilizzata da GKE per consentire aiGoogle Cloud clienti di pagare solo per ciò che serve, riducendo al minimo il tempo di attività dell'infrastruttura. In altre parole, la scalabilità automatica consente di risparmiare sui costi perché 1) avvia i workload e la relativa infrastruttura di base prima che la domanda aumenti e 2) li arresta quando la domanda diminuisce.

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

La scalabilità automatica consente di risparmiare sui costi perché 1) avvia i workload e la relativa infrastruttura di base prima dell'aumento della domanda e 2) li arresta quando la domanda diminuisce.

Come mostrato nel 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 possono essere scalati verticalmente aumentando e diminuendo le dimensioni dei pod o dei nodi.

Le quattro dimensioni di scalabilità di un ambiente con ottimizzazione dei costi.

GKE gestisce questi scenari di scalabilità automatica utilizzando funzionalità come quelle riportate di seguito:

Il seguente diagramma illustra questi scenari.

Utilizzo degli scenari HPA, VPA, CA e di provisioning automatico dei nodi.

Il resto di questa sezione illustra queste funzionalità di scalabilità automatica di GKE in modo più dettagliato e illustra altre configurazioni utili con ottimizzazione dei costi sia per i carichi di lavoro di pubblicazione che per quelli batch.

Horizontal Pod Autoscaler

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

La soglia di utilizzo target dell'HPA ti consente di personalizzare il momento in cui attivare automaticamente la scalabilità.

Come mostrato nell'immagine precedente, HPA richiede una soglia di utilizzo target, expressed in percentage, che consente di personalizzare quando attivare automaticamente la scalabilità. In questo esempio, l'utilizzo della CPU target è del 70%. Ciò significa che il tuo carico di lavoro ha un buffer della CPU del 30% per gestire le richieste durante l'avvio delle nuove repliche. Un piccolo buffer impedisce l'aumento troppo rapido delle dimensioni, ma può sovraccaricare l'applicazione durante i picchi. Tuttavia, un buffer di grandi dimensioni causa un spreco di risorse, aumentando i costi. Il target esatto è specifico per l'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 può avviarsi in pochi secondi, questo tempo extra è necessario quando Cluster Autoscaler aggiunge nuovi nodi al cluster o quando i pod vengono limitati per mancanza di risorse.

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

Per ulteriori informazioni, consulta Configurare un Horizontal Pod Autoscaler.

Gestore di scalabilità automatica pod verticale

A differenza di HPA, che aggiunge ed elimina le repliche dei pod per reagire rapidamente agli picchi di utilizzo, il gestore della scalabilità automatica dei pod verticali (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 riuscire a causa di errori di esaurimento della memoria. Se le risorse sono troppo grandi, si verificano sprechi e, quindi, le fatture sono più alte. VPA è pensato per i carichi di lavoro stateless e stateful non gestiti da HPA o quando non conosci le richieste di risorse dei pod appropriate.

La VPA rileva che un pod è in esecuzione costantemente al limite e lo ricrea con risorse più grandi.

Come mostrato nell'immagine precedente, VPA rileva che il pod funziona costantemente al limite e lo ricrea con risorse più grandi. accade anche il contrario quando il pod è costantemente sottoutilizzato: viene attivato uno scale down.

La VPA può funzionare in tre diverse modalità:

  • Off. In questa modalità, nota anche come modalità di consiglio, il VPA non applica alcuna modifica al pod. I consigli vengono calcolati e possono essere esaminati nell'oggetto VPA.
  • Iniziale: la VPA assegna le richieste di risorse solo al momento della creazione del pod e non le modifica mai 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 viene avviato un nuovo pod.

Se prevedi di utilizzare la VPA, la best practice è iniziare con la modalità Off per recuperare i consigli della VPA. Assicurati che sia in esecuzione per 24 ore, idealmente una settimana o più, prima di estrarre i consigli. Solo quando ti senti sicuro, puoi passare alla modalità Iniziale o Automatica.

Segui queste best practice per attivare la VPA in modalità Iniziale o Automatica nella tua applicazione:

Se stai valutando la possibilità di utilizzare la modalità Automatica, assicurati di seguire anche queste best practice:

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

Per ulteriori informazioni, consulta la pagina sulla configurazione della scalabilità automatica del pod verticale.

Combinazione di HPA e VPA

Il consiglio ufficiale è di non combinare VPA e HPA su CPU o memoria. Tuttavia, puoi combinarli in sicurezza quando utilizzi la modalità di consiglio in VPA o le metriche personalizzate in HPA, ad esempio le richieste al secondo. Quando combini VPA con HPA, assicurati che i deployment ricevano traffico sufficiente, ovvero che vengano eseguiti in modo coerente al di sopra delle repliche minime HPA. In questo modo, il VPA può comprendere le esigenze di risorse del tuo pod.

Per ulteriori informazioni sulle limitazioni della scalabilità automatica verticale, consulta Limitazioni della scalabilità automatica dei pod verticali.

Programma di scalabilità automatica del cluster

Cluster Autoscaler (CA) ridimensiona automaticamente l'infrastruttura di calcolo sottostante. La CA fornisce i nodi per i pod che non hanno un luogo in cui essere eseguiti nel cluster e rimuove i nodi sottoutilizzati. La CA è ottimizzata 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 specificata.

A differenza di HPA e VPA, la CA non dipende dalle metriche di carico. Si basa invece sulla simulazione della pianificazione e sulle richieste di pod dichiarate. È buona prassi attivare la CA ogni volta che utilizzi HPA o VPA. Questa pratica garantisce che, se gli autori di scalabilità automatica dei pod rilevano che hai bisogno di più capacità, l'infrastruttura di base aumenti di conseguenza.

La CA aggiunge e rimuove automaticamente la capacità di calcolo per gestire i picchi di traffico.

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

Alcuni pod non possono essere riavviati da nessun gestore della scalabilità automatica quando causano interruzioni temporanee, pertanto 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 lo spazio di archiviazione locale non verranno riavviati. Tuttavia, puoi cambiare questo comportamento definendo PDB per questi pod di sistema e impostando l'annotazione "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" per i pod che utilizzano lo spazio di archiviazione locale e che sono sicuri per il riavvio del gestore della scalabilità automatica. Inoltre, ti consigliamo di eseguire pod a vita lunga che non possono essere riavviati in un distinto pool di nodi, 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 carichi di lavoro sono resilienti ai riavvii involontari dei nodi e alle perdite di capacità, puoi risparmiare di più creando un cluster o un pool di nodi con VM spot. Affinché la CA funzioni come previsto, le richieste di risorse del pod devono essere sufficientemente grandi per il normale funzionamento del pod. Se le richieste di risorse sono troppo ridotte, 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 attivare Cluster Autoscaler nel tuo cluster:

  • Utilizza HPA o VPA per scalare automaticamente i carichi di lavoro.
  • Assicurati di seguire le best practice descritte nell'autoscalabilità dei pod scelto.
  • Scegli le dimensioni appropriate per la tua applicazione impostando richieste e limiti di risorse appropriati o utilizza VPA.
  • Definisci un PDB per le tue applicazioni.
  • Definisci PDB per i pod di sistema che potrebbero bloccare il ridimensionamento verso il basso. 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 distinti, in modo che i pod di lunga durata non blocchino il loro ridimensionamento.
  • Evita il provisioning eccessivo configurando i nodi inattivi nel cluster. Per farlo, devi conoscere la tua capacità minima, che per molte aziende si verifica durante la notte, e impostare il numero minimo di nodi nei pool di nodi per supportare questa capacità.
  • Se hai bisogno di una capacità aggiuntiva per gestire le richieste durante i picchi, utilizza i pod in pausa, discussi in Autoscaler e over-provisioning.

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 pool di nodi oltre a gestire le relative dimensioni per conto dell'utente. Senza il provisioning automatico dei nodi, GKE considera l'avvio di nuovi nodi solo dal set di pool di nodi 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 i pool di nodi più adatti ai workload pianificati. Tuttavia, la latenza della scalabilità automatica può essere leggermente superiore quando è necessario creare nuovi pool di nodi. Se i tuoi carichi di lavoro sono resilienti al riavvio involontario dei nodi e alle perdite di capacità, puoi ridurre ulteriormente i costi configurando la tolleranza delle VM spot nel tuo pod.

Di seguito sono riportate le best practice per abilitare l'autoprovisioning dei nodi:

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

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

Scalabilità automatica e overprovisioning

Per controllare i costi, ti consigliamo vivamente di attivare il ridimensionamento automatico 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 autori di scalabilità automatica rispondano correttamente agli aumenti del traffico.

Tuttavia, come indicato nella sezione Horizontal Pod Autoscaler, gli scale up potrebbero richiedere del tempo a causa del provisioning dell'infrastruttura. Per visualizzare questa differenza nel tempo e possibili scenari di scalabilità, considera la seguente immagine.

Visualizzazione della differenza di tempo e di possibili scenari di scalabilità.

Quando il cluster ha spazio sufficiente per il deployment di nuovi pod, viene attivato uno degli scenari di scalabilità dei workload. Ciò significa che, se un nodo esistente non ha mai eseguito il deployment della tua applicazione, deve scaricare le relative 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 di scalabilità totale diminuisce perché non è richiesto alcun download di immagini (scenario 2).

Quando il cluster non ha spazio sufficiente per il deployment di nuovi pod, viene attivato uno degli scenari di scalabilità 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 alla tua 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 pool di nodi (scenario 2).

Per gli scenari in cui è necessaria una nuova infrastruttura, non spremere troppo il cluster, ovvero devi eseguire il provisioning eccessivo, ma solo per riservare il buffer necessario per gestire le richieste di picco previste durante i ridimensionamenti.

Esistono due strategie principali per questo tipo di overprovisioning:

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

    (1 - buff)/(1 + perc)

    • buff è un buffer di sicurezza che puoi impostare per evitare di raggiungere il 100% della CPU. Questa variabile è utile perché il raggiungimento del 100% della CPU significa che la latenza dell'elaborazione delle richieste è molto più alta del solito.
    • perc è la percentuale di crescita del traffico prevista 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 margine di sicurezza del 10%, la formula sarà la seguente:

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

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

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

Scegli il tipo di macchina più adatto

Oltre all'autoscaling, altre configurazioni possono aiutarti a eseguire applicazioni Kubernetes con ottimizzazione dei costi su GKE. Questa sezione illustra la scelta del tipo di macchina più adatto.

VM spot

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

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

  • Il budget di interruzione dei pod potrebbe non essere rispettato perché le VM spot possono essere chiuse inavvertitamente.
  • Non vi è alcuna garanzia che i pod si arrestino in modo corretto 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 sottoposto a preemption e che i pod non sono più in esecuzione, il che ritarda la riprogrammazione dei pod su un nuovo nodo.

A partire dalla versione 1.20 di GKE, il riavvio dei nodi è abilitato per impostazione predefinita per inviare una notifica ai carichi di lavoro in esecuzione.

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

Per ulteriori informazioni, consulta Esegui carichi di lavoro a tolleranza di errore a costi inferiori con le VM spot, Esegui carichi di lavoro a tolleranza di errore a costi inferiori nei pod spot e Esegui applicazioni web su GKE utilizzando VM spot con ottimizzazione dei costi.

Tipi di macchine E2

I tipi di macchine E2 (VM E2) sono VM ottimizzate per i costi che offrono un risparmio del 31% rispetto ai tipi di macchine N1. Le VM E2 sono adatte a una vasta 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 altriGoogle Cloud tipi di macchine, consulta Gestione dinamica delle risorse in base al rendimento nelle VM E2 e Tipi di macchine.

Seleziona la regione appropriata

Quando il costo è un vincolo, è importante dove esegui i tuoi cluster GKE. Per molti fattori, il costo varia in base alla regione di calcolo. Assicurati quindi di eseguire il tuo carico di lavoro nell'opzione meno costosa, ma dove la latenza non influisce sul cliente. Se il tuo carico di lavoro richiede la copia di dati da una regione all'altra, ad esempio per eseguire un job batch, devi anche prendere in considerazione 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 Compute Engine.

Registrati per usufruire degli sconti per impegno di utilizzo

Se intendi utilizzare 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%) in cambio dell'impegno a pagare queste risorse per uno o tre anni. Se hai dubbi su quante risorse impegnare, esamina il tuo utilizzo minimo dell'elaborazione, ad esempio durante la notte, e impegna il pagamento per quell'importo.

Per ulteriori informazioni sui prezzi per impegno di utilizzo per diversi tipi di macchine, consulta la pagina relativa ai prezzi delle istanze VM.

Esamina piccoli cluster di sviluppo

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

Rivedi le strategie di logging e monitoraggio

Se utilizzi Cloud Logging e Cloud Monitoring per fornire osservabilità delle tue applicazioni e della tua infrastruttura, paghi solo per ciò che utilizzi. Tuttavia, più la tua infrastruttura e le tue applicazioni generano log e più a lungo li conservi, più li paghi. Analogamente, più metriche esterne e personalizzate hai, più alti saranno 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 regionali. Grazie all'elevata disponibilità dei nodi nelle varie zone, i cluster regionali e multizona sono molto adatti per gli ambienti di produzione. Tuttavia, ti viene addebitato il traffico in uscita tra zone. Per gli ambienti di produzione, ti consigliamo di monitorare il carico del traffico tra le zone e di migliorare le API per ridurlo al minimo. Valuta anche la possibilità di utilizzare configurazioni di affinità e anti-affinità tra pod per collocare in co-locazione 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 di loro. Il modo consigliato per monitorare questo traffico è abilitare la misurazione dell'utilizzo di GKE e il relativo agente di traffico in uscita dalla rete, che è disabilitato per impostazione predefinita.

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

Prepara l'ambiente in base al tipo di carico di lavoro

Le aziende hanno requisiti di costo e disponibilità diversi. I loro carichi di lavoro possono essere suddivisi in carichi di lavoro di distribuzione, che devono rispondere rapidamente a picchi o picchi, e carichi di lavoro batch, che riguardano l'eventuale lavoro da svolgere. I carichi di lavoro di pubblicazione richiedono una piccola latenza di scalabilità; 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 diversi metodi di risparmio sui costi.

Carichi di lavoro batch

Poiché i carichi di lavoro batch riguardano il lavoro finale, consentono di risparmiare sui costi su GKE perché i carichi di lavoro sono generalmente tolleranti nei confronti di una certa latenza all'avvio del job. Questa tolleranza offre a Cluster Autoscaler lo spazio per avviare nuovi nodi solo quando i job sono pianificati e per 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 utilizzando contaminazioni e tolleranze. La motivazione è la seguente:

  • Il gestore della scalabilità automatica dei cluster può eliminare più rapidamente i nodi vuoti quando non è necessario riavviare i pod. Al termine dei job batch, il cluster accelera il processo di scalata verso il basso se il carico di lavoro è in esecuzione su nodi dedicati ora vuoti. Per migliorare ulteriormente la velocità dei ridimensionamenti, ti consigliamo di configurare il profilo di ottimizzazione dell'utilizzo di Cloudera.
  • Alcuni pod non possono essere riavviati, quindi bloccano definitivamente lo scale down dei relativi nodi. Questi pod, che includono i pod di sistema, devono essere eseguiti su pool di nodi diversi in modo da non influire sul ridimensionamento verso il basso.

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

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

Erogazione di workload

A differenza dei carichi di lavoro batch, i carichi di lavoro di pubblicazione devono rispondere il più rapidamente possibile a picchi o picchi. Questi improvvisi aumenti del traffico possono essere dovuti a molti fattori, ad esempio spot pubblicitari televisivi, eventi di picco come il Black Friday o notizie di cronaca. La tua applicazione deve essere preparata a gestirle.

I problemi di gestione di questi picchi sono in genere 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 il cui provisioning richiede tempo, come le GPU.
  • I gestori della scalabilità automatica e il provisioning eccessivo non sono impostati correttamente.

Preparare le applicazioni Kubernetes basate su cloud

Alcune delle best practice riportate in questa sezione possono farti risparmiare da sole. Tuttavia, poiché la maggior parte di queste pratiche è pensata per far funzionare la tua applicazione in modo affidabile con gli autoscaler, ti consigliamo vivamente di implementarle.

Informazioni sulla capacità dell'applicazione

Quando pianifichi la capacità dell'applicazione, devi sapere quante richieste simultanee può gestire la tua applicazione, quanta CPU e memoria richiede e come risponde sotto un carico elevato. La maggior parte dei team non conosce queste capacità, quindi 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 quindi di configurare il gestore della scalabilità automatica del cluster, le richieste di risorse e i limiti, nonché HPA o VPA. Sottoponi di nuovo l'applicazione a stress, ma con una maggiore intensità per simulare picchi o 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 scegliere lo strumento che preferisci per questi test, che si tratti di uno script fatto in casa o di uno strumento per le prestazioni 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 l'applicazione possa crescere verticalmente e orizzontalmente

Assicurati che la tua applicazione possa crescere e ridursi. Ciò significa che puoi scegliere di gestire gli aumenti di traffico aggiungendo più CPU e memoria o più repliche di pod. In questo modo, hai la flessibilità di sperimentare ciò che si adatta meglio alla tua applicazione, che si tratti di una configurazione diversa dell'autoscalabilità o di una dimensione diversa dei nodi. Purtroppo, alcune applicazioni sono a thread singolo o limitate da un numero fisso di worker o sottoprocessi che rendono impossibile questo esperimento senza un refactoring completo della loro architettura.

Imposta richieste e limiti delle risorse appropriati

Comprendendo la capacità della tua applicazione, puoi determinare cosa configurare nelle risorse del contenitore. Le risorse in Kubernetes sono definite principalmente come CPU e memoria (RAM). Configura la CPU o la memoria come quantità richiesta per eseguire l'applicazione utilizzando la richiesta spec.containers[].resources.requests.<cpu|memory> e configura il limite utilizzando la richiesta spec.containers[].resources.limits.<cpu|memory>.

Se hai impostato correttamente le richieste di risorse, lo scheduler Kubernetes può utilizzarle per decidere su quale nodo posizionare il pod. In questo modo, i pod vengono collocati in nodi che possono consentirne il normale funzionamento, migliorando la stabilità e riducendo lo spreco di risorse. Inoltre, la definizione di limiti di risorse contribuisce a garantire che queste applicazioni non utilizzino mai tutta l'infrastruttura di base disponibile fornita dai nodi di calcolo.

Una buona prassi per impostare le risorse del container è utilizzare la stessa quantità di memoria per richieste e limiti e un limite della CPU più grande o illimitato. Prendiamo 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 insufficienti di Kubernetes. In breve, quando le risorse del computer sono esaurite, i nodi diventano instabili. Per evitare questa situazione, kubelet monitora e impedisce il blocco totale di queste risorse classificando i pod che richiedono molte risorse. Quando la CPU è in contesa, questi pod possono essere limitati in base alle sue richieste. Tuttavia, poiché la memoria è una risorsa non comprimibile, quando viene esaurita, il pod deve essere smontato. Per evitare che i pod vengano rimossi e, di conseguenza, destabilizzare l'ambiente, devi impostare la memoria richiesta sul limite di memoria.

Puoi anche utilizzare la VPA in modalità di consiglio per determinare l'utilizzo della CPU e della memoria per una determinata applicazione. Poiché la VPA fornisce questi consigli based on your application usage, ti consigliamo di attivarla in un ambiente simile alla produzione per far fronte al traffico reale. Lo stato VPA genera quindi un report con le richieste e i limiti delle risorse suggeriti, che puoi specificare in modo statico nel manifest di deployment. Se la tua applicazione già definisce gli annunci di inventario proprietario, consulta la sezione Combinare annunci di inventario proprietario e annunci di inventario video.

Assicurati che il contenitore sia il più snello possibile

Quando esegui i container su Kubernetes, l'applicazione può essere avviata e interrotta in qualsiasi momento. È quindi importante seguire queste best practice:

  • Devi avere l'immagine più piccola possibile. È buona prassi 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 al suo interno. Più piccola è l'immagine, più velocemente il nodo può scaricarla.

  • Avvia l'applicazione il più rapidamente possibile. L'avvio di alcune applicazioni può richiedere alcuni minuti a causa del caricamento delle classi, della memorizzazione nella cache e così via. Quando un Pod richiede un'avvio lungo, le richieste dei clienti potrebbero non andare a buon fine durante l'avvio della applicazione.

Valuta queste due pratiche durante la progettazione del sistema, soprattutto se prevedi picchi o picchi. Avere un'immagine di piccole dimensioni e un avvio rapido ti consente di ridurre la latenza dei ridimensionamenti. 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 discusse 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 interrotti contemporaneamente da un'interruzione volontaria. Ciò significa che il budget delle interruzioni 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 eliminazione di una VM per errore.

Quando il PDB viene rispettato durante la fase di compattazione del Cluster Autoscaler, è buona prassi 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 tuo carico in qualsiasi momento, anche quando CA riduce il cluster.

Per ulteriori informazioni, consulta Specificare un budget per le interruzioni per la tua applicazione.

Impostare probe di idoneità e attività significativi per l'applicazione

L'impostazione di probe significativi garantisce che la tua applicazione riceva traffico solo quando è attiva e pronta ad accettarlo. GKE utilizza probe di idoneità per determinare quando aggiungere pod ai bilanciatori del carico o rimuoverli. 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 avanzare, ad esempio quando viene rilevato uno stato di deadlock. Il probe di idoneità è utile per comunicare a Kubernetes che la tua applicazione non è pronta a ricevere traffico, ad esempio durante il caricamento di dati della cache di grandi dimensioni all'avvio.

Per garantire il ciclo di vita corretto dell'applicazione durante le attività di scalabilità, è importante procedere nel seguente modo:

  • Definisci il probe di idoneità per tutti i container.
  • Se la tua applicazione dipende dal caricamento di una cache all'avvio, il probe di idoneità deve indicare che è pronto solo dopo il caricamento completo della cache.
  • Se la tua applicazione può iniziare a essere pubblicata immediatamente, un'implementazione di sonda predefinita valida può essere il più semplice possibile, ad esempio un endpoint HTTP che restituisce un codice di stato 200.
  • Se implementi un controllo più avanzato, ad esempio controllando 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 prova di accedere ad altri servizi. Può compromettere il ciclo di vita del pod se questi servizi non rispondono tempestivamente.

Per ulteriori informazioni, consulta Configurare i controlli di attivazione, idoneità e avvio.

Assicurati che le applicazioni si arrestino 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 graduale.

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

  • Non smettere di accettare nuove richieste subito dopo il giorno SIGTERM. L'applicazione non deve interrompersi immediatamente, ma deve completare tutte le richieste in corso e continuare ad ascoltare le connessioni in arrivo che arrivano dopo l'inizio del termine del pod. Potrebbe essere necessario del tempo prima che Kubernetes aggiorni tutti i kube-proxy e i bilanciatori del carico. Se l'applicazione termina prima che questi vengano aggiornati, alcune richieste potrebbero causare errori lato client.
  • Se la tua applicazione non segue la prassi precedente, utilizza il preStop hook. 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 graduale senza modificare l'applicazione. Una strategia comune è eseguire, nell'hook preStop, una sospensione di alcuni secondi per posticipare SIGTERM. In questo modo, Kubernetes ha più tempo per completare il processo di eliminazione del pod e si riducono gli errori di connessione lato client.
  • Gestisci SIGTERM per le operazioni di pulizia. Se la tua applicazione deve eseguire la pulizia o ha uno stato in memoria che deve essere mantenuto prima del termine del processo, è 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. I valori elevati potrebbero aumentare i tempi di upgrade o implementazione dei nodi, ad esempio. I valori bassi potrebbero non consentire tempo sufficiente per completare la procedura di terminazione del pod da parte di Kubernetes. In ogni caso, ti consigliamo di impostare il periodo di interruzione 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 riuscire nel probe di idoneità quando ricevi un SIGTERM. Questa azione indica direttamente ai bilanciatori del carico di interrompere l'inoltro delle nuove richieste al pod di backend. A seconda della concorrenza tra la configurazione del controllo di integrità e la programmazione dell'endpoint, il pod di backend potrebbe essere rimosso dal traffico in precedenza.

Per ulteriori informazioni, consulta Best practice di Kubernetes: terminazione senza problemi.

Configurare 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 richiedono molto DNS, la configurazione predefinita di kube-dns-autoscaler, che regola il numero di repliche di 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 loro cluster. Anche se questa strategia potrebbe funzionare come previsto, aumenta l'utilizzo delle risorse e il costo totale di GKE.

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

Per ulteriori 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 di dati chiamato gruppi di endpoint di rete (NEG). Questo approccio migliora le prestazioni della rete, aumenta la visibilità, abilita funzionalità avanzate di bilanciamento del carico e consente l'utilizzo di Cloud Service Mesh, il piano di controllo del traffico completamente gestito diGoogle Cloudper il mesh di servizi.

Per questi vantaggi, il bilanciamento del carico nativo del container è la soluzione consigliata per il bilanciamento del carico tramite Ingress. Quando le NEG vengono utilizzate con GKE Ingress, il controller Ingress facilita la creazione di tutti gli aspetti del bilanciatore del carico L7. Sono inclusi la creazione dell'indirizzo IP virtuale, le regole di inoltro, i controlli di integrità, le regole del firewall e altro ancora.

Il bilanciamento del carico nativo del container diventa ancora più importante quando utilizzi Cluster Autoscaler. Per i bilanciatori del carico non NEG, durante le riduzioni di scala, la programmazione del bilanciamento del carico e lo svuotamento delle connessioni 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 sono sul nodo.

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

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

Per ulteriori informazioni, consulta la documentazione di Ingress GKE e la sezione Utilizzare il bilanciamento del carico nativo dei contenitori.

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:

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

Per facilitare questo pattern di ripetizione, molte librerie esistenti implementano la logica di ripetizione esponenziale. 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 riprova a livello di proxy, che esegue in modo trasparente le riprove per tuo conto.

È importante pianificare che la tua applicazione supporti i 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 scadere se non pianificata correttamente.

Monitora l'ambiente e applica configurazioni e best practice ottimizzate in termini di costi

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

Osserva i tuoi cluster GKE e tieni d'occhio i suggerimenti

Puoi controllare l'utilizzo delle risorse in un cluster Kubernetes esaminando i contenitori, i pod e i servizi, nonché le caratteristiche del cluster complessivo. Esistono molti modi per eseguire questa operazione, ma l'approccio iniziale che consigliamo è osservare i cluster GKE tramite la dashboard di monitoraggio. In questo modo, puoi ottenere dati sulle serie temporali relative all'utilizzo del cluster, in modo da aggregare e passare da infrastruttura, carichi di lavoro e servizi.

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

  • Nella console Google Cloud, nella pagina Cluster GKE, esamina la colonna Notifiche. Se in un cluster si verifica un elevato spreco di risorse, la UI fornisce un'indicazione delle informazioni allocate e richieste complessivamente.

    Vai all'elenco dei cluster GKE

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

    Vai all'hub dei suggerimenti

Per maggiori dettagli, consulta Monitorare i cluster GKE e Guida introduttiva a Recommendation Hub.

Abilita misurazione utilizzo GKE

Per un approccio più flessibile che ti consenta di visualizzare suddivisioni 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. Monitora le informazioni sulle richieste di risorse e sul consumo di risorse dei carichi di lavoro del cluster, ad esempio CPU, GPU, TPU, memoria, archiviazione e, facoltativamente, uscita di rete.

La misurazione dell'utilizzo di GKE ti aiuta a comprendere la struttura di costo complessiva dei tuoi cluster GKE, quale team o applicazione sta spendendo 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 sotto o sovradimensionati.

Puoi utilizzare i modelli predefiniti di Looker Studio o fare un passo avanti 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.

Informazioni sul funzionamento e sul monitoraggio di Metrics Server

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

Per l'integrità della scalabilità automatica di GKE, devi disporre di un server Metrics in buono stato. Con il deployment di GKE metrics-server, viene installato un nanny per il ridimensionamento, che consente di far crescere il contenitore Metrics Server verticalmente aggiungendo o rimuovendo CPU e memoria in base al numero di nodi del cluster. L'aggiornamento in situ dei pod non è ancora supportato in Kubernetes, per questo motivo il servizio di supervisione deve riavviare il pod metrics-server per applicare le nuove risorse richieste.

Sebbene il riavvio avvenga rapidamente, la latenza totale per consentire ai gestori della scalabilità automatica di capire che devono intervenire può aumentare leggermente dopo un ridimensionamentometrics-server. Per evitare frequenti riavvii di Metrics Server nei cluster in rapida evoluzione, a partire da GKE 1.15.11-gke.9, la funzionalità di monitoraggio dei bambini supporta i ritardi di ridimensionamento.

Segui queste best practice quando utilizzi Metric Server:

  • Scegli la versione GKE che supporta i ritardi nel ridimensionamentometrics-server. Puoi verificarlo controllando se il metrics-server file YAML del deployment contiene la configurazione scale-down-delay nel contenitore metrics-server-nanny.
  • Monitora il deployment di metrics-server. Se Metrics Server non è attivo, significa che la scalabilità automatica non funziona. Vuoi che i servizi di monitoraggio di massima priorità monitorino questo deployment.
  • Segui le best practice descritte in Scalabilità automatica di GKE.

Utilizzare le quote delle risorse Kubernetes

Nei cluster multi-tenant, è comune che diversi team siano responsabili delle applicazioni di cui è stato eseguito il deployment in spazi dei nomi diversi. Per un gruppo di piattaforme e infrastrutture centralizzate, è un problema che un team possa utilizzare più risorse del necessario. Se non fornisci risorse di calcolo a tutti i cluster o se attivi troppi aumenti di scala, i costi possono aumentare.

Per risolvere il problema, devi utilizzare le quote di 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 di oggetti. Le quote delle risorse ti consentono di assicurarti che nessun tenant utilizzi più della quota di risorse del cluster assegnata.

Per ulteriori informazioni, consulta Configurare le quote di memoria e CPU per uno spazio dei nomi.

Valuta la possibilità di utilizzare Policy Controller di GKE Enterprise

Policy Controller di GKE Enterprise è un controller di ammissione dinamico Kubernetes che controlla, verifica e applica la conformità dei cluster ai 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 discusse nella sezione Preparazione dell'applicazione Kubernetes basata su cloud. In questo modo, i deployment vengono rifiutati se non rispettano rigorosamente le tue pratiche Kubernetes. L'applicazione di queste regole consente di evitare picchi di costi imprevisti e riduce le probabilità di instabilità del carico di lavoro durante la scalabilità automatica.

Per ulteriori informazioni su come applicare e scrivere le tue regole, consulta Creare vincoli e Scrivere 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.

Progetta la pipeline CI/CD per applicare pratiche di risparmio sui costi

GKE Enterprise Policy Controller 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 importazione o in qualsiasi passaggio utile 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 guardrail.

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

Per maggiori informazioni, consulta Utilizzare Policy Controller in una pipeline CI. Per un esempio completo di una piattaforma di distribuzione, consulta CI/CD moderno con GKE Enterprise.

Diffondere la cultura del risparmio

Molte organizzazioni creano piattaforme e astrazioni per nasconderti la complessità dell'infrastruttura. Questa è una pratica comune nelle aziende che eseguono la migrazione degli i servizi dalle macchine virtuali a Kubernetes. A volte queste aziende consentono agli sviluppatori di configurare le proprie applicazioni in produzione. Tuttavia, non è raro trovare sviluppatori che non hanno mai utilizzato un cluster Kubernetes.

Le pratiche consigliate in questa sezione non significano che devi smettere di fare astrazione. ma ti aiutano a visualizzare la spesa per Google Cloud e a formare gli sviluppatori e gli operatori sulla infrastruttura. Puoi farlo creando programmi e incentivi per l'apprendimento in cui puoi utilizzare corsi tradizionali o online, gruppi di discussione, revisioni tra pari, programmazione collaborativa, CI/CD e gamification per risparmiare sui costi e altro ancora. Ad esempio, nel mondo di Kubernetes, è importante comprendere l'impatto di un'applicazione di immagini da 3 GB, di un controllo di idoneità mancante o di una configurazione errata dell'HPA.

Infine, come mostrato nella ricerca DORA di Google, le competenze culturali sono alcuni dei fattori principali che migliorano il rendimento dell'organizzazione, riducono le rilavorazioni, il burnout e così via. Il risparmio sui costi non è diverso. Dare ai dipendenti l'accesso alle loro spese li allinea maggiormente agli scopi e ai vincoli dell'attività.

Riepilogo delle best practice

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

Argomento Attività
Funzionalità e opzioni di ottimizzazione dei costi di GKE
Prepara le tue applicazioni Kubernetes cloud-native
Monitora l'ambiente e applica configurazioni e best practice ottimizzate in termini di costi
Cultura

Passaggi successivi