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

Last reviewed 2024-09-11 UTC

Questo documento illustra le funzionalità e le opzioni di Google Kubernetes Engine (GKE), nonché le best practice per l'esecuzione di applicazioni con ottimizzazione dei costi su GKE per sfruttare l'elasticità offerta da Google Cloud. In questo documento si presuppone che tu abbia familiarità con Kubernetes, Google Cloud, GKE e la scalabilità automatica.

Introduzione

Con l'adozione sempre più diffusa di Kubernetes, un numero crescente di aziende e provider di piattaforme e software as a service (PaaS e SaaS) utilizzano cluster Kubernetes multi-tenant per i propri carichi di lavoro. Ciò significa che un singolo cluster potrebbe eseguire applicazioni appartenenti a team, reparti, clienti o ambienti diversi. L'architettura multi-tenancy fornita da Kubernetes consente alle aziende di pochi cluster di grandi dimensioni, invece di più cluster più piccoli, con vantaggi come un utilizzo appropriato delle risorse, un controllo di gestione semplificato e frammentazione del lavoro.

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

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 sui costi tra i team. Oltre a trasferire le discussioni sui costi l'inizio del processo di sviluppo, questo approccio ti costringe a migliorare comprendere l'ambiente in cui sono in esecuzione le tue applicazioni, contesto, l'ambiente GKE.

Per ottenere un costo ridotto e la stabilità dell'applicazione, devi impostare o ottimizzare correttamente alcune funzionalità e configurazioni (ad esempio la scalabilità automatica, i tipi di macchine e la selezione della regione). Un'altra considerazione importante è che carico di lavoro perché, a seconda del tipo di carico di lavoro e devi applicare configurazioni diverse per ridurre ulteriormente a tuo carico. Infine, devi monitorare la spesa e creare delle barriere in modo che poter applicare le best practice all'inizio del ciclo di sviluppo.

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

Sfida Azione
Voglio esaminare i risparmi sui costi su GKE. Seleziona l'area appropriata, registrarsi per un impegno di utilizzo gli sconti e utilizza la macchina E2 tipi.
Ho bisogno di conoscere i miei costi GKE. Osserva le tue GKE cluster e verifica i suggerimenti e abilita l'utilizzo di GKE misurazione
Voglio sfruttare al meglio l'elasticità di GKE per i miei carichi di lavoro esistenti. Leggi Horizontal Pod Autoscaler, Cluster Autoscaler e scopri le best practice per Autoscaler e over-provisioning.
Voglio utilizzare i tipi di macchine più efficienti. Scegli il tipo di macchina giusto per il tuo carico di lavoro.
Molti nodi nel mio cluster sono inattivi. Leggi le best practice per Cluster Autoscaler.
Devo migliorare i risparmi sui costi nei miei job batch. Leggi le best practice per i carichi di lavoro collettivi.
Devo migliorare i risparmi sui costi dei miei carichi di lavoro di gestione. Leggi le best practice per il pubblicamento di carichi di lavoro.
Non so come dimensionare le mie richieste di risorse pod. Utilizza Vertical Pod Autoscaler (VPA), ma fai attenzione alle best practice per combinare Horizontal Pod Autoscaler (HPA) e VPA.
Le mie applicazioni sono instabili durante le attività di ridimensionamento automatico e manutenzione. Prepara le applicazioni basate su cloud per Kubernetes e scopri come funziona Metrics Server e come monitorarlo.
Come faccio a fare in modo che i miei sviluppatori prestino attenzione all'utilizzo delle risorse delle loro applicazioni? Distribuisci il risparmio sui costi cultura aziendale, valuta la possibilità di usare GKE Enterprise Policy Controller, progetta la tua pipeline CI/CD per applicare pratiche di risparmio sui costi e usa le quote delle risorse Kubernetes.
Cos'altro dovrei prendere in considerazione per ridurre ulteriormente i costi del mio ecosistema? Esamina piccoli cluster di sviluppo, esamina le tue strategie di logging e monitoraggio ed esamina il traffico in uscita interregionale nei cluster regionali e multizonali.

Funzionalità e opzioni di ottimizzazione dei costi di GKE

Le applicazioni Kubernetes con ottimizzazione dei costi fanno molto affidamento su GKE e la scalabilità automatica. Per bilanciare costi, affidabilità e prestazioni di scalabilità su GKE, devi capire come funziona la scalabilità automatica e quali opzioni hai a disposizione. Questa sezione illustra GKE della scalabilità automatica e altre utili configurazioni con ottimizzazione dei costi, sia per la pubblicazione carichi di lavoro batch.

