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) e le best practice per l'esecuzione di applicazioni con ottimizzazione dei costi su GKE al fine di sfruttare l'elasticità offerta da Google Cloud. Questo documento presuppone la conoscenza di Kubernetes, Google Cloud, GKE e della scalabilità automatica.

Introduzione

Con la diffusione diffusa di Kubernetes, un numero crescente di aziende e provider 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 in un singolo cluster potrebbero essere in esecuzione applicazioni che appartengono a team, reparti, clienti o ambienti diversi. L'architettura multi-tenancy fornita da Kubernetes consente alle aziende di gestire pochi cluster di grandi dimensioni, anziché molti cluster più piccoli, con vantaggi come un utilizzo appropriato delle risorse, controllo di gestione semplificato e frammentazione ridotta.

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

La base della creazione di applicazioni con ottimizzazione dei costi sta diffondendo la cultura del risparmio tra i team. Oltre a portare 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 una stabilità delle applicazioni e dei costi ridotti, devi impostare o ottimizzare correttamente alcune funzionalità e configurazioni (ad esempio, scalabilità automatica, tipi di macchine e 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, è necessario applicare configurazioni diverse per ridurre ulteriormente i costi. Infine, devi monitorare la spesa e definire misure di salvaguardia per applicare le best practice all'inizio del ciclo di sviluppo.

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

Sfida Azione
Voglio dare un'occhiata ai facili risparmi sui costi su GKE. Seleziona la regione appropriata, registrati per gli sconti per impegno di utilizzo e utilizza i tipi di macchine E2.
Devo conoscere i miei costi di GKE. Osserva i tuoi cluster GKE e cerca suggerimenti e abilita la misurazione dell'utilizzo di GKE
Voglio sfruttare al meglio l'elasticità di GKE per i miei carichi di lavoro esistenti. Consulta Horizontal Pod Autoscaler e Gestore della scalabilità automatica dei cluster e comprendi le best practice per il gestore della scalabilità automatica e il provisioning eccessivo.
Voglio utilizzare i tipi di macchine più efficienti. Scegli il tipo di macchina giusto per il tuo carico di lavoro.
Molti nodi nel mio cluster sono inattivi. Leggi le best practice per il gestore della scalabilità automatica dei cluster.
Devo migliorare i risparmi sui costi dei miei job batch. Leggi le best practice per i carichi di lavoro in batch.
Devo migliorare i risparmi sui costi dei miei carichi di lavoro di gestione. Leggi le best practice per la pubblicazione di carichi di lavoro.
Non so come dimensionare le mie richieste di risorse pod. Utilizza Vertical Pod Autoscaler (VPA), ma presta attenzione alla combinazione delle best practice di Horizontal Pod Autoscaler (HPA) e VVP.
Le mie applicazioni sono instabili durante le attività di scalabilità automatica 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? Diffondere la cultura del risparmio sui costi, valuta la possibilità di utilizzare GKE Enterprise Policy Controller, progetta la tua pipeline CI/CD per applicare pratiche di risparmio sui costi e utilizza le quote delle risorse Kubernetes.
Cos'altro dovrei prendere in considerazione per ridurre ulteriormente i costi del mio ecosistema? Esamina cluster di sviluppo di piccole dimensioni, esamina le strategie di logging e monitoraggio ed esamina il traffico in uscita tra regioni in cluster a livello di regione e multi-zona.

Funzionalità e opzioni di ottimizzazione dei costi di GKE

Le applicazioni Kubernetes con ottimizzazione dei costi si basano sulla scalabilità automatica di GKE. Per bilanciare costi, affidabilità e prestazioni di scalabilità su GKE, devi comprendere come funziona la scalabilità automatica e quali opzioni hai a disposizione. Questa sezione illustra la scalabilità automatica di GKE e altre utili configurazioni con ottimizzazione dei costi, sia per la distribuzione che per i carichi di lavoro in batch.

Ottimizza la scalabilità automatica di GKE

La scalabilità automatica è la strategia utilizzata da GKE per consentire ai clienti di Google Cloud di pagare solo per ciò di cui hanno bisogno, riducendo al minimo il tempo di attività dell'infrastruttura. In altre parole, la scalabilità automatica consente di risparmiare sui costi 1) avviando i carichi di lavoro e l'infrastruttura sottostante 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 dei pod e l'infrastruttura sottostante, composta da un insieme di nodi, deve fornire una capacità di calcolo sufficiente per eseguire i carichi di lavoro.

La scalabilità automatica consente di risparmiare sui costi 1) avviando i carichi di lavoro e l'infrastruttura sottostante prima che la domanda aumenti e 2) arrestandoli quando la domanda diminuisce.

Come mostra il diagramma seguente, questo ambiente ha quattro dimensioni di scalabilità. Il carico di lavoro e l'infrastruttura possono scalare in orizzontale aggiungendo e rimuovendo pod o nodi, e possono scalare 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 le seguenti:

Il seguente diagramma illustra questi scenari.

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

Il resto di questa sezione illustra più nel dettaglio queste funzionalità di scalabilità automatica di GKE e illustra altre utili configurazioni con ottimizzazione dei costi sia per la distribuzione che per i carichi di lavoro in batch.

Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) è concepito per la scalabilità delle 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 le repliche dei pod ed è più adatto ai worker stateless che possono avviarsi rapidamente per reagire ai picchi di utilizzo e arresto controllato per evitare l'instabilità dei carichi di lavoro.

La soglia di utilizzo target HPA ti consente di personalizzare quando attivare automaticamente la scalabilità.

