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 crescente adozione di Kubernetes, un numero crescente di aziende e provider di Platform as a Service (PaaS) 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 che appartengono a team, reparti, clienti o ambienti diversi. La multitenancy offerta da Kubernetes consente alle aziende di gestire pochi cluster di grandi dimensioni, anziché più cluster più piccoli, con vantaggi come un utilizzo appropriato delle risorse, un controllo di gestione semplificato e una frammentazione ridotta.

Nel tempo, alcune di queste aziende con cluster Kubernetes in rapida crescita iniziano a registrare un aumento sproporzionato dei costi. Ciò accade perché le aziende tradizionali che adottano soluzioni basate su cloud come Kubernetes non hanno sviluppatori e operatori con esperienza nel cloud. Questa mancanza di idoneità al cloud porta all'instabilità delle applicazioni durante la scalabilità automatica (ad esempio, la volatilità del traffico durante un normale periodo della giornata), burst improvvisi o picchi (come spot pubblicitari in TV o eventi di picco come il Black Friday e il Cyber Monday). Nel tentativo di "risolvere" il problema, queste aziende tendono a eseguire il provisioning eccessivo dei cluster nel modo in cui erano abituati a un ambiente non elastico. L'over-provisioning comporta un'allocazione di CPU e memoria notevolmente maggiore rispetto a quella utilizzata dalle applicazioni per la maggior parte della giornata.

Questo documento fornisce 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 delle applicazioni Kubernetes a fronte dei costi.

Alla base della creazione di applicazioni con ottimizzazione dei costi si sta diffondendo la cultura del risparmio tra i team. Oltre a spostare le discussioni sui costi all'inizio del processo di sviluppo, questo approccio ti costringe a comprendere meglio l'ambiente in cui vengono eseguite le tue applicazioni: in questo contesto, l'ambiente GKE.

Per ottenere costi bassi e stabilità delle applicazioni, 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, devi applicare configurazioni diverse per ridurre ulteriormente i costi. Infine, devi monitorare la spesa e creare misure di protezione in modo da poter applicare le best practice nelle prime fasi del ciclo di sviluppo.

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

Sfida Azione
Voglio vedere i facili risparmi sui costi di GKE. Seleziona la regione appropriata, registrati per ricevere sconti per impegno di utilizzo e utilizza i tipi di macchine E2.
Ho bisogno di capire i costi di GKE. Osserva i tuoi cluster GKE e controlla i suggerimenti e abilita la misurazione dell'utilizzo di GKE
Voglio ottenere il massimo dall'elasticità di GKE per i miei carichi di lavoro esistenti. Leggi le informazioni sul gestore della scalabilità automatica dei pod e sul gestore della scalabilità automatica dei cluster e le best practice per il gestore della scalabilità automatica e il provisioning eccessivo.
Voglio utilizzare i tipi di macchina 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 il risparmio sui costi per i job batch. Leggi le best practice per i carichi di lavoro batch.
Devo migliorare il risparmio sui costi nei miei carichi di lavoro di gestione. Leggi le best practice per la pubblicazione dei carichi di lavoro.
Non so come dimensionare le richieste di risorse pod. Utilizza Vertical Pod Autoscaler (VPA), ma fai attenzione al mixing delle best practice di Horizontal Pod Autoscaler (HPA) e VPA.
Le mie applicazioni sono instabili durante le attività di scalabilità automatica e manutenzione. Preparare le applicazioni basate su cloud per Kubernetes e scoprire come funziona Metrics Server e come monitorarlo.
Come posso fare in modo che i miei sviluppatori prestino attenzione all'utilizzo delle risorse delle loro applicazioni? Diffondi 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 i cluster di sviluppo di piccole dimensioni, esamina le strategie di logging e monitoraggio e esamina il traffico in uscita tra regioni nei 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 in larga misura sulla scalabilità automatica di GKE. Per bilanciare costi, affidabilità e prestazioni di scalabilità su GKE, devi comprendere come funziona la scalabilità automatica e le opzioni a tua disposizione. Questa sezione illustra la scalabilità automatica di GKE e altre configurazioni utili con ottimizzazione dei costi per carichi di lavoro di gestione e 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 l'uptime dell'infrastruttura. In altre parole, la scalabilità automatica consente di risparmiare sui costi 1) facendo avviare i carichi di lavoro e l'infrastruttura sottostante prima dell'aumento della domanda e 2) arrestandoli quando la domanda diminuisce.

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

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