Ottimizzare la scalabilità automatica di GKE

La scalabilità automatica è la strategia utilizzata da GKE per consentire ai clienti Google Cloud di pagare solo per ciò che richiedono, riducendo al minimo il tempo di attività dell'infrastruttura. In altre parole, la scalabilità automatica consente di risparmiare sui costi 1) rendendo dei carichi di lavoro e della loro infrastruttura sottostante si avviano prima dell'aumento della domanda, e 2) chiuderle quando la domanda diminuisce.

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

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

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

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

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

Il seguente diagramma illustra questi scenari.

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

Il resto di questa sezione tratta questi GKE di scalabilità automatica in modo più dettagliato e riguarda altre utili funzionalità sia per la distribuzione che per i carichi di lavoro in batch.

Horizontal Pod Autoscaler

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

La soglia di utilizzo target HPA ti consente di decidere quando attivare automaticamente dei trigger su larga scala.

Come mostrato nell'immagine precedente, HPA richiede una soglia di utilizzo target, expressed in percentage, che ti consente di personalizzare quando attivare automaticamente la scalabilità. In questo esempio, l'utilizzo della CPU target è del 70%. Ciò significa che il tuo carico di lavoro ha un buffer della CPU del 30% per gestire le richieste durante l'avvio delle nuove repliche. Un piccolo buffer impedisce l'aumento troppo rapido delle dimensioni, ma può sovraccaricare l'applicazione durante i picchi. Tuttavia, un buffer di grandi dimensioni provoca sprechi, con conseguente aumento dei costi. Il target esatto è specifico per l'applicazione e devi considerare che la dimensione del buffer sia sufficiente per gestire le richieste per due o tre minuti durante un picco. Anche se garantisci che la tua applicazione può si avvia in pochi secondi, questo tempo aggiuntivo è necessario quando Gestore della scalabilità automatica dei cluster aggiunge nuovi nodi al tuo cluster o quando i pod sono limitati per mancanza Google Cloud.

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

Per ulteriori informazioni, consulta Configurare un Horizontal Pod Autoscaler.

Gestore di scalabilità automatica pod verticale

A differenza dell'HPA, che aggiunge ed elimina le repliche dei pod per reagire rapidamente all'utilizzo di picchi, Gestore della scalabilità automatica pod verticale (VPA) osserva i pod nel tempo e trova gradualmente la CPU e la memoria ottimali risorse richieste dai pod. Impostare le risorse giuste è importante la stabilità e l'efficienza in termini di costi. Se anche le risorse del pod sono piccola, la tua applicazione può essere limitata o potrebbe non riuscire a causa di esaurimento della memoria. Se le risorse sono troppo grandi, si verificano sprechi e, quindi, le fatture sono più alte. VPA è pensato per i carichi di lavoro stateless e stateful non gestiti da HPA o quando non conosci le richieste di risorse dei pod appropriate.

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

Come mostra l'immagine precedente, VPA rileva che il pod è costantemente in esecuzione al limite e ricrea il pod con risorse più grandi. Anche il contrario si verifica quando il pod è costantemente sottoutilizzato e viene attivato lo scale down.

La VPA può funzionare in tre diverse modalità:

  • Disattivata. In questa modalità, nota anche come modalità consigli, VPA senza applicare alcuna modifica al pod. I suggerimenti vengono calcolati possono essere ispezionate nell'oggetto VPA.
  • Iniziale: VPA assegna richieste di risorse solo al momento della creazione del pod e non li modifichi mai in seguito.
  • Automatica: la VPA aggiorna le richieste di CPU e memoria durante il ciclo di vita di un pod. Ciò significa che il pod viene eliminato, la CPU e la memoria vengono regolate e viene avviato un nuovo pod.

Se prevedi di utilizzare la VPA, la best practice è iniziare con la modalità Off per recuperare i consigli della VPA. Assicurati che sia in funzione per 24 ore, idealmente almeno una settimana, prima di generare consigli. Solo quando ti sentirai sicuro, ti consigliamo di passare alla modalità Iniziale o Automatica.

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

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

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

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

Combinazione di HPA e VPA

Il consiglio ufficiale è di non combinare VPA e HPA su CPU o memoria. Tuttavia, puoi combinarle in modo sicuro utilizzando la modalità di suggerimento in VPA o le metriche personalizzate in HPA, ad esempio richieste al secondo. Quando combini VPA con HPA, assicurati che i deployment ricevano traffico sufficiente, ovvero che vengano eseguiti in modo coerente al di sopra delle repliche minime HPA. Ciò consente a VPA di comprendere la risorsa del pod e alle esigenze aziendali.

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