Come mostra l'immagine precedente, l'HPA richiede una soglia di utilizzo target, espressa in percentuale, che consente di personalizzare quando attivare automaticamente la scalabilità. In questo esempio, l'utilizzo target della CPU è del 70%. Ciò significa che il carico di lavoro ha un buffer della CPU del 30% per la gestione delle richieste durante l'avvio delle nuove repliche. Un buffer di dimensioni ridotte impedisce lo scale up anticipato, ma può sovraccaricare l'applicazione durante i picchi. Tuttavia, un buffer di grandi dimensioni provoca sprechi di risorse, con conseguente aumento dei costi. Il target esatto è specifico dell'applicazione e devi considerare la dimensione del buffer come sufficiente per gestire le richieste di due o tre minuti durante un picco. Anche se garantisci che l'applicazione può essere avviata in pochi secondi, questo tempo aggiuntivo è necessario quando il gestore della scalabilità automatica dei cluster aggiunge nuovi nodi al cluster o quando i pod sono limitati per mancanza di risorse.

Di seguito sono riportate le best practice per abilitare HPA nella tua applicazione:

Per ulteriori informazioni, consulta Configurazione di un gestore della scalabilità automatica orizzontale dei pod.

Gestore di scalabilità automatica pod verticale

A differenza di HPA, che aggiunge ed elimina le repliche dei pod per reagire rapidamente ai picchi di utilizzo, Vertical Pod Autoscaler (VPA) osserva i pod nel tempo e trova gradualmente le risorse di CPU e memoria ottimali richieste dai pod. Impostare le 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 potrebbe non riuscire a causa di errori di memoria insufficiente. Se le risorse sono troppo grandi, si verificano sprechi e, di conseguenza, bollette più salate. VPA è progettato per i carichi di lavoro stateless e stateful non gestiti da HPA o quando non conosci le richieste di risorse pod appropriate.

VPA rileva che un pod è costantemente in esecuzione ai suoi limiti e lo ricrea con risorse più grandi.

Come mostrato nell'immagine precedente, VPA rileva che il pod è costantemente in esecuzione ai limiti consentiti e lo ricrea con risorse più grandi. Si verifica anche il contrario quando il pod è costantemente sottoutilizzato e viene attivato lo scale down.

VPA può funzionare in tre diverse modalità:

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

Se prevedi di utilizzare VPA, la best practice è iniziare con la modalità Off per estrarre i suggerimenti VPA. Assicurati che venga eseguito per 24 ore, idealmente una settimana o più, prima di generare i suggerimenti. Quindi, solo quando ti senti fiducioso, valuta la possibilità di passare alla modalità Iniziale o Auto.

Segui queste best practice per abilitare VPA, in modalità Iniziale o Auto, nella tua applicazione:

Se stai prendendo in considerazione l'utilizzo della modalità automatica, assicurati di seguire anche queste pratiche:

  • Assicurati che l'applicazione possa essere riavviata quando ricevi traffico.
  • Aggiungi il budget di interruzione dei pod (PDB) per controllare il numero di pod che possono essere disattivati contemporaneamente.

Per ulteriori informazioni, consulta Configurazione della scalabilità automatica verticale dei pod.

Combinazione di HPA e VPA

Il consiglio ufficiale è di non utilizzare insieme VPA e HPA su CPU o memoria. Tuttavia, puoi combinarli in sicurezza utilizzando la modalità di suggerimento in VPA o le metriche personalizzate in HPA, ad esempio le richieste al secondo. Quando combini VPA e HPA, assicurati che i deployment ricevano traffico sufficiente, ovvero che siano costantemente in esecuzione al di sopra delle minime repliche HPA. In questo modo VPA può comprendere le esigenze delle risorse del pod.

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

Programma di scalabilità automatica del cluster

Il gestore della scalabilità automatica dei cluster ridimensiona automaticamente l'infrastruttura del computer sottostante. CA fornisce nodi per i pod che non devono essere eseguiti nel cluster e rimuove i nodi sottoutilizzati. CA è ottimizzata per il costo dell'infrastruttura. In altre parole, se nel cluster sono presenti due o più tipi di nodi, la CA sceglie quello meno costoso che soddisfa la domanda specificata.

A differenza di HPA e VPA, CA non dipende dalle metriche di carico. Si basa invece sulla pianificazione della simulazione e delle richieste di pod dichiarate. È consigliabile abilitare CA ogni volta che utilizzi HPA o VPA. In questo modo, se i tuoi gestori della scalabilità automatica dei pod stabiliscono che hai bisogno di maggiore capacità, l'infrastruttura sottostante aumenti di conseguenza.

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

Come mostrano questi diagrammi, CA aggiunge e rimuove automaticamente capacità di calcolo per gestire i picchi di traffico e farti risparmiare quando i clienti dormono. Come best practice, è consigliabile definire il budget di interruzione dei pod (PDB) per tutte le applicazioni. Nella fase di scale down della CA, è particolarmente importante quando il PDB controlla il numero di repliche che possono essere rimosse contemporaneamente.

Alcuni pod non possono essere riavviati da nessun gestore della scalabilità automatica quando causano un'interruzione temporanea, 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 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 lo spazio di archiviazione locale e che il gestore della scalabilità automatica può riavviare in sicurezza. Inoltre, valuta la possibilità di eseguire pod di lunga durata che non possono essere riavviati su 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 si è verificata come previsto.