Come illustrato nel seguente diagramma, questo ambiente ha quattro dimensioni di scalabilità. Il carico di lavoro e l'infrastruttura possono scalare orizzontalmente mediante l'aggiunta e la rimozione di pod o nodi e la scalabilità verticale aumentando e diminuendo le dimensioni del pod o del nodo.

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

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

Il seguente diagramma illustra questi scenari.

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

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

Horizontal Pod Autoscaler

L'Horizontal Pod Autoscaler (HPA) è pensato per scalare le applicazioni in esecuzione nei pod in base a metriche che esprimono il carico. Puoi configurare l'utilizzo della CPU o altre metriche personalizzate (ad esempio le richieste al secondo). In breve, HPA aggiunge ed elimina le repliche dei pod ed è la soluzione più adatta per i worker stateless in grado di avviare rapidamente per reagire ai picchi di utilizzo e si arrestano in modo controllato per evitare l'instabilità dei carichi di lavoro.

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

Come mostra l'immagine precedente, 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 mentre sono in corso nuove repliche. Un buffer di piccole dimensioni impedisce lo scale up precoce, ma può sovraccaricare la tua applicazione durante i picchi. Tuttavia, un buffer di grandi dimensioni causa sprechi di risorse, aumentando i costi. Il target esatto è specifico per l'applicazione ed è necessario considerare la dimensione del buffer sufficiente per gestire le richieste per 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 del cluster aggiunge nuovi nodi al cluster o quando i pod vengono limitati per mancanza di risorse.

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

Per maggiori informazioni, consulta Configurazione di 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 ai picchi di utilizzo, il VPA (Vertical Pod Autoscaler) osserva i pod nel tempo e trova gradualmente le risorse di CPU e memoria ottimali richieste dai pod. Impostare le risorse giuste è importante per stabilità ed efficienza in termini di costi. Se le risorse dei pod sono troppo piccole, l'applicazione può essere limitata o potrebbe non riuscire a causa di errori di esaurimento della memoria. Se le risorse a tua disposizione sono eccessive, hai sprechi e, di conseguenza, fatture più elevate. VPA è pensato per carichi di lavoro stateless e stateful non gestiti da HPA o quando non conosci le richieste di risorse pod corrette.

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

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

VPA può funzionare in tre diverse modalità:

  • Off. In questa modalità, nota anche come modalità di suggerimento, il VPA non applica alcuna modifica al pod. I suggerimenti sono 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 seguito.
  • Auto: VPA aggiorna le richieste di CPU e memoria durante la 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 VPA, la best practice prevede di iniziare con la modalità Off per estrarre i suggerimenti relativi ai VPA. Assicurati che sia in esecuzione per 24 ore, idealmente una settimana o più, prima di generare i suggerimenti. Poi, solo quando ti senti a tuo agio, valuta la possibilità di passare alla modalità Iniziale o Automatica.

Segui queste best practice per attivare 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 la tua applicazione possa essere riavviata mentre riceve traffico.
  • Aggiungi un budget di interruzione dei pod (PDB) per controllare il numero di pod che possono essere rimossi contemporaneamente.

Per maggiori informazioni, consulta 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 modo sicuro quando utilizzi la modalità di suggerimento in VPA o metriche personalizzate in HPA, ad esempio le richieste al secondo. Quando combini VPA con HPA, assicurati che i deployment stiano ricevendo traffico sufficiente, ovvero che siano costantemente in esecuzione al di sopra delle repliche minime di HPA. Ciò consente a VPA di comprendere le esigenze di risorse del tuo pod.

Per maggiori 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 (CA) ridimensiona automaticamente l'infrastruttura del computer sottostante. La CA fornisce nodi per i pod che non hanno un luogo in cui eseguire nel cluster e rimuove i nodi sottoutilizzati. la CA è ottimizzata per il costo dell'infrastruttura. In altre parole, se ci sono due o più tipi di nodi nel cluster, la CA sceglie il meno costoso adatto alla domanda specificata.

A differenza di HPA e VPA, la CA non dipende dalle metriche di carico. ma sulla simulazione della pianificazione e sulle richieste di pod dichiarate. La best practice prevede di abilitare la CA ogni volta che utilizzi HPA o VPA. In questo modo, se i gestori della scalabilità automatica dei pod stabiliscono che hai bisogno di più capacità, l'infrastruttura sottostante cresca di conseguenza.

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

Come mostrano questi diagrammi, la CA aggiunge e rimuove automaticamente capacità di calcolo per gestire i picchi di traffico e farti risparmiare denaro quando i tuoi clienti dormono. Una best practice è definire un budget di interruzione dei pod (PDB) per tutte le tue applicazioni. È particolarmente importante nella fase di scale down della CA quando il PDB controlla il numero di repliche che è possibile rimuovere contemporaneamente.