Programma di scalabilità automatica del cluster

Cluster Autoscaler (CA) ridimensiona automaticamente l'infrastruttura di calcolo sottostante. CA fornisce nodi per i pod che non devono essere eseguiti nel cluster e rimuove di nodi sottoutilizzati. CA è ottimizzata per il costo dell'infrastruttura. In altre Se nel cluster sono presenti due o più tipi di nodi, la CA sceglie più costosa e che risponda alla domanda.

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

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

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

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

Se le tue 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 spot. Affinché la CA funzioni come previsto, le richieste di risorse del pod devono essere sufficientemente grandi per il normale funzionamento del pod. Se le richieste di risorse sono troppo piccole, i nodi potrebbero non disporre di risorse sufficienti. che i pod potrebbero arrestarsi in modo anomalo o avere problemi durante il runtime.

Di seguito è riportato un riepilogo delle best practice per attivare Cluster Autoscaler nel tuo cluster:

  • Utilizza HPA o VPA per eseguire la scalabilità automatica dei carichi di lavoro.
  • Assicurati di seguire le best practice descritte nel Gestore della scalabilità automatica dei pod.
  • Scegli le dimensioni appropriate per la tua applicazione impostando richieste e limiti di risorse appropriati o utilizza VPA.
  • Definisci un PDB per le tue applicazioni.
  • Definisci PDB per i pod di sistema che potrebbero bloccare il ridimensionamento. Per ad esempio kube-dns. Per evitare interruzioni temporanee nel cluster, non impostare PDB per i pod di sistema che hanno una sola replica (ad esempio metrics-server).
  • Esegui pod di breve durata e pod che possono essere riavviati in pool di nodi distinti, in modo che i pod di lunga durata non blocchino il loro ridimensionamento.
  • Evita il provisioning eccessivo configurando i nodi inattivi nel cluster. Per devi conoscere la capacità minima, per molte aziende è durante la notte e imposta il numero minimo di nodi nel nodo per supportare questa capacità.
  • Se hai bisogno di una capacità aggiuntiva per gestire le richieste durante i picchi, utilizza i pod in pausa, discussi in Autoscaler e over-provisioning.

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

Provisioning automatico dei nodi

Provisioning automatico dei nodi (NAP) è un meccanismo del gestore della scalabilità automatica del cluster che aggiunge automaticamente nuovi pool di nodi oltre a gestirne le dimensioni per conto dell'utente. Senza nodo automaticamente, GKE considera solo l'avvio di nuovi nodi dal set di pool di nodi creati dall'utente. Con il provisioning automatico dei nodi, GKE può creare ed eliminare nuovi pool di nodi automaticamente.

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

Di seguito sono riportate le best practice per abilitare 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 il NAP apporti modifiche significative al cluster quando l'applicazione non riceve traffico.
  • Quando utilizzi Horizontal Pod Autoscaler per l'erogazione dei carichi di lavoro, ti consigliamo di riservare un buffer di utilizzo target leggermente più grande perché, in alcuni casi, NAP potrebbe aumentare la latenza della scalabilità automatica.

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

Gestore della scalabilità automatica e provisioning eccessivo

Per controllare i tuoi costi, ti consigliamo vivamente di attivare il gestore della scalabilità automatica secondo le sezioni precedenti. Nessuna configurazione è adatta a tutti gli scenari possibili, quindi devi ottimizzare le impostazioni per il tuo carico di lavoro per assicurarti che gli autori di scalabilità automatica rispondano correttamente agli aumenti del traffico.

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

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

Quando il cluster ha spazio sufficiente per il deployment di nuovi pod, uno dei carichi di lavoro scenari di scale up. Questo significa che se non è mai stato eseguito il deployment di un nodo esistente dell'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 dell'applicazione, il tempo totale di scale up diminuisce perché non è possibile scaricare immagini è obbligatorio (scenario 2).

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

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

Esistono due strategie principali per questo tipo di overprovisioning:

  • 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 raggiungendo il 100% della CPU. Questa variabile è utile perché il raggiungimento del 100% della CPU significa che la latenza dell'elaborazione delle richieste è molto più alta del solito.
    • perc è la percentuale di crescita del traffico prevista in due o tre anni minuti.

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

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

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

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

Scegli il tipo di macchina giusto

Oltre alla scalabilità automatica, altre configurazioni possono aiutarti a ottimizzare i costi le applicazioni Kubernetes su GKE. Questa sezione illustra la scelta del tipo di macchina più adatto.