Se i tuoi carichi di lavoro sono resilienti al riavvio involontario dei nodi e a perdite di capacità, puoi risparmiare di più creando un cluster o un pool di nodi con VM prerilasciabili. Affinché la CA funzioni come previsto, le richieste di risorse dei pod devono essere sufficientemente grandi da consentire al pod di funzionare normalmente. Se le richieste di risorse sono troppo piccole, i nodi potrebbero non disporre di risorse sufficienti e i pod potrebbero arrestarsi in modo anomalo o riscontrare problemi durante il runtime.

Di seguito è riportato un riepilogo delle best practice per l'abilitazione del gestore della scalabilità automatica del cluster nel tuo cluster:

  • Utilizza HPA o VPA per scalare automaticamente i carichi di lavoro.
  • Assicurati di seguire le best practice descritte nel gestore della scalabilità automatica dei pod scelto.
  • Dimensiona correttamente l'applicazione impostando richieste e limiti appropriati per le risorse oppure utilizza VPA.
  • Definisci un PDB per le tue applicazioni.
  • Definisci il PDB per i pod di sistema che potrebbero bloccare lo scale down. Ad esempio, kube-dns. Per evitare interruzioni temporanee nel cluster, non impostare il PDB per i pod di sistema che hanno una sola replica (ad esempio metrics-server).
  • Esegui pod e pod di breve durata che possono essere riavviati in pool di nodi separati, in modo che i pod di lunga durata non ne blocchino lo scale down.
  • Evita il provisioning eccessivo configurando i nodi inattivi nel cluster. Per questo motivo, devi conoscere la capacità minima (per molte aziende è durante la notte) e impostare il numero minimo di nodi nei pool di nodi per supportare tale capacità.
  • Se hai bisogno di capacità aggiuntiva per gestire le richieste durante i picchi, utilizza i pod in pausa, di cui abbiamo parlato in Gestione della scalabilità automatica e provisioning eccessivo.

Per saperne di più, consulta Scalabilità automatica di un cluster.

Provisioning automatico dei nodi

Il provisioning automatico dei nodi (NAP) è un meccanismo del gestore della scalabilità automatica dei cluster che aggiunge automaticamente nuovi pool di nodi 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 pool di nodi creati dall'utente. Con il provisioning automatico dei nodi, GKE può creare ed eliminare automaticamente nuovi pool di nodi.

Il provisioning automatico dei nodi tende a ridurre gli sprechi di risorse creando dinamicamente pool di nodi che si adattano meglio ai carichi di lavoro pianificati. Tuttavia, la latenza con scalabilità automatica può essere leggermente superiore quando è necessario creare nuovi pool di nodi. Se i tuoi carichi di lavoro sono resilienti ai nodi che si riavviano inavvertitamente e alle perdite di capacità, puoi ridurre ulteriormente i costi configurando la tolleranza di una VM prerilasciabile nel tuo pod.

Di seguito sono riportate le best practice per abilitare il provisioning automatico dei nodi:

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

Per ulteriori informazioni, consulta Utilizzo del provisioning automatico dei nodi e Funzionalità non supportate.

Gestore della scalabilità automatica e provisioning eccessivo

Per controllare i costi, ti consigliamo vivamente di abilitare il gestore della scalabilità automatica in base alle sezioni precedenti. Nessuna configurazione è adatta a tutti gli scenari possibili, quindi devi ottimizzare le impostazioni del carico di lavoro per assicurarti che i gestori della scalabilità automatica rispondano correttamente all'aumento del traffico.

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

Visualizzazione della differenza nel tempo e dei possibili scenari di scale up.

Quando il cluster dispone di spazio sufficiente per il deployment di nuovi pod, viene attivato uno degli scenari di scale up del carico di lavoro. 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 scale up diminuisce perché non è necessario scaricare un'immagine (scenario 2).

Quando il cluster non dispone di spazio sufficiente per il deployment di nuovi pod, viene attivato uno degli scenari di scale up dell'infrastruttura e del carico di lavoro. Ciò significa che il gestore della scalabilità automatica dei cluster deve eseguire il provisioning di nuovi nodi e avviare il software richiesto prima di affrontare l'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 del cluster deve eseguire il provisioning di nodi e pool di nodi (scenario 2).

Per gli scenari in cui è richiesta una nuova infrastruttura, non comprimere troppo il cluster, in altre parole, devi eseguire l'overprovisioning, ma solo per riservare il buffer necessario per gestire le richieste di picco previste durante gli scale up.

Esistono due strategie principali per questo tipo di overprovisioning:

  • Ottimizza il target di utilizzo 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é 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 prevista in due o tre minuti.

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

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

  • Configurare i pod in pausa. Non è possibile configurare il gestore della scalabilità automatica del cluster in modo che avvii i nodi in anticipo. Puoi invece impostare un target di utilizzo HPA per fornire un buffer per gestire i picchi di carico. Tuttavia, se prevedi burst di grandi dimensioni, impostare un target di utilizzo HPA ridotto potrebbe non essere sufficiente o diventare troppo costoso.

    Una soluzione alternativa a questo problema è usare i pod in pausa. I pod in pausa sono deployment a bassa priorità che riservano solo spazio al cluster. Ogni volta che viene pianificato un pod con priorità elevata, i pod in pausa vengono rimossi e il pod ad alta priorità prende immediatamente il loro posto. I pod in pausa eliminati vengono ripianificati e, se non c'è spazio nel cluster, il gestore della scalabilità automatica del cluster avvia nuovi nodi per adattarli. Come best practice, conviene 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 giusto

Oltre alla scalabilità automatica, esistono altre configurazioni per Kubernetes con ottimizzazione dei costi. Questa sezione illustra la scelta del tipo di macchina corretto.

VM prerilasciabili