Alcuni pod non possono essere riavviati da un gestore della scalabilità automatica quando causano interruzioni temporanee, perciò 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 definindo 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 che possono essere riavviati dal gestore della scalabilità automatica. Inoltre, valuta la possibilità di eseguire pod di lunga durata che non possono essere riavviati in un pool di nodi separato, in modo che non blocchino lo scale down di altri nodi. Infine, scopri come analizzare gli eventi CA nei log per capire perché una determinata attività di scalabilità non si è verificata come previsto.

Se i tuoi carichi di lavoro sono resilienti ai nodi che si riavviano inavvertitamente e alle 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 pod devono essere abbastanza grandi da consentire il normale funzionamento del pod. Se le richieste di risorse sono troppo piccole, i nodi potrebbero non avere risorse sufficienti e i pod potrebbero arrestarsi in modo anomalo o avere problemi durante il runtime.

Di seguito è riportato un riepilogo delle best practice per abilitare il gestore della scalabilità automatica del cluster nel cluster:

  • Usa 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.
  • Ridimensiona correttamente la tua applicazione impostando richieste e limiti appropriati per le risorse o 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 blocchino lo scale down.
  • Per evitare il provisioning eccessivo, configura i nodi inattivi nel tuo cluster. Per farlo, devi conoscere la tua capacità minima, per molte aziende, di notte e impostare il numero minimo di nodi nei pool di nodi per supportarla.
  • Se hai bisogno di capacità aggiuntiva per gestire le richieste durante i picchi, utilizza la pausa dei pod, descritti in Gestore della scalabilità automatica e provisioning eccessivo.

Per maggiori informazioni, 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 lo spreco di risorse tramite la creazione dinamica dei pool di nodi più adatti ai carichi di lavoro 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 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 dei cluster.
  • Imposta le dimensioni minime e massime delle risorse per evitare che il NAP apporti modifiche significative al cluster quando l'applicazione non riceve traffico.
  • Se utilizzi Horizontal Pod Autoscaler per la gestione dei carichi di lavoro, valuta la possibilità di prenotare un buffer di utilizzo target leggermente più ampio perché in alcuni casi NAP potrebbe aumentare la latenza della scalabilità automatica.

Per maggiori 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 si adatta a tutti gli scenari possibili, quindi devi perfezionare le impostazioni per il tuo carico di lavoro per assicurarti che i gestori della scalabilità automatica rispondano correttamente agli aumenti del traffico.

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

Visualizzazione della differenza temporale e dei possibili scenari di scale up.

Quando il cluster ha 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 dell'applicazione, deve scaricare le relative immagini container prima di avviare il pod (scenario 1). Tuttavia, se lo stesso nodo deve avviare una nuova replica pod della tua applicazione, il tempo di scale up totale diminuisce perché non è richiesto il download di immagini (scenario 2).

Quando il cluster non ha 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 la 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 del cluster deve eseguire il provisioning di nodi e pool di nodi (scenario 2).

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

Esistono due strategie principali per questo tipo di overprovisioning:

  • Ottimizza 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é raggiungere il 100% della CPU significa che la latenza di 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% delle richieste e vuoi evitare di raggiungere il 100% della CPU definendo un buffer di sicurezza del 10%, la formula sarebbe la seguente:

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

  • Configura i pod in pausa. Non è possibile configurare il gestore della scalabilità automatica del cluster per avviare i nodi in anticipo. Puoi invece impostare un target di utilizzo HPA per fornire un buffer e gestire i picchi di carico. Tuttavia, se prevedi burst di grandi dimensioni, l'impostazione di un target di utilizzo HPA di dimensioni ridotte potrebbe non essere sufficiente o potrebbe diventare troppo costosa.

    Una soluzione alternativa a questo problema è utilizzare i pod in pausa. I pod in pausa sono deployment a bassa priorità che hanno solo lo scopo di riservare spazio nel tuo cluster. Ogni volta che viene programmato un pod ad alta priorità, i pod in pausa vengono rimossi e il pod ad alta priorità viene immediatamente rimosso. I pod in pausa rimossi vengono quindi ripianificati e, se nel cluster non è presente spazio, il gestore della scalabilità automatica del cluster avvia nuovi nodi per adattarli. La best practice prevede di avere un solo pod di pausa per nodo. Ad esempio, se utilizzi 4 nodi CPU, configura la richiesta di CPU dei pod di pausa con circa 3200 m.