VM spot

VM spot sono istanze VM di Compute Engine che non offrono garanzie di disponibilità. Le VM spot fino al 91% in meno rispetto alle VM standard di Compute Engine, ma ti consigliamo di usarle per i cluster GKE. Spot VM su GKE è più adatto per eseguire job batch o a tolleranza di errore che sono meno sensibili alla natura temporanea e non garantita dei Spot VM. I carichi di lavoro stateful e di pubblicazione non devono utilizzare Individua le VM a meno che non prepari il sistema e l'architettura per gestire i vincoli delle VM spot.

Qualunque sia il tipo di carico di lavoro, devi prestare attenzione a quanto segue: vincoli:

  • Il budget di interruzione del pod potrebbe non essere rispettato perché le VM spot possono essere arrestate inavvertitamente.
  • Non vi è alcuna garanzia che i pod chiudi con grazia quando il prerilascio del nodo ignora Periodo di tolleranza per i pod.
  • Potrebbero essere necessari diversi minuti prima che GKE rilevi che il nodo è stato sottoposto a preemption e che i pod non sono più in esecuzione, il che ritarda la riprogrammazione dei pod su un nuovo nodo.

A partire da GKE v1.20 arresto controllato del nodo è abilitata per impostazione predefinita per informare i carichi di lavoro in esecuzione.

Le VM spot non hanno una disponibilità garantita, il che significa che disponibili con facilità in alcune regioni. Per superare questo limite, consigliamo di impostare un pool di nodi di backup senza VM spot. Gruppo Il gestore della scalabilità automatica dà la precedenza alle VM spot perché è ottimizzata per i costi dell'infrastruttura.

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

Tipi di macchine E2

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

Per ulteriori informazioni sulle VM E2 e per confrontarle con altre per i tipi di macchine di Google Cloud, Gestione dinamica delle risorse basata sulle prestazioni nelle VM E2 e Tipi di macchine.

Seleziona la regione appropriata

Se il costo è un vincolo, quando esegui GKE i cluster sono importanti. Per molti fattori, il costo varia in base alla regione di calcolo. Pertanto, assicurati di eseguire il tuo carico di lavoro nell'opzione meno costosa, ma dove la latenza non influisce sul cliente. Se il tuo carico di lavoro richiede la copia di dati da una regione all'altra, ad esempio per eseguire un job batch, devi anche prendere in considerazione il costo del trasferimento di questi dati.

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

Registrati per gli sconti per impegno di utilizzo

Se intendi rimanere in Google Cloud per qualche anno, ti consigliamo consigliamo di acquistare sconti per impegno di utilizzo in cambio di prezzi molto scontati per l'utilizzo delle VM. Quando firmi un per impegno di utilizzo, acquisti le risorse di computing a un prezzo scontato (fino al 70% di sconto) in cambio dell'impegno a pagare quelle risorse per una sola o tre anni. Se hai dubbi su quante risorse impegnare, esamina il tuo utilizzo minimo dell'elaborazione, ad esempio durante la notte, e impegna il pagamento per quell'importo.

Per ulteriori informazioni sui prezzi per impegno di utilizzo per diversi tipi di macchine, vedi Prezzi delle istanze VM.

Esamina piccoli cluster di sviluppo

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

Rivedi le strategie di logging e monitoraggio

Se utilizzi Cloud Logging e Cloud Monitoring per fornire osservabilità delle tue applicazioni e della tua infrastruttura, paghi solo per ciò che utilizzi. Tuttavia, più è necessaria la tua infrastruttura log delle applicazioni: più a lungo conservi i log, più pagherai per loro. Allo stesso modo, maggiore è il numero di metriche esterne e personalizzate, maggiori saranno i costi.

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, multi-zona e regionali. Grazie all'alta disponibilità dei nodi nelle varie zone, i cluster regionali e multizona sono adatti per gli ambienti di produzione. Tuttavia, ti vengono addebitati dal il traffico in uscita tra zone. Per gli ambienti di produzione, ti consigliamo di monitorare il carico del traffico tra le zone e di migliorare le API per ridurlo al minimo. Valuta anche la possibilità di utilizzare configurazioni di affinità e anti-affinità tra pod per collocare in colocation pod dipendenti di servizi diversi negli stessi nodi o nella stessa zona di disponibilità per ridurre al minimo i costi e la latenza di rete tra di loro. Il modo consigliato per monitorare questo traffico è abilitare la misurazione dell'utilizzo di GKE e il relativo agente di traffico in uscita dalla rete, che è disabilitato per impostazione predefinita.

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

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