Le VM prerilasciabili (PVM) sono istanze VM di Compute Engine che durano al massimo 24 ore e non offrono garanzie di disponibilità. Le VM PVM costano fino all'80% in meno rispetto alle VM standard di Compute Engine, ma ti consigliamo di usarle con cautela sui cluster GKE. Le PVM su GKE sono più adatte per eseguire job batch o a tolleranza di errore che sono meno sensibili alla natura temporanea e non garantita delle PVM. I carichi di lavoro stateful e di gestione non devono utilizzare le PVM, a meno che non prepari il sistema e l'architettura per gestire i vincoli delle PVM.

Qualunque sia il tipo di carico di lavoro, devi prestare attenzione ai seguenti vincoli:

  • Il budget di interruzione dei pod potrebbe non essere rispettato perché i nodi prerilasciabili possono essere arrestati inavvertitamente.
  • Non vi è alcuna garanzia che i pod vengano arrestati automaticamente quando il prerilascio del nodo ignora il periodo di tolleranza dei pod.
  • GKE potrebbe impiegare diversi minuti per rilevare che il nodo è stato prerilasciato e che i pod non sono più in esecuzione, il che ritarda la ripianificazione dei pod in un nuovo nodo.

Per mitigare questi vincoli, puoi eseguire il deployment nel cluster di un progetto Gestione degli eventi di chiusura dei nodi (importante: non è un progetto Google ufficiale) che fornisca un adattatore per tradurre gli eventi di terminazione dei nodi Compute Engine in terminazioni dei pod gestite in modo controllato in Kubernetes. Questo progetto della community non risolve in modo affidabile tutti i vincoli delle PVM quando si può ancora mancare di rispetto ai budget di interruzione dei pod. Di conseguenza, la ripianificazione dei pod può richiedere più tempo.

Infine, le VM non hanno una disponibilità garantita, il che significa che sono in grado di effettuare facilmente stoccaggio in alcune regioni. Per ovviare a questo limite, ti consigliamo di impostare un pool di nodi di backup senza PVM. Il gestore della scalabilità automatica dei cluster dà la precedenza alle VM VM

Per ulteriori informazioni, consulta Esecuzione di VM prerilasciabili su GKE ed Eseguire applicazioni web su GKE utilizzando VM spot con ottimizzazione dei costi.

Tipi di macchine E2

I tipi di macchine E2 (VM E2) sono VM con ottimizzazione dei costi che offrono un risparmio del 31% rispetto ai tipi di macchine N1. Le VM E2 sono adatte per 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 su come si confrontano con altri tipi di macchine Google Cloud, consulta Gestione delle risorse dinamiche orientata alle prestazioni nelle VM E2 e Tipi di macchine.

Seleziona la regione appropriata

Se il costo è un vincolo, il luogo 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 carico di lavoro nell'opzione meno costosa, ma in cui la latenza non influisce sul cliente. Se il tuo carico di lavoro richiede la copia dei dati da una regione all'altra, ad esempio per eseguire un job batch, devi considerare anche il costo dello spostamento di questi dati.

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

Registrati agli sconti per impegno di utilizzo

Se hai intenzione di continuare a utilizzare Google Cloud per alcuni anni, ti consigliamo vivamente di acquistare sconti per impegno di utilizzo in cambio di prezzi notevolmente scontati per l'utilizzo delle VM. Quando firmi un contratto per impegno di utilizzo, acquisti risorse di calcolo a un prezzo scontato (fino al 70% di sconto) in cambio dell'impegno a pagarle per uno o tre anni. Se hai dubbi riguardo a quante risorse impegnarti, controlla il tuo utilizzo minimo di computing, ad esempio durante la notte, e impegna il pagamento per quell'importo.

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

Esamina cluster di sviluppo di piccole dimensioni

Per cluster di sviluppo di piccole dimensioni in cui devi ridurre al minimo i costi, valuta l'utilizzo dei cluster Autopilot. Con i cluster in questa modalità operativa non ti vengono addebitati pod di sistema, i costi del sistema operativo o i carichi di lavoro non pianificati.

Rivedi le strategie di logging e monitoraggio

Se utilizzi Cloud Logging e Cloud Monitoring per offrire osservabilità alle tue applicazioni e alla tua infrastruttura, paghi solo per ciò che utilizzi. Tuttavia, maggiore è il numero di log dell'infrastruttura e delle applicazioni e più a lungo conservi questi log, maggiore sarà il costo dei relativi costi. Allo stesso modo, maggiore è il numero di metriche esterne e personalizzate, maggiori saranno i costi. Rivedi le strategie di logging e monitoraggio in base all'ottimizzazione dei costi per Cloud Logging, Cloud Monitoring e Application Performance Management.

Esamina il traffico in uscita tra regioni in cluster a livello di regione e multi-zona

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

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

Prepara l'ambiente per adattarlo al tipo di carico di lavoro

Le aziende hanno requisiti diversi in termini di costi e disponibilità. I loro carichi di lavoro possono essere suddivisi in carichi di lavoro di gestione, che devono rispondere rapidamente a burst o picchi, e carichi di lavoro in batch, che sono preoccupati per il lavoro finale da svolgere. La distribuzione dei carichi di lavoro richiede una piccola latenza di scale up. I carichi di lavoro batch resistono meglio alla latenza. Le diverse aspettative per questi tipi di carichi di lavoro rendono più flessibile la scelta di metodi diversi.

Carichi di lavoro batch

Poiché i carichi di lavoro batch sono preoccupati per il lavoro finale, consentono un risparmio sui costi su GKE, poiché i carichi di lavoro tollerano generalmente una certa latenza al momento dell'avvio del job. Questa tolleranza dà al gestore della scalabilità automatica del cluster lo spazio per avviare nuovi nodi solo quando i job sono pianificati e per rimuoverli al termine dei job.