Scegli il tipo di macchina giusto

Oltre alla scalabilità automatica, altre configurazioni possono aiutarti a eseguire applicazioni Kubernetes con ottimizzazione dei costi su GKE. Questa sezione 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 PVM sono fino all'80% più economiche rispetto alle VM standard di Compute Engine, ma ti consigliamo di utilizzarle con attenzione sui cluster GKE. Le PVM su GKE sono più adatte per l'esecuzione di job batch o a tolleranza di errore 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 per l'interruzione dei pod potrebbe non essere rispettato perché i nodi prerilasciabili possono arrestarsi inavvertitamente.
  • Non c'è alcuna garanzia che i tuoi pod verranno arrestati automaticamente una volta che il prerilascio dei nodi 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. Questo ritarda la riprogrammazione dei pod in un nuovo nodo.

Per limitare questi vincoli, puoi eseguire il deployment nel tuo cluster di un progetto gestore degli eventi di terminazione dei nodi della community (importante: non è un progetto Google ufficiale) che fornisce un adattatore per tradurre gli eventi di terminazione dei nodi Compute Engine in terminazioni sicure dei pod in Kubernetes. Questo progetto della community non risolve in modo affidabile tutti i vincoli delle PVM una volta che i budget di interruzione dei pod possono ancora non essere rispettati. Di conseguenza, la riprogrammazione dei pod può richiedere un po' più di tempo.

Infine, le VMP non hanno disponibilità garantita, ovvero possono effettuare i pagamenti in modo semplice in alcune regioni. Per superare questo limite, ti consigliamo di impostare un pool di nodi di backup senza PVM. Il gestore della scalabilità automatica del cluster dà la preferenza alle PVM perché è ottimizzato per i costi dell'infrastruttura.

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

Tipi di macchine E2

I tipi di macchina 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 a un'ampia gamma di carichi di lavoro, tra cui server web, microservizi, applicazioni business-critical, database di piccole e medie dimensioni e ambienti di sviluppo.

Per saperne di più sulle VM E2 e sulle loro differenze con altri tipi di macchine Google Cloud, consulta Gestione dinamica delle risorse basata sulle 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 con l'opzione meno costosa, ma in cui la latenza non influisce sul cliente. Se il carico di lavoro richiede la copia dei dati da una regione all'altra, ad esempio per eseguire un job batch, devi anche valutare 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 per usufruire di sconti per impegno di utilizzo

Se intendi continuare a utilizzare Google Cloud per qualche anno, 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 per impegno di utilizzo, acquisti le risorse di computing a un prezzo scontato (fino al 70% di sconto) in cambio dell'impegno a pagare per queste risorse per uno o tre anni. Se hai dubbi sulla quantità di risorse da impegnare, controlla l'utilizzo minimo del computing, ad esempio di notte, ed esegui il pagamento per l'importo in questione.

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

Esamina cluster di sviluppo di piccole dimensioni

Per i 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à di funzionamento, non ti viene addebitato alcun costo per pod di sistema, costi del sistema operativo o carichi di lavoro non pianificati.

Esamina le strategie di logging e monitoraggio

Se utilizzi Cloud Logging e Cloud Monitoring per garantire l'osservabilità delle tue applicazioni e della tua infrastruttura, paghi solo per ciò che utilizzi. Tuttavia, più l'infrastruttura e le applicazioni registrano e più a lungo vengono conservati questi log, più paghi per queste operazioni. Analogamente, più metriche esterne e personalizzate hai, maggiori sono i costi. Rivedi le tue strategie di logging e monitoraggio consultando la sezione Ottimizzazione dei costi per Cloud Logging, Cloud Monitoring e Application Performance Management.

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

I tipi di cluster GKE disponibili sono a zona singola, multi-zona e a livello di regione. Data l'alta disponibilità dei nodi nelle zone, i cluster a livello di regione e multi-zona sono adatti per gli ambienti di produzione. Tuttavia, gli addebiti vengono addebitati in base al traffico in uscita tra le 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. Inoltre, valuta la possibilità di utilizzare configurazioni di affinità e anti-affinità tra i pod per collocare i pod dipendenti di servizi diversi negli stessi nodi o nella stessa zona di disponibilità, in modo da ridurre al minimo i costi e la latenza di rete tra i due. Il modo suggerito per monitorare questo traffico è abilitare la misurazione dell'utilizzo di GKE e il relativo agente in uscita dalla rete, che è disabilitato per impostazione predefinita.

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

Prepara l'ambiente in modo che si adatti al tipo di carico di lavoro