Le aziende hanno requisiti di costo e disponibilità diversi. I loro carichi di lavoro possono essere suddivisi in carichi di lavoro di pubblicazione, che devono rispondere rapidamente a picchi o picchi, e carichi di lavoro batch, che riguardano l'eventuale lavoro da svolgere. La gestione dei carichi di lavoro richiede una latenza di scale up ridotta. carichi di lavoro batch più tollerante alla latenza. Le diverse aspettative per questi tipi di carichi di lavoro rendono più flessibile la scelta di diversi metodi di risparmio.

Carichi di lavoro batch

Poiché i carichi di lavoro batch riguardano il lavoro finale, consentono di risparmiare sui costi su GKE perché i carichi di lavoro sono generalmente tolleranti nei confronti di una certa latenza all'avvio del job. Questa tolleranza offre a Cluster Autoscaler lo spazio per avviare nuovi nodi solo quando i job sono pianificati e per arrestarli al termine dei job.

La prima best practice consigliata è quella di separare i carichi di lavoro batch pool di nodi utilizzando etichette e selettori, e utilizzando incompatibilità e tolleranze. La motivazione è la seguente:

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

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

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

Carichi di lavoro di pubblicazione

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

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

  • Applicazioni non pronte per l'esecuzione su Kubernetes, ad esempio app con dimensioni delle immagini elevate, tempi di avvio lenti o configurazioni Kubernetes non ottimali.
  • delle applicazioni dipende dall'infrastruttura che richiede tempo di cui è stato eseguito il provisioning, come le GPU.
  • I gestori della scalabilità automatica e il provisioning eccessivo non sono impostati correttamente.

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 rendere funzionino in modo affidabile con i gestori della scalabilità automatica, ti consigliamo vivamente di implementarli.

Informazioni sulla capacità dell'applicazione

Quando pianifichi la capacità dell'applicazione, devi sapere quante richieste simultanee può gestire la tua applicazione, quanta CPU e memoria richiede e come risponde sotto un carico elevato. La maggior parte dei team non conosce queste capacità, quindi consigliamo devi testare il comportamento della tua applicazione sotto pressione. Prova a isolare una singola replica del pod dell'applicazione con la scalabilità automatica disattivata, quindi esegui i test simulando un carico di utilizzo reale. In questo modo puoi capire la capacità per pod. Consigliamo quindi di configurare il gestore della scalabilità automatica del cluster, le richieste di risorse e HPA o VPA. Poi sottolinea di nuovo la tua richiesta, ma con dell'intensità per simulare esplosioni o picchi improvvisi.

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

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

Assicurati che l'applicazione possa crescere verticalmente e orizzontalmente

Assicurati che la tua applicazione possa crescere e ridursi. Ciò significa che puoi scegliere di gestire gli aumenti di traffico aggiungendo più CPU e memoria o più repliche di pod. Questo ti offre la flessibilità di sperimentare ciò che si adatta dell'applicazione, sia che si tratti di una configurazione del gestore della scalabilità automatica diversa di nodi con dimensioni diverse. Purtroppo, alcune applicazioni sono a thread singolo o limitate da un numero fisso di worker o sottoprocessi che rendono impossibile questo esperimento senza un refactoring completo della loro architettura.

Imposta richieste e limiti delle risorse appropriati

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

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

Una buona pratica per impostare le risorse del container è utilizzare la stessa quantità di memoria per richieste e limiti e un limite della CPU più grande o illimitato. Prendi l' di deployment, ad esempio:

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

Il ragionamento alla base del pattern precedente si basa sul funzionamento della gestione delle risorse insufficienti di Kubernetes. In breve, quando le risorse del computer sono esaurite, i nodi diventano instabili. A evitare questa situazione kubelet monitora e impedisce il totale di queste risorse ranking dei pod che consumano molte risorse. Quando la CPU è in contesa, questi pod possono essere limitati in base alle sue richieste. Tuttavia, poiché la memoria è una risorsa non comprimibile, quando viene esaurita, il pod deve essere smontato. Per evitare che i pod vengano rimossi e, di conseguenza, destabilizzare l'ambiente, devi impostare la memoria richiesta sul limite di memoria.

Puoi anche utilizzare VPA in modalità suggerimento per determinare più facilmente CPU memoria utilizzata per una determinata applicazione. Poiché la VPA fornisce questi consigli in base all'utilizzo della tua applicazione, ti consigliamo di attivarla in un ambiente di produzione per far fronte al traffico reale. quindi lo stato VPA genera un report con le richieste e i limiti di risorse suggeriti, che puoi specificare in modo statico nel manifest di deployment. Se la tua richiesta è già definisce l'HPA, consulta Combinazione di HPA e VPA.