La prima pratica consigliata consiste nel separare i carichi di lavoro batch in diversi pool di nodi utilizzando etichette e selettori e incompatibilità e tolleranze. La motivazione è la seguente:

  • Il gestore della scalabilità automatica del cluster può eliminare i nodi vuoti più velocemente se non è necessario riavviare i pod. Al termine dei job batch, il cluster accelera il processo di scale down se il carico di lavoro è in esecuzione su nodi dedicati che ora sono vuoti. Per migliorare ulteriormente la velocità degli scale down, valuta la possibilità di configurare il profilo di ottimizzazione di utilizzo delle CA.
  • Alcuni pod non possono essere riavviati, quindi bloccano definitivamente lo scale down dei nodi. Questi pod, che includono i pod di sistema, devono essere eseguiti su pool di nodi diversi in modo da non influire sullo scale down.

La seconda pratica consigliata è l'utilizzo del provisioning automatico dei nodi per creare automaticamente pool di nodi dedicati per i job con un'incompatibilità o una tolleranza corrispondenti. In questo modo, è possibile separare molti carichi di lavoro diversi senza dover configurare tutti i diversi pool di nodi.

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

Per ulteriori informazioni su come configurare un ambiente che segua queste pratiche, consulta il tutorial Ottimizzazione dell'utilizzo delle risorse in un cluster GKE multi-tenant con il provisioning automatico dei nodi.

Carichi di lavoro di gestione

A differenza dei carichi di lavoro in modalità batch, i carichi di lavoro di gestione devono rispondere il più rapidamente possibile a burst o picchi. Questi aumenti improvvisi del traffico possono derivare da molti fattori, ad esempio da spot pubblicitari televisivi, eventi su larga scala come il Black Friday o ultime notizie. La tua applicazione deve essere preparata per gestirle.

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

  • Applicazioni non ancora pronte per essere eseguite su Kubernetes, ad esempio app con immagini di grandi dimensioni, tempi di avvio lenti o configurazioni Kubernetes non ottimali.
  • Il provisioning delle applicazioni dipende dall'infrastruttura che richiede tempo, ad esempio le GPU.
  • I gestori della scalabilità automatica e il provisioning eccessivo non sono impostati in modo appropriato.

Prepara le applicazioni Kubernetes basate su cloud

Alcune delle best practice riportate 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 i gestori della scalabilità automatica, ti consigliamo vivamente di implementarle.

Comprendi la capacità dell'applicazione

Quando pianifichi la capacità dell'applicazione, scopri quante richieste in parallelo sono in grado di gestire, quanta CPU e memoria richiede e come risponde sotto carico elevato. La maggior parte dei team non conosce queste capacità, quindi ti consigliamo di testare il comportamento dell'applicazione sotto pressione. Prova a isolare una singola replica del pod dell'applicazione con scalabilità automatica disattivata, quindi esegui i test simulando un carico di utilizzo reale. Questo ti aiuta a comprendere la capacità per pod. Consigliamo quindi di configurare il gestore della scalabilità automatica del cluster, le richieste e i limiti delle risorse e HPA o VPA. Poi sottoponi di nuovo l'applicazione, ma con maggiore forza per simulare burst o picchi improvvisi.

Idealmente, per eliminare i problemi di latenza, questi test devono essere eseguiti dalla stessa regione o zona in cui l'applicazione è in esecuzione su Google Cloud. Per questi test, puoi utilizzare lo strumento che preferisci, che si tratti di uno script "fai in casa" o di uno strumento per le prestazioni più avanzato, come Apache Benchmark, JMeter o Locust.

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

Assicurati che la tua applicazione possa crescere sia in verticale che in orizzontale

Assicurati che la tua applicazione possa crescere e ridursi. Ciò significa che puoi scegliere di gestire l'aumento del traffico aggiungendo più CPU e memoria o aggiungendo altre repliche di pod. In questo modo hai la flessibilità di sperimentare ciò che meglio si adatta alla tua applicazione, che si tratti di una diversa configurazione del gestore della scalabilità automatica o di una diversa dimensione dei nodi. Purtroppo, alcune applicazioni sono in thread o limitate da un numero fisso di worker o processi secondari che rendono impossibile questo esperimento senza un refactoring completo della loro architettura.

Imposta richieste e limiti appropriati per le risorse

Comprendendo la capacità della tua applicazione, puoi determinare cosa configurare nelle risorse container. In Kubernetes, le risorse sono definite principalmente 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>.

Quando hai impostato correttamente le richieste di risorse, lo scheduler Kubernetes può utilizzarle per decidere su quale nodo posizionare il pod. Ciò garantisce che i pod vengano posizionati in nodi che possono farli funzionare normalmente, consentendoti di migliorare la stabilità e ridurre lo spreco di risorse. Inoltre, la definizione di limiti delle risorse aiuta ad assicurare che queste applicazioni non utilizzino mai tutta l'infrastruttura sottostante disponibile fornita dai nodi di computing.

Una buona prassi per impostare le risorse del container consiste nell'utilizzare la stessa quantità di memoria per richieste e limiti e un limite di CPU maggiore o illimitato. 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 per il pattern precedente si basa sul funzionamento della gestione delle risorse fuori risorse di Kubernetes. In breve, quando le risorse del computer sono esaurite, i nodi diventano instabili. Per evitare questa situazione, kubelet monitora e previene la fame totale di queste risorse ordinando i pod che consumano molte risorse. Quando la CPU è contesa, questi pod possono essere limitati alle sue richieste. Tuttavia, poiché la memoria è una risorsa incomprimibile, quando la memoria è esaurita, il pod deve essere rimosso. Per evitare che i pod vengano disattivati e di conseguenza destabilizzano l'ambiente, devi impostare la memoria richiesta sul limite di memoria.