Le aziende hanno requisiti diversi di costo 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 in carichi di lavoro batch, che riguardano il lavoro finale. I carichi di lavoro in uso richiedono una latenza ridotta in termini di scale up, mentre i carichi di lavoro batch sono più tolleranti alla latenza. Le diverse aspettative per questi tipi di carichi di lavoro rendono più flessibile la scelta di metodi diversi per risparmiare.

Carichi di lavoro batch

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

La prima prassi consigliata è 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, puoi configurare il profilo di ottimizzazione di utilizzo della CA.
  • Alcuni pod non possono essere riavviati, pertanto bloccano definitivamente lo scale down dei propri 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 consiste nell'utilizzare il provisioning automatico dei nodi per creare automaticamente pool di nodi dedicati per i job con un'incompatibilità o una tolleranza corrispondente. In questo modo, puoi separare molti carichi di lavoro diversi senza dover configurare tutti questi pool di nodi.

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

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

Carichi di lavoro per la gestione

A differenza dei carichi di lavoro batch, quelli di gestione devono rispondere il più rapidamente possibile a burst o picchi. Questi improvvisi aumenti del traffico possono derivare da molti fattori, ad esempio pubblicità in TV, eventi di picco su scala come il Black Friday o ultime notizie. La richiesta di partecipazione deve essere preparata per la gestione.

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

  • Le applicazioni non sono pronte per l'esecuzione su Kubernetes, ad esempio app con immagini di grandi dimensioni, tempi di avvio lenti o configurazioni Kubernetes non ottimali.
  • Le applicazioni dipendono dall'infrastruttura che richiede tempo per il provisioning, come le GPU.
  • I gestori della scalabilità automatica e il provisioning eccessivo non devono essere impostati in modo appropriato.

Prepara le applicazioni Kubernetes basate su cloud

Alcune delle best practice di questa sezione consentono di risparmiare denaro in autonomia. Tuttavia, poiché la maggior parte di queste pratiche ha lo scopo di far funzionare l'applicazione in modo affidabile con i gestori della scalabilità automatica, ti consigliamo vivamente di implementarle.

Comprendi la capacità dell'applicazione

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

Idealmente, per eliminare 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 più avanzato per il rendimento, 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 in verticale e in orizzontale

Assicurati che l'applicazione possa crescere e ridursi. Ciò significa che puoi scegliere di gestire gli aumenti del traffico aggiungendo più CPU e memoria o aggiungendo più repliche dei pod. Questo ti offre la flessibilità di sperimentare ciò che si adatta meglio alla tua applicazione, che si tratti di una configurazione di scalabilità automatica diversa o di una dimensione del nodo diversa. Sfortunatamente, alcune applicazioni sono organizzate in thread o sono limitate da un numero fisso di worker o sottoprocessi che rendono impossibile questo esperimento senza un refactoring completo della loro architettura.

Imposta limiti e richieste appropriati per le risorse

Se conosci la capacità dell'applicazione, puoi determinare cosa configurare nelle risorse dei container. Le risorse in Kubernetes sono principalmente definite come CPU e memoria (RAM). Per configurare la CPU o la memoria come quantità necessaria per eseguire l'applicazione utilizzando la richiesta spec.containers[].resources.requests.<cpu|memory>, configuri il limite utilizzando la richiesta spec.containers[].resources.limits.<cpu|memory>.

Dopo aver 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 inseriti in nodi che possono farli funzionare normalmente, in modo da migliorare la stabilità e ridurre lo spreco di risorse. Inoltre, la definizione dei limiti delle risorse aiuta a garantire che queste applicazioni non utilizzino mai tutta l'infrastruttura sottostante disponibile fornita dai nodi di computing.

Una buona norma 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. 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 del pattern precedente si basa sul funzionamento della gestione out-of-resource di Kubernetes. In breve, quando le risorse del computer sono esaurite, i nodi diventano instabili. Per evitare questa situazione, kubelet monitora e impedisce il totale inutili di queste risorse classificando i pod che consumano molte risorse. Quando la CPU è limitata, questi pod possono essere limitati alle richieste. Tuttavia, poiché la memoria è una risorsa incomprimibile, quando la memoria è esaurita, il pod deve essere rimosso. Per evitare la rimozione dei pod e, di conseguenza, la destabilizzazione dell'ambiente, devi impostare la memoria richiesta sul limite di memoria.