Assicurati che il contenitore sia il più snello possibile

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

  • Usa l'immagine più piccola possibile. È consigliabile avere perché ogni volta che il gestore della scalabilità automatica del cluster esegue il provisioning di un nuovo nodo per il 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 delle classi, della memorizzazione nella cache e così via. Quando I pod richiedono una lunga startup, potrebbero non andare a buon fine è in corso l'avvio dell'applicazione.

Prendi in considerazione queste due pratiche quando progetti il tuo sistema, soprattutto se in attesa di scoppi o picchi. Avere un'immagine piccola e un avvio rapido ti aiutano Riduci la latenza dello scale up. Di conseguenza, puoi gestire meglio gli aumenti di traffico senza preoccuparti troppo dell'instabilità. Queste pratiche funzionano meglio con le best practice di scalabilità automatica discusse in Scalabilità automatica di GKE.

Aggiungi budget di interruzione dei pod alla tua applicazione

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

Quando il PDB viene rispettato durante la fase di compattazione del gestore della scalabilità automatica del cluster, best practice per 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 qualsiasi momento, anche quando CA riduce il cluster.

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

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

L'impostazione di probe significativi garantisce che l'applicazione riceva il traffico solo quando è attivo e pronto ad accettare il traffico. GKE utilizza probe di idoneità per determinare quando aggiungere pod ai bilanciatori del carico o rimuoverli. GKE utilizza probe di attività per determinare quando riavviare i pod.

Il probe di attività è utile per comunicare a Kubernetes che un determinato pod non è in grado per avanzare, ad esempio quando viene rilevato uno stato di deadlock. La il probe di idoneità è utile per comunicare a Kubernetes che la tua applicazione pronto a ricevere traffico, ad esempio durante il caricamento di dati della cache di grandi dimensioni avvio automatico.

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

  • Definisci il probe di idoneità per tutti i container.
  • Se l'applicazione dipende da una cache da caricare all'avvio, Il probe di idoneità deve indicare che è pronto solo dopo che la cache è stata caricata completamente.
  • Se la tua applicazione può iniziare a pubblicare immediatamente, è un buon probe predefinito l'implementazione 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 controllare se il pool di connessioni ha risorse disponibili, assicurati che il tasso di errore non aumenta rispetto a un'implementazione più semplice.
  • Non consentire mai alla logica di prova di accedere ad altri servizi. Può compromettere del ciclo di vita del pod se questi servizi non rispondono prontamente.

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

Assicurati che le applicazioni si arrestino in base alle aspettative di Kubernetes

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

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

  • Non smettere di accettare nuove richieste subito dopo il giorno SIGTERM. Il tuo applicazione non deve arrestarsi immediatamente, ma terminare tutte le richieste che sono in transito e continuano ad ascoltare le connessioni in arrivo che arrivano dopo inizia l'arresto del pod. Potrebbe essere necessario del tempo prima che Kubernetes aggiorni tutti i kube-proxy e i bilanciatori del carico. Se la tua applicazione viene terminata prima che vengano aggiornate, alcune richieste potrebbero causare errori sul lato client.
  • Se la tua applicazione non segue la prassi precedente, utilizza il preStop hook. 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 graduale senza modificare l'applicazione. Una strategia comune è eseguire, nell'hook preStop, una sospensione di alcuni secondi per posticipare SIGTERM. In questo modo, Kubernetes ha più tempo per completare il processo di eliminazione del pod e si riducono gli errori di connessione lato client.
  • Gestisci SIGTERM per le pulizie. Se la tua applicazione deve eseguire la pulizia ha uno stato in memoria che deve essere mantenuto prima del processo termina il processo, ora è il momento di farlo. Diversi linguaggi di programmazione esistono diversi modi per rilevare questo segnale, quindi trova la strada giusta lingua.
  • Configura terminationGracePeriodSeconds in base alle esigenze della tua applicazione. Alcune applicazioni richiedono più il limite predefinito è di 30 secondi. In questo caso, devi specificare terminationGracePeriodSeconds. I valori elevati potrebbero aumentare i tempi di upgrade o implementazione dei nodi, ad esempio. Valori bassi potrebbero non concedere abbastanza tempo per consentire a Kubernetes di completare il processo di terminazione dei pod. In ogni caso, ti consigliamo di impostare il periodo di interruzione dell'applicazione su meno di 10 minuti perché il gestore della scalabilità automatica dei cluster lo rispetta solo per 10 minuti.
  • Se la tua applicazione utilizza il bilanciamento del carico nativo del container, inizia a non riuscire nel probe di idoneità quando ricevi un SIGTERM. Questa azione indica direttamente ai bilanciatori del carico di interrompere l'inoltro delle nuove richieste al pod di backend. A seconda della concorrenza tra la configurazione del controllo di integrità e la programmazione dell'endpoint, il pod di backend potrebbe essere rimosso dal traffico in precedenza.