Puoi anche utilizzare VPA in modalità suggerimento per determinare l'utilizzo di CPU e memoria per una determinata applicazione. Poiché VPA fornisce questi suggerimenti in base all'utilizzo dell'applicazione, ti consigliamo di abilitarlo in un ambiente di produzione per affrontare 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 definisce già HPA, consulta Mixing HPA and VPA (Combinazione di HPA e VPA).

Assicurati che il container sia il più snello possibile

Quando esegui le applicazioni nei container, è importante seguire alcune pratiche per la loro creazione. Alcune di queste pratiche sono ancora più importanti quando l'applicazione è in esecuzione su Kubernetes, perché l'applicazione può avviarsi e arrestarsi in qualsiasi momento. Questa sezione si concentra principalmente sulle due pratiche seguenti:

  • Usa l'immagine più piccola possibile. Ti consigliamo di avere immagini piccole, poiché ogni volta che il gestore della scalabilità automatica del cluster esegue il provisioning di un nuovo nodo per il tuo cluster, il nodo deve scaricare le immagini che verranno eseguite su quel nodo. 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 della classe, della memorizzazione nella cache e così via. Quando un pod richiede un avvio lungo, le richieste dei tuoi clienti potrebbero non riuscire durante l'avvio dell'applicazione.

Prendi in considerazione queste due pratiche quando progetti il tuo sistema, soprattutto se prevedi burst o picchi. Avere un'immagine piccola e un avvio rapido ti aiuta a ridurre la latenza dello scale up. Di conseguenza, puoi gestire meglio l'aumento del traffico senza preoccuparti troppo dell'instabilità. Queste best practice funzionano meglio insieme alle best practice per la scalabilità automatica descritte in Scalabilità automatica di GKE.

Per saperne di più su come creare container, consulta le best practice per la creazione dei container.

Aggiungi budget di interruzione dei pod alla tua applicazione

Il budget di interruzione dei pod (PDB) limita il numero di pod che possono essere rimossi contemporaneamente a seguito di un'interruzione volontaria. Ciò significa che il budget di interruzione definito viene rispettato in fase di implementazione, upgrade dei nodi e in qualsiasi attività di scalabilità automatica. Tuttavia, questo budget non può essere garantito in caso di eventi involontari, come guasti hardware, panic del kernel o l'eliminazione di una VM per errore.

Se il PDB viene rispettato durante la fase di compattazione del gestore della scalabilità automatica del cluster, è consigliabile definire un budget di interruzione dei pod per ogni applicazione. In questo modo puoi controllare il numero minimo di repliche necessarie per supportare il tuo carico in un dato momento, anche quando la CA sta eseguendo lo scale down del cluster.

Per ulteriori informazioni, consulta la sezione Specificare 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 l'applicazione riceva il traffico solo quando è in esecuzione e pronta ad accettare traffico. GKE utilizza i probe di idoneità per determinare quando aggiungere o rimuovere pod dai bilanciatori del carico. GKE utilizza i 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 procedere con l'avanzamento, ad esempio quando viene rilevato uno stato di deadlock. Il probe di idoneità è utile per comunicare a Kubernetes che l'applicazione non è pronta a ricevere traffico, ad esempio durante il caricamento di dati di grandi dimensioni della cache all'avvio.

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

  • Definisci il probe di idoneità per tutti i container.
  • Se l'applicazione dipende da una cache da caricare 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 predefinita del probe 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 ha risorse disponibili, assicurati che la percentuale di errori non aumenti rispetto a un'implementazione più semplice.
  • Non consentire mai l'accesso ad altri servizi della logica del probe. Se questi servizi non rispondono prontamente, possono compromettere il ciclo di vita del pod.

Per maggiori informazioni, consulta Configurare probe di attività, idoneità e avvio.

Assicurati che le tue applicazioni vengano arrestate secondo le aspettative di Kubernetes

I gestori della scalabilità automatica consentono di rispondere ai picchi avviando 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 per 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 smettere di accettare nuove richieste subito dopo il giorno SIGTERM. L'applicazione non deve arrestarsi immediatamente, ma terminare tutte le richieste in corso di pubblicazione e comunque ascoltare le connessioni in entrata che arrivano dopo l'inizio dell'arresto del pod. Kubernetes potrebbe impiegare un po' di tempo per aggiornare tutti i kube-proxies e i bilanciatori del carico. Se l'applicazione termina prima che queste vengano aggiornate, alcune richieste potrebbero causare errori sul lato client.
  • Se la tua applicazione non segue la pratica precedente, utilizza l'hook preStop. La maggior parte dei programmi non smette di accettare subito le richieste. 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 è eseguire, nell'hook preStop, un sonno di qualche secondo per posticipare SIGTERM. In questo modo Kubernetes ha più tempo per completare il processo di eliminazione dei pod e riduce gli errori di connessione sul lato client.
  • Gestisci SIGTERM per le pulizie. Se l'applicazione deve eseguire la pulizia o ha uno stato in memoria che deve essere mantenuto prima della fine del processo, è il momento di farlo. I vari linguaggi di programmazione hanno modi diversi per rilevare questo segnale, quindi trova quello giusto nella tua lingua.
  • Configura terminationGracePeriodSeconds in base alle esigenze della tua applicazione. Alcune applicazioni richiedono più dei 30 secondi predefiniti. In questo caso, devi specificare terminationGracePeriodSeconds. Valori elevati possono aumentare il tempo necessario per gli upgrade o le implementazioni dei nodi. Valori bassi potrebbero non concedere abbastanza tempo a Kubernetes per il completamento del processo. 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 riuscire nel probe di idoneità quando ricevi un SIGTERM. Questa azione indica direttamente ai bilanciatori del carico di interrompere l'inoltro di nuove richieste al pod di backend. A seconda del percorso tra la configurazione del controllo di integrità e la programmazione degli endpoint, il pod di backend potrebbe essere rimosso dal traffico prima.