Puoi anche utilizzare VPA in modalità di suggerimento per determinare l'utilizzo di CPU e memoria per una determinata applicazione. Poiché VPA fornisce suggerimenti di questo tipo in base all'utilizzo dell'applicazione, ti consigliamo di abilitarlo in un ambiente di produzione per gestire il traffico reale. Lo stato VPA genera quindi un report con le richieste e i limiti di risorse suggeriti, che puoi specificare in modo statico nel manifest del deployment. Se la tua applicazione definisce già l'HPA, consulta Combinazione di HPA e VPA.

Assicurati che il contenitore sia il più snello possibile

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

  • Utilizza l'immagine più piccola possibile. La best practice prevede immagini di piccole dimensioni perché ogni volta che il gestore della scalabilità automatica del cluster esegue il provisioning di un nuovo nodo per il cluster, quest'ultimo deve scaricare le immagini che verranno eseguite nel nodo. Più piccola è l'immagine, più velocemente il nodo potrà scaricarla.

  • Avvia l'applicazione il più velocemente possibile. L'avvio di alcune applicazioni può richiedere minuti a causa del caricamento della classe, della memorizzazione nella cache e così via. Quando un pod richiede un avvio lungo, le richieste dei clienti potrebbero non riuscire durante l'avvio dell'applicazione.

Considera queste due pratiche durante la progettazione del sistema, soprattutto se prevedi burst o picchi. Avere un'immagine di piccole dimensioni e un avvio veloce ti aiuta a ridurre la latenza degli scale up. Di conseguenza, è possibile gestire meglio gli aumenti del traffico senza preoccuparsi troppo dell'instabilità. Queste best practice funzionano meglio con le best practice per la scalabilità automatica descritte in Scalabilità automatica di GKE.

Per saperne di più su come creare i 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 da un' interruzione volontaria. Ciò significa che il budget per l'interruzione definito viene rispettato durante le implementazioni, gli upgrade dei nodi e in qualsiasi attività di scalabilità automatica. Tuttavia, questo budget non può essere garantito in caso di guasti involontari, ad esempio guasti hardware, kernel panic o eliminazione di una VM per errore.

Se il PDB viene rispettato durante la fase di compattazione del gestore della scalabilità automatica del cluster, una best practice prevede la definizione di un budget di interruzione dei pod per ogni applicazione. In questo modo puoi controllare il numero minimo di repliche necessario per supportare il tuo carico in qualsiasi momento, anche quando la CA sta effettuando lo scale down del tuo cluster.

Per maggiori informazioni, consulta Specificare un budget di interruzione per la tua applicazione.

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

L'impostazione di probe significativi garantisce che l'applicazione riceva 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 progredire, ad esempio quando viene rilevato uno stato di deadlock. Il probe di idoneità è utile per indicare a Kubernetes che l'applicazione non è pronta a ricevere traffico, ad esempio durante il caricamento di dati memorizzati nella cache di grandi dimensioni all'avvio.

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

  • 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 dichiarare che è pronta solo dopo che la cache è stata completamente caricata.
  • Se la tua applicazione può iniziare a essere gestita immediatamente, una buona implementazione del probe predefinito può essere il più semplice possibile, ad esempio un endpoint HTTP che restituisce un codice di stato 200.
  • Se implementi un probe più avanzato, ad esempio controlli che il pool di connessioni abbia risorse disponibili, assicurati che la percentuale di errori non aumenta rispetto a un'implementazione più semplice.
  • Non consentire mai a un probe di accedere ad altri servizi. Può compromettere il ciclo di vita del pod se questi servizi non rispondono prontamente.

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

Assicurati che le tue applicazioni vengano arrestate in base alle aspettative di Kubernetes

I gestori della scalabilità automatica ti aiutano a 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 uno arresto controllato.

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

  • Non smettere di accettare nuove richieste subito dopo il giorno SIGTERM. L'applicazione non deve interrompersi immediatamente, ma completare tutte le richieste in fase di elaborazione e continuare ad ascoltare le connessioni in entrata che arrivano dopo l'inizio della terminazione del pod. Kubernetes potrebbe impiegare un po' di tempo per aggiornare tutti i kube-proxies e i bilanciatori del carico. Se la tua applicazione viene terminata prima dell'aggiornamento, alcune richieste potrebbero causare errori sul lato client.
  • Se la tua applicazione non rispetta la procedura precedente, utilizza l'hook preStop. La maggior parte dei programmi non smette di accettare richieste immediatamente. Tuttavia, se utilizzi codice di terze parti o gestisci un sistema su cui non hai il controllo, ad esempio nginx, l'hook preStop è una buona opzione per attivare un arresto controllato senza modificare l'applicazione. Una strategia comune è eseguire, nell'hook preStop, un sonno di pochi secondi 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.
  • Gestire SIGTERM per le operazioni di pulizia. Se la tua applicazione deve eseguire la pulizia o ha uno stato in memoria che deve essere mantenuto come persistente prima della fine del processo, ora è il momento di farlo. I diversi linguaggi di programmazione possono 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 potrebbero ad esempio aumentare il tempo per gli upgrade o le implementazioni dei nodi. Valori bassi potrebbero non concedere a Kubernetes tempo sufficiente per completare il processo di terminazione. In ogni caso, ti consigliamo di impostare il periodo di terminazione dell'applicazione su un periodo inferiore a 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 eseguire il 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 della corsa tra la configurazione del controllo di integrità e la programmazione degli endpoint, il pod di backend potrebbe essere rimosso dal traffico in precedenza.

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