Per ulteriori informazioni, vedi Best practice per Kubernetes: chiusura con grazia.

Configurare NodeLocal DNSCache

Il DNS gestito da GKE è implementato da kube-dns, un componente aggiuntivo di cui è stato eseguito il deployment in tutti i cluster GKE. Quando esegui per le 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, potrebbero non essere sufficienti. In questo scenario, le query DNS possono rallentare o scadere. Per mitigare questo problema, le aziende sono abituate a sull'ottimizzazione kube-dns-autoscaler ConfigMap per aumentare il numero di repliche kube-dns nei rispettivi cluster. Anche se questa strategia potrebbe funzionare come previsto, aumenta l'utilizzo delle risorse e il costo totale di GKE.

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

Per ulteriori informazioni, vedi Configurazione di NodeLocal DNSCache.

Utilizzare il bilanciamento del carico nativo del container tramite Ingress

Bilanciamento del carico nativo del container consente ai bilanciatori del carico di scegliere come target i pod Kubernetes direttamente e in modo distribuire il traffico ai 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 le NEG vengono utilizzate con GKE Ingress, il controller Ingress facilita la creazione di tutti gli aspetti del bilanciatore del carico L7. Sono inclusi la creazione dell'indirizzo IP virtuale, delle regole di inoltro, dei controlli di integrità, delle regole del firewall e altro ancora.

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

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

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

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

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

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

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

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

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

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

In molte medie e grandi imprese, una piattaforma e un'infrastruttura centralizzate è spesso responsabile della creazione, della manutenzione e del monitoraggio cluster per l'intera azienda. Ciò rappresenta un'esigenza imprescindibile per avere un'accountabilità dell'utilizzo delle risorse e per assicurarsi che tutti i team rispettino le norme dell'azienda. Questa sezione illustra le opzioni per il monitoraggio e l'applicazione in materia di costi.

Osserva i tuoi cluster GKE e cerca suggerimenti

Puoi controllare l'utilizzo delle risorse in un cluster Kubernetes esaminando di container, pod e servizi, nonché le caratteristiche del cluster nel suo complesso. Esistono molti modi per eseguire questa operazione, ma l'approccio iniziale che consigliato è l'osservazione dei tuoi cluster GKE tramite la dashboard di Monitoring. In questo modo ottieni dati di serie temporali sull'utilizzo del cluster, in modo da aggregare e spaziare da infrastruttura, carichi di lavoro e servizi.

Sebbene questo sia un buon punto di partenza, Google Cloud offre altri disponibili, ad esempio:

  • Nella pagina Cluster GKE della console Google Cloud, esamina colonna Notifiche. Se in un cluster c'è uno spreco di risorse elevato, l'interfaccia utente fornisce un suggerimento per confrontare le risorse allocate e quelle richieste informazioni.

    Vai all'elenco di cluster GKE

  • Nella pagina Suggerimenti della console Google Cloud, cerca per le schede dei consigli Risparmi sui costi.

    Vai all'hub dei suggerimenti

Per ulteriori dettagli, vedi Osservazione dei cluster GKE e Introduzione all'hub dei suggerimenti.

Abilita misurazione utilizzo GKE

Per un approccio più flessibile che ti consenta di visualizzare suddivisioni approssimative dei costi, prova la misurazione dell'utilizzo di GKE. La misurazione dell'utilizzo di GKE ti consente di visualizzare i profili di utilizzo dei tuoi cluster GKE suddivisi in base a spazi dei nomi ed etichette. Monitora le informazioni sulle richieste e sulle risorse dei carichi di lavoro dei cluster, come CPU, GPU, TPU, memoria, spazio e, facoltativamente, traffico di rete in uscita.

La misurazione dell'utilizzo di GKE ti aiuta a comprendere la struttura di costi complessiva dei tuoi cluster GKE, quale team o applicazione sta spendendo di più, quale ambiente o componente ha causato un improvviso picco di utilizzo o costi e quale team sta sprecando risorse. Mettendo a confronto le richieste di risorse all'utilizzo effettivo, puoi capire quali carichi di lavoro sono in overprovisioning.