Per ulteriori informazioni, consulta Best practice di Kubernetes: terminazione con tolleranza.

Configura NodeLocal DNSCache

Il DNS gestito da GKE viene 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 kube-dns-autoscaler predefinita, 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 kube-dns-autoscaler ConfigMap per aumentare il numero di repliche kube-dns nei loro cluster. Sebbene questa strategia possa funzionare come previsto, aumenta l'utilizzo delle risorse e il costo totale di GKE.

Un'alternativa più scalabile e con ottimizzazione dei costi consiste nel configurare NodeLocal DNSCache nel tuo cluster. NodeLocal DNSCache è un componente aggiuntivo di GKE facoltativo che migliora la latenza della 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 ciascun nodo del cluster.

Per ulteriori informazioni, consulta Configurazione di NodeLocal DNSCache.

Utilizza 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 in modo uniforme il traffico tra i pod utilizzando un modello dei 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 di Google Cloud per il mesh di servizi.

Per via di questi vantaggi, il bilanciamento del carico nativo del container è la soluzione consigliata per il bilanciamento del carico tramite Ingress. Quando si utilizzano i NEG 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 del firewall e altro ancora.

Il bilanciamento del carico nativo del container diventa ancora più importante quando utilizzi il gestore della scalabilità automatica del cluster. Per i bilanciatori del carico non NEG, durante lo scale down, la programmazione del bilanciamento del carico e lo svuotamento della connessione potrebbero non essere completamente completati prima che il gestore della scalabilità automatica del cluster termini le istanze del nodo. Ciò potrebbe interrompere le connessioni in corso che attraversano il nodo anche quando i pod di backend non si trovano 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 di VPC.
  • Se non utilizzi un VPC condiviso,
  • Se non utilizzi il criterio di rete GKE.

Per maggiori informazioni, consulta la documentazione di Ingress su GKE e l'articolo sull'utilizzo del bilanciamento del carico nativo del container.

Valuta la possibilità di utilizzare nuovi tentativi con backoff esponenziale

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

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

Per facilitare questo pattern di nuovi tentativi, molte librerie esistenti implementano la logica di nuovo tentativo esponenziale. Puoi usare 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 i nuovi tentativi per tuo conto.

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

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

In molte imprese di grandi e medie dimensioni, la creazione, la manutenzione e il monitoraggio dei cluster Kubernetes per l'intera azienda sono spesso responsabili di una piattaforma centralizzata e di un team dell'infrastruttura. Ciò rappresenta una forte necessità di avere una responsabilità di utilizzo delle risorse e di garantire che tutti i team seguano i criteri dell'azienda. Questa sezione illustra le opzioni per il monitoraggio e l'applicazione delle pratiche relative ai costi.

Osserva i tuoi cluster GKE e cerca suggerimenti

Puoi verificare l'utilizzo delle risorse in un cluster Kubernetes esaminando container, pod e servizi, nonché le caratteristiche del cluster complessivo. Esistono molti modi per eseguire questa attività, ma l'approccio iniziale che consigliamo è quello di osservare i cluster GKE tramite la dashboard di Monitoring. In questo modo ottieni dati in serie temporali relativi all'utilizzo del tuo cluster, in modo da aggregarli e estenderli a infrastruttura, carichi di lavoro e servizi.

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

  • Nella pagina Cluster GKE della console Google Cloud, osserva la colonna Notifiche. Se in un cluster è presente un elevato spreco di risorse, la UI fornisce un suggerimento tra le informazioni complessive allocate rispetto a quelle richieste.

    Vai all'elenco di cluster GKE

  • Nella pagina Consigli della console Google Cloud, cerca le schede dei suggerimenti Risparmi sui costi.

    Vai all'hub dei suggerimenti

Per maggiori dettagli, consulta Osservazione dei cluster GKE e Guida introduttiva all'hub dei suggerimenti.

Abilita misurazione utilizzo GKE

Per un approccio più flessibile che consenta di visualizzare una suddivisione approssimativa dei costi, prova la misurazione dell'utilizzo di GKE. La misurazione dell'utilizzo di GKE consente di visualizzare i profili di utilizzo dei cluster GKE suddivisi per spazi dei nomi ed etichette. Monitora le informazioni sulle richieste e sul consumo di risorse dei carichi di lavoro del cluster, come CPU, GPU, TPU, memoria, spazio di archiviazione e, facoltativamente, traffico in uscita dalla rete.

La misurazione dell'utilizzo di GKE ti aiuta a comprendere la struttura dei costi complessiva dei tuoi cluster GKE, quale team o applicazione spende di più, quale ambiente o componente ha causato un picco improvviso di utilizzo o costi e quale team sta sprecando il budget. Confrontando le richieste di risorse con l'utilizzo effettivo, puoi comprendere per quali carichi di lavoro è stato eseguito l'underprovisioning o l'overprovisioning.