Configura NodeLocal DNSCache

Il DNS gestito da GKE è implementato da kube-dns, un componente aggiuntivo di cui è stato eseguito il deployment in tutti i cluster GKE. Quando esegui applicazioni che necessitano di 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 andare in timeout. Per ridurre questo problema, le aziende sono abituate a ottimizzare kube-dns-autoscaler ConfigMap per aumentare il numero di repliche kube-dns nei propri cluster. Anche se questa strategia potrebbe funzionare come previsto, aumenta l'utilizzo delle risorse e il costo totale di GKE.

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

Per maggiori 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 nei pod utilizzando un modello dei dati chiamato gruppi di endpoint di rete (NEG). Questo approccio migliora le prestazioni della rete, aumenta la visibilità, consente funzionalità avanzate di bilanciamento del carico e consente l'utilizzo di Traffic Director, il piano di controllo del traffico completamente gestito di Google Cloud per 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 usano i NEG con GKE Ingress, il controller Ingress facilita la creazione di tutti gli aspetti del bilanciatore del carico L7. Ciò include la creazione di indirizzo IP virtuale, regole di forwarding, controlli di integrità, regole firewall e altro ancora.

Il bilanciamento del carico nativo del container diventa ancora più importante quando si utilizza il gestore della scalabilità automatica dei 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 completati completamente prima che il gestore della scalabilità automatica del cluster termini le istanze dei nodi. Ciò potrebbe interrompere le connessioni in corso che passano attraverso il nodo, anche quando i pod di backend non si trovano sul nodo.

Il bilanciamento del carico nativo del container è 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 successivi.
  • Se utilizzi cluster nativi di VPC.
  • Se non utilizzi un VPC condiviso.
  • Se non utilizzi il criterio di rete GKE.

Per ulteriori informazioni, consulta la documentazione di GKE in entrata e l'utilizzo del bilanciamento del carico nativo del container.

Considera l'utilizzo di 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 limitarli richiamando nuovamente il servizio dopo un ritardo. Tuttavia, per evitare di sovraccaricare il servizio di destinazione con le richieste, è importante eseguire queste chiamate utilizzando un backoff esponenziale.

Per facilitare questo pattern di ripetizione, molte librerie esistenti implementano la logica di ripetizione esponenziale. Puoi usare la libreria che preferisci o scrivere il tuo codice. Se usi Istio o Anthos Service Mesh (ASM), puoi optare per il meccanismo di riprova a livello di proxy, che esegue i nuovi tentativi in modo trasparente per tuo conto.

È importante pianificare l'applicazione in modo da supportare 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 scadere se non pianificata correttamente.

Monitora il tuo ambiente e applica configurazioni e pratiche con ottimizzazione dei costi

In molte aziende di medie e grandi dimensioni, un team centralizzato per la piattaforma e l'infrastruttura è spesso responsabile della creazione, della manutenzione e del monitoraggio dei cluster Kubernetes per l'intera azienda. Ciò rappresenta una grande esigenza di avere la responsabilità sull'utilizzo delle risorse e di assicurarsi che tutti i team rispettino le norme dell'azienda. Questa sezione illustra le opzioni disponibili per il monitoraggio e l'applicazione delle pratiche relative ai costi.

Osserva i tuoi cluster GKE e controlla i suggerimenti

Puoi controllare 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 è osservare i cluster GKE tramite la dashboard di monitoraggio. In questo modo puoi ottenere dati in serie temporali sull'utilizzo del cluster, in modo da aggregare e suddividere l'infrastruttura, i carichi di lavoro e i servizi.