Puoi sfruttare i modelli di Looker Studio predefiniti oppure fare un ulteriore passo e personalizzare le dashboard in base delle esigenze organizzative. Per ulteriori informazioni sull'utilizzo di GKE monitoraggio e 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 dei container per le pipeline di scalabilità automatica integrate di GKE. Metrics Server recupera le metriche dai kubelet e le espone tramite l'API Metrics di Kubernetes. HPA e VPA utilizzano queste metriche per determinare quando attivare la scalabilità automatica.

Per l'integrità della scalabilità automatica di GKE, devi disporre di un server Metrics in buono stato. Con il deployment di GKE metrics-server, viene installato un nanny per il ridimensionamento, che consente di far crescere il contenitore del server delle metriche verticalmente 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, ed è per questo che la tata deve riavviare il pod metrics-server per applicare le risorse necessarie.

Anche se il riavvio avviene rapidamente, la latenza totale per i gestori della scalabilità automatica capire che devono agire, possono essere leggermente aumentati dopo Ridimensiona di metrics-server. Per evitare riavvii frequenti di Metrics Server in rapida evoluzione, a partire da GKE 1.15.11-gke.9, la tata supporta i ritardi nel ridimensionamento.

Segui queste best practice quando utilizzi Metric Server:

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

Utilizza le quote delle risorse Kubernetes

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

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

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

Valuta la possibilità di utilizzare Policy Controller di GKE Enterprise

Policy Controller di GKE Enterprise è un controller di ammissione dinamico Kubernetes che controlla, verifica e applica la conformità dei cluster ai criteri relativi a sicurezza, normative o regole aziendali arbitrarie. Policy Controller utilizza i vincoli per applicare in modo forzato conformità. Ad esempio, puoi installare nei vincoli del cluster per molte delle best practice discusse in il Preparazione dell'applicazione Kubernetes basata su cloud . In questo modo, i deployment vengono rifiutati se non rispettano rigorosamente le tue pratiche Kubernetes. L'applicazione di queste regole consente di evitare costi imprevisti aumenta i picchi e riduce le possibilità di instabilità del carico di lavoro durante la scalabilità automatica.

Per ulteriori informazioni su come applicare e scrivere le tue regole, consulta Creare vincoli e Scrivere un modello di vincolo. Se non sei un GKE Enterprise puoi prendere in considerazione l'utilizzo Gatekeeper il software open source su cui si basa Policy Controller.

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

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

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

Per ulteriori informazioni, vedi Utilizzo di Policy Controller in una pipeline CI, Per un esempio completo di una piattaforma di distribuzione, consulta Approccio CI/CD moderno con GKE Enterprise.

Diffondere la cultura del risparmio

Molte organizzazioni creano astrazioni e piattaforme per nascondere l'infrastruttura complessità da parte tua. Si tratta di una prassi comune nelle aziende che stanno migrando i propri servizi dalle macchine virtuali a Kubernetes. A volte queste aziende consentono agli sviluppatori di configurare le proprie applicazioni in produzione. Tuttavia, è raro vedere sviluppatori che non hanno mai interagito con un cluster Kubernetes.

Le pratiche consigliate in questa sezione non implicano che sia necessario interrompere fare delle astrazioni. Ti aiutano invece a visualizzare le tue spese su Google Cloud e a formare gli sviluppatori e gli operatori sulla tua infrastruttura. Puoi farlo creando programmi e incentivi per l'apprendimento in cui puoi utilizzare corsi tradizionali o online, gruppi di discussione, revisioni tra pari, programmazione collaborativa, CI/CD e gamification per risparmiare sui costi e altro ancora. Per Ad esempio, nel mondo Kubernetes è importante comprendere l'impatto Applicazione immagine Gb, probe di idoneità mancante o configurazione errata dell'HPA.

Infine, come mostrato nella ricerca DORA di Google, le competenze culturali sono alcuni dei fattori principali che migliorano il rendimento dell'organizzazione, riducono le rilavorazioni, il burnout e così via. Il risparmio sui costi è non c'è differenza. Se concedi ai tuoi dipendenti l'accesso alle loro spese, li allinea meglio a stretto contatto con gli obiettivi e i vincoli commerciali.

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 applicazioni Kubernetes cloud-native
Monitora l'ambiente e applica configurazioni e best practice ottimizzate in termini di costi
Cultura

Passaggi successivi