Puoi sfruttare i modelli predefiniti di Looker Studio o fare un ulteriore passo in avanti e personalizzare le dashboard in base alle esigenze della tua organizzazione. Per ulteriori informazioni sulla misurazione dell'utilizzo di GKE e sui relativi prerequisiti, consulta Informazioni sull'utilizzo delle risorse del cluster.

Comprendere come funziona e monitora il server delle metriche

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

Per l'integrità della scalabilità automatica di GKE, devi avere un server delle metriche integro. Con il deployment di GKE metrics-server, viene installato un nanny del resizer, che fa crescere il container di Metrics Server in verticale 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 deve riavviare il pod metrics-server per applicare le nuove risorse richieste.

Anche se il riavvio avviene rapidamente, la latenza totale affinché i gestori della scalabilità automatica si rendano conto che devono intervenire può essere leggermente aumentata dopo un ridimensionamento metrics-server. Per evitare riavvii frequenti di Metrics Server nei cluster in rapida evoluzione, a partire da GKE 1.15.11-gke.9, la tata supporta i ritardi di ridimensionamento.

Segui queste best practice quando utilizzi Metric Server:

  • Scegli la versione GKE che supporta i ritardi di ridimensionamento di metrics-server. Puoi verificarlo controllando se il file YAML del deployment metrics-server ha la configurazione scale-down-delay nel container metrics-server-nanny.
  • Monitora il deployment di metrics-server. Se il server delle metriche non è attivo, significa che la scalabilità automatica non funziona. Vuoi che i tuoi servizi di monitoraggio principali monitorino il deployment.
  • Segui le best practice descritte in Scalabilità automatica di GKE.

Utilizza le quote delle risorse Kubernetes

Nei cluster multi-tenant, team diversi diventano di solito responsabili del deployment delle applicazioni in spazi dei nomi diversi. Per una piattaforma centralizzata e un gruppo di infrastruttura, è un problema che un team possa utilizzare più risorse del necessario. Esaurire tutte le risorse di calcolo del cluster o addirittura attivare troppi scale up possono aumentare i costi.

Per risolvere questo problema, devi utilizzare le quote delle 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 conteggio degli oggetti. Le quote delle risorse consentono di garantire 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 GKE Enterprise Policy Controller

GKE Enterprise Policy Controller (APC) è un controller di ammissione dinamico di Kubernetes che controlla, controlla 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 i vincoli per molte delle best practice illustrate nella sezione Preparare un'applicazione Kubernetes basata su cloud. In questo modo, i deployment vengono rifiutati se non seguono rigorosamente le tue pratiche Kubernetes. L'applicazione di queste regole consente di evitare picchi imprevisti dei costi e riduce le possibilità di instabilità del carico di lavoro durante la scalabilità automatica.

Per ulteriori informazioni su come applicare in modo forzato e scrivere regole personalizzate, consulta Creazione di vincoli e Scrittura di un modello di vincolo. Se non sei un cliente di GKE Enterprise, puoi prendere in considerazione l'utilizzo di Gatekeeper, il software open source su cui si basa APC.

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

GKE Enterprise Policy Controller consente di evitare il deployment di software non conforme nel cluster GKE. Tuttavia, ti consigliamo di applicare questi vincoli dei criteri all'inizio del ciclo di sviluppo, sia nei controlli pre-commit, nei controlli delle richieste di pull, nei flussi di lavoro di pubblicazione o in qualsiasi passaggio che abbia senso nel tuo ambiente. Questa pratica ti consente di trovare e correggere rapidamente gli errori di configurazione e ti aiuta a capire a cosa devi prestare attenzione creando dei sistemi di protezione.

Valuta anche l'utilizzo di funzioni kpt nella pipeline CI/CD per verificare se i file di configurazione di Kubernetes sono conformi ai vincoli applicati da GKE Enterprise Policy Controller e per stimare l'utilizzo delle risorse o i costi di deployment. In questo modo, puoi arrestare 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 ulteriori informazioni, consulta Utilizzo di Policy Controller in una pipeline CI e per un esempio completo di una piattaforma di distribuzione, consulta CI/CD moderna con GKE Enterprise.

Diffondi la cultura del risparmio sui costi

Molte organizzazioni creano astrazioni e piattaforme per nascondere la complessità dell'infrastruttura. È 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 è raro vedere sviluppatori che non hanno mai usato un cluster Kubernetes.

Le pratiche che consigliamo in questa sezione non implicano che l'esecuzione delle astrazioni non sia ultimata. Al contrario, ti aiutano a visualizzare la spesa su Google Cloud e ad addestrare gli sviluppatori e gli operatori nella tua infrastruttura. Puoi farlo creando incentivi e programmi per l'apprendimento in cui puoi utilizzare lezioni tradizionali o online, gruppi di discussione, peer review, programmazione di abbinamento, gamification di CI/CD e risparmio sui costi e altro ancora. Ad esempio, nel mondo Kubernetes è importante comprendere l'impatto di un'applicazione con immagini a 3 GB, di un probe di idoneità mancante o di un errore di configurazione HPA.

Infine, come mostrato nella ricerca DORA di Google, le funzionalità della cultura sono alcuni dei fattori principali che promuovono prestazioni organizzative migliori, meno rilavorazioni, meno burnout e così via. Lo stesso vale per il risparmio sui costi. Se concedi ai tuoi dipendenti l'accesso alla loro spesa, li allinea meglio agli obiettivi e ai vincoli commerciali.

Riepilogo delle best practice

La seguente tabella 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 il tuo ambiente e applica configurazioni e pratiche ottimizzate per i costi
Cultura

Passaggi successivi