Sebbene questo sia un buon punto di partenza, Google Cloud offre altre opzioni, ad esempio:

  • Nella pagina Cluster GKE della console Google Cloud, controlla la colonna Notifiche. Se in un cluster è presente un elevato spreco di risorse, l'interfaccia utente fornisce un suggerimento delle informazioni allocato in generale rispetto a quelle richieste.

    Vai all'elenco dei cluster GKE

  • Nella pagina Consigli della console Google Cloud, cerca le schede dei suggerimenti Risparmio 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 ti consenta di visualizzare riduzioni dei costi approssimative, 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 di risorse e sul consumo di risorse dei carichi di lavoro del cluster, ad esempio CPU, GPU, TPU, memoria, spazio di archiviazione e, facoltativamente, traffico di rete in uscita.

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

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

Comprendi il funzionamento del server delle metriche e monitoralo

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 Server di Kubernetes. HPA e VPA usano 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 resizer nanny, 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 la tata deve riavviare il pod metrics-server per applicare le nuove risorse richieste.

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

Segui queste best practice quando utilizzi il server delle metriche:

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

Usa le quote delle risorse Kubernetes

Nei cluster multi-tenant, team diversi di solito diventano responsabili delle applicazioni sottoposte a deployment in spazi dei nomi diversi. Per un gruppo di piattaforma e infrastruttura centralizzati, si teme che un team possa utilizzare più risorse del necessario. L'eliminazione di tutte le risorse di calcolo del cluster o l'attivazione di un numero eccessivo di scale up può comportare un aumento dei 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 calcolo (CPU e memoria) e risorse di archiviazione o in termini di conteggio degli oggetti. Le quote delle risorse consentono di assicurarti che nessun tenant utilizzi una quota di risorse del cluster superiore a quella assegnata.

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

Valuta l'utilizzo di GKE Enterprise Policy Controller

GKE Enterprise Policy Controller (APC) è un controller di ammissione dinamico Kubernetes che verifica, controlla e applica la conformità dei cluster ai criteri relativi a sicurezza, normative o regole aziendali arbitrarie. Policy Controller utilizza vincoli per applicare la conformità dei cluster. Ad esempio, puoi installare i vincoli del cluster per molte delle best practice descritte nella sezione Preparazione dell'applicazione Kubernetes basata su cloud. In questo modo, i deployment vengono rifiutati se non rispettano rigorosamente le pratiche Kubernetes. L'applicazione di queste regole consente di evitare picchi di costo imprevisti e di ridurre le probabilità di instabilità dei carichi di lavoro durante la scalabilità automatica.

Per ulteriori informazioni su come applicare e scrivere regole personalizzate, consulta Creazione di vincoli e Scrittura di un modello di vincolo. Se non sei un cliente GKE Enterprise, puoi considerare di utilizzare 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 ti aiuta a evitare il deployment di software non conforme nel tuo cluster GKE. Tuttavia, ti consigliamo di applicare questi vincoli ai criteri nelle prime fasi del ciclo di sviluppo, che si tratti di controlli pre-commit, controlli delle richieste di pull, flussi di lavoro di distribuzione o qualsiasi passaggio che abbia senso nel tuo ambiente. Questa pratica ti consente di trovare e correggere rapidamente gli errori di configurazione e di capire a cosa prestare attenzione creando sistemi di protezione.

Valuta inoltre la possibilità di utilizzare le funzioni kpt nella pipeline CI/CD per verificare se i file di configurazione di Kubernetes rispettano i 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 maggiori informazioni, consulta Utilizzo di Policy Controller in una pipeline CI e, per un esempio completo di una piattaforma di distribuzione, consulta CI/CD moderni con GKE Enterprise.

Diffondi la cultura del risparmio sui costi

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

Le pratiche consigliate in questa sezione non significano che devi smettere del tutto di fare astrazioni. Ti aiutano invece a visualizzare la tua spesa su Google Cloud e a formare sviluppatori e operatori sulla tua infrastruttura. Puoi farlo creando incentivi e programmi per l'apprendimento in cui puoi utilizzare corsi tradizionali o online, gruppi di discussione, revisioni dei compagni, programmazione di abbinamenti, CI/CD, gamification a basso costo e altro ancora. Ad esempio, nel mondo Kubernetes, è importante comprendere l'impatto di un'applicazione immagine da 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à culturali sono tra i principali fattori in grado di migliorare le prestazioni dell'organizzazione, ridurre le rilavorazioni, il burnout e così via. Il risparmio sui costi non è diverso. Concedere ai dipendenti l'accesso alle spese li allinea maggiormente agli scopi e ai vincoli aziendali.

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 il tuo ambiente e applica configurazioni e pratiche con ottimizzazione dei costi
Cultura

Passaggi successivi