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

Questo documento tratta Google Kubernetes Engine (GKE) funzioni e opzioni e le best practice per l'ottimizzazione dei costi applicazioni su GKE per sfruttare l'elasticità fornita sono creati da Google Cloud. In questo documento si presuppone che tu abbia familiarità con Kubernetes, Google Cloud, GKE e la scalabilità automatica.

Introduzione

Con la diffusione diffusa di Kubernetes, un numero crescente di aziende e i fornitori Platform as a Service (PaaS) e Software as a Service (SaaS) utilizzando cluster Kubernetes multi-tenant per i loro carichi di lavoro. Ciò significa che un singolo cluster potrebbe essere in esecuzione di applicazioni che appartengono a team, reparti, clienti diversi ambienti cloud-native. 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. Ciò accade perché le aziende tradizionali che adottano soluzioni basate su cloud come Kubernetes non hanno sviluppatori e operatori con competenze cloud. Questa mancanza di idoneità al cloud porta all'instabilità delle applicazioni durante la scalabilità automatica (ad esempio, volatilità del traffico durante un normale periodo della giornata), scoppi improvvisi o picchi (ad esempio spot pubblicitari in TV o eventi su scala come Black Friday e Cyber Monday lunedì). 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 soluzioni Kubernetes con ottimizzazione dei costi carichi di lavoro standard 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 bassi costi e stabilità delle applicazioni, è necessario impostare o ottimizzare alcune funzionalità e configurazioni (ad esempio, scalabilità automatica, tipi e 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. Nonostante ti invitiamo a leggere l'intero documento, presenta una mappa degli argomenti trattati.

Sfida Azione
Voglio dare un'occhiata ai facili risparmi sui costi su GKE. Seleziona l'area appropriata, registrarsi per un impegno di utilizzo gli sconti e utilizza la macchina E2 tipi.
Devo conoscere i miei costi di GKE. Osserva le tue GKE cluster e verifica i suggerimenti e abilita l'utilizzo di GKE misurazione
Voglio ottenere il massimo dall'elasticità di GKE per i miei carichi di lavoro esistenti. Leggi la sezione Horizontal Pod Gestore della scalabilità automatica, Cluster Gestore della scalabilità automatica e comprendere le best practice per il gestore della scalabilità automatica l'overprovisioning.
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 Gestore della scalabilità automatica.
Devo migliorare i risparmi sui costi dei miei job batch. Leggi le best practice per la gestione collettiva carichi di lavoro standard.
Devo migliorare i risparmi sui costi dei miei carichi di lavoro di gestione. Leggi le best practice per la pubblicazione carichi di lavoro standard.
Non so come dimensionare le mie richieste di risorse pod. Usa Vertical Pod Autoscaler (VPA), ma presta attenzione alla combinazione di Horizontal Pod Gestore della scalabilità automatica (HPA) Best practice per gli VPA.
Le mie applicazioni sono instabili durante la scalabilità automatica e la manutenzione attività. Preparazione basate su cloud per Kubernetes e comprendere come funziona Metrics Server e come per monitorarlo.
Come faccio a fare in modo che i miei sviluppatori prestino attenzione alle loro applicazioni risorsa utilizzo? 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 i piccoli sviluppi cluster, esamina le strategie di logging e monitoraggio ed esaminare il traffico in uscita tra regioni a livello di regione e multi-zona.

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 scalabilità delle prestazioni devi comprendere come funziona la scalabilità automatica le opzioni a tua disposizione. Questa sezione illustra GKE della scalabilità automatica e altre configurazioni utili con ottimizzazione dei costi, sia per la pubblicazione carichi di lavoro batch.

Ottimizza la scalabilità automatica di GKE

La scalabilità automatica è la strategia utilizzata da GKE I clienti Google Cloud pagano solo per ciò di cui hanno bisogno, riducendo al minimo il tempo di attività dell'infrastruttura. In altre parole, la scalabilità automatica consente di risparmiare sui costi 1) 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 che vengono eseguite Pod, e l'infrastruttura sottostante, composta da un insieme di Nodi, e fornire capacità di calcolo sufficiente per eseguire i carichi di lavoro.

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

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

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

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

Il seguente diagramma illustra questi scenari.

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

Il resto di questa sezione 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) è pensato per la scalabilità delle applicazioni in esecuzione nei pod in base che esprimono il carico. Puoi configurare l'utilizzo della CPU o altre metriche personalizzate, ad esempio 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, l'HPA richiede una soglia di utilizzo target, espressa in percentuale, che permette di decidere quando attivare dei trigger su larga scala. In questo esempio, l'utilizzo target della CPU è del 70%. Ciò significa il carico di lavoro ha un buffer della CPU del 30% per la gestione delle richieste, mentre le nuove repliche girare. Un buffer piccolo impedisce lo scale up in anticipo, ma può sovraccaricare durante i picchi. Tuttavia, un buffer di grandi dimensioni provoca sprechi, con conseguente aumento dei costi. Il target esatto è specifico dell'applicazione consideri la dimensione del buffer sufficiente a gestire le richieste di due 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 abilitare HPA nella tua applicazione:

Per ulteriori informazioni, vedi Configurazione di 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 le 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 a tua disposizione sono eccessive, causi sprechi e quindi fatture più grandi. VPA è pensato per i carichi di lavoro stateless e stateful non è gestita dall'HPA o se non conosci le corrette richieste di risorse pod.

VPA rileva che un pod è costantemente in esecuzione ai suoi limiti 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.

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.
  • Automatico: VPA aggiorna le richieste di CPU e memoria durante il ciclo di vita di un pod. Ciò significa che il pod viene eliminato, CPU e memoria vengono regolate e quindi viene Il pod viene avviato.

Se prevedi di utilizzare VPA, la best practice è iniziare con la modalità Off per l'estrazione di suggerimenti VPA. Assicurati che sia in funzione per 24 ore, idealmente almeno una settimana, prima di generare consigli. Poi, solo quando senti che ti consigliamo di passare alla modalità Iniziale o Auto.

Segui queste best practice per abilitare VPA, nella sezione Iniziale o Automatica. nell'applicazione:

Se stai considerando l'uso della modalità Auto, assicurati di seguire anche queste pratiche:

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

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

Combinazione di HPA e VPA

La consiglio ufficiale è che non devi 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 mescoli VPA e HPA, assicurati che i deployment ricevono traffico sufficiente, ovvero vengono eseguiti costantemente al di sopra delle repliche minime dell'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

Gestore della scalabilità automatica dei cluster (CA) ridimensiona automaticamente l'infrastruttura computer 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, 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 prassi garantisce che, se I gestori della scalabilità automatica dei pod stabiliscono che hai bisogno di più capacità, della tua infrastruttura cresce di conseguenza.

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

Come mostrano questi diagrammi, CA aggiunge e rimuove automaticamente capacità di calcolo gestire picchi di traffico e risparmiare denaro quando i clienti dormono. È una best practice per definire Budget di interruzione dei pod per tutte le tue applicazioni. È particolarmente importante presso l'autorità di certificazione fase di scale down quando il PDB controlla il numero di repliche che è possibile rimuovere contemporaneamente.

Alcuni pod non possono essere riavviati da nessun gestore della scalabilità automatica quando causano un'interruzione temporanea, quindi il nodo su non possono essere eliminati. Ad esempio, 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 particolare attività di scalabilità non si è verificata 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 prerilasciabili. Affinché CA funzioni come previsto, Le richieste di risorse del pod devono essere abbastanza grandi da consentire al pod di funzionare normalmente. 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 l'abilitazione dei cluster Gestore della scalabilità automatica nel tuo cluster:

  • Utilizza HPA o VPA per scalare automaticamente i carichi di lavoro.
  • Assicurati di seguire le best practice descritte nel Gestore della scalabilità automatica dei pod.
  • Dimensiona correttamente l'applicazione la creazione di richieste e limiti appropriati per le risorse o utilizzare il VPA.
  • Definisci un PDB per le tue applicazioni.
  • Definisci il PDB per i pod di sistema che potrebbero bloccare lo scale down. Per ad esempio kube-dns. Per evitare interruzioni temporanee nel cluster, non imposta il 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 un nodo separato in modo che i pod di lunga durata non ne blocchino lo scale down.
  • Evita il provisioning eccessivo configurando i nodi inattivi nel cluster. Per 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 capacità aggiuntiva per gestire le richieste durante i picchi, usa mettendo in pausa i pod, di cui parleremo Gestore della scalabilità automatica e provisioning eccessivo.

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 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 le tue sono resilienti ai nodi che si riavviano inavvertitamente e alle perdite di capacità, puoi ridurre ulteriormente i costi configurare la tolleranza di una VM prerilasciabile nel tuo pod.

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

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

Per ulteriori informazioni, vedi Utilizzo del 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 scenari possibili, quindi è necessario ottimizzare le impostazioni per il carico di lavoro assicurano che i gestori della scalabilità automatica rispondano correttamente all'aumento del traffico.

Tuttavia, come indicato nel Horizontal Pod Autoscaler gli scale up potrebbero richiedere del tempo a causa del provisioning dell'infrastruttura. A questa differenza nel tempo e i possibili scenari di scale up, considera le nell'immagine che segue.

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

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, uno dei Vengono attivati scenari di scale up 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 cluster Il gestore della scalabilità automatica deve eseguire il provisioning di nodi e pool di nodi (scenario 2).

Per scenari in cui è necessaria una nuova infrastruttura, non comprimere il tuo cluster devi eseguire l'overprovisioning ma solo per riservare i necessari del buffer per gestire le richieste di picco previste durante gli scale up.

Esistono due strategie principali per questo tipo di overprovisioning:

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

    (1 - buff)/(1 + perc)

    • buff è un buffer di sicurezza che puoi impostare per evitare raggiungendo il 100% della CPU. Questa variabile è utile perché raggiunge il 100% della CPU significa che la latenza dell'elaborazione delle richieste è molto più elevata del solito.
    • perc è la percentuale di crescita del traffico prevista in due o tre 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. Puoi invece impostare un target di utilizzo HPA su forniscono un buffer per aiutare a gestire i picchi di carico. Tuttavia, se prevedi di acquistare burst, impostare un target di utilizzo HPA ridotto potrebbe non essere sufficiente diventano troppo costosi.

    Una soluzione alternativa a questo problema è utilizzare mettere in pausa i pod. I pod in pausa sono deployment a bassa priorità che non fanno altro che per prenotare una stanza nel cluster. Ogni volta che viene pianificato un pod a priorità elevata, i pod vengono rimossi e il pod ad alta priorità 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. Come best practice, conviene avere un solo pod in pausa per nodo. Ad esempio: se utilizzi 4 nodi CPU, configura l'impostazione di messa in pausa dei pod di CPU 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 tratta la scelta del tipo di macchina corretto.

VM prerilasciabili

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

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

  • Il budget di interruzione dei pod potrebbe non essere rispettato perché i nodi prerilasciabili può arrestarsi inavvertitamente.
  • Non vi è alcuna garanzia che i pod chiudi con grazia quando il prerilascio del nodo ignora Periodo di tolleranza per i pod.
  • Il rilevamento da parte di GKE potrebbe richiedere diversi minuti che il nodo è stato prerilasciato e che i pod non sono più in esecuzione. ritardi nella ripianificazione dei pod in un nuovo nodo.

Per mitigare questi vincoli, puoi eseguire il deployment nel tuo cluster di una comunità Gestore di eventi di chiusura dei nodi progetto (importante: non si tratta di un progetto Google ufficiale) che fornisce una per tradurre gli eventi di terminazione dei nodi Compute Engine in terminazione controllata dei pod in Kubernetes. Questo progetto della community non che risolva in modo affidabile tutte le VM una volta che i budget di interruzione dei pod mancare di rispetto. Di conseguenza, la ripianificazione dei pod può richiedere più tempo.

Infine, le VM non hanno una disponibilità garantita, il che significa che possono in alcune regioni. Per ovviare a questo limite, ti consigliamo di impostare un di backup senza PVM. Il gestore della scalabilità automatica del cluster dà la preferenza alle VM perché è ottimizzato per i costi dell'infrastruttura.

Per ulteriori informazioni, vedi Esecuzione di VM prerilasciabili su GKE e Esegui applicazioni web su GKE utilizzando VM spot con ottimizzazione dei costi.

Tipi di macchine E2

Tipi di macchine E2 (VM E2) sono VM ottimizzate per i costi che offrono un risparmio del 31% rispetto alle Tipi di macchine N1. Le VM E2 sono adatte per un'ampia gamma di carichi di lavoro, tra cui server web, microservizi, applicazioni business-critical, database di piccole e medie dimensioni, ambienti di sviluppo e 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. A causa di molti fattori, il costo varia a seconda della regione di computing. Quindi assicurati di eseguire il carico di lavoro nell'opzione meno costosa, ma in cui la latenza non influisce sul cliente. Se il carico di lavoro richiede la copia dati da una regione all'altra, ad esempio per eseguire un job batch, devi anche considera il costo dello spostamento di questi dati.

Per ulteriori informazioni su come scegliere la regione giusta, consulta Best practice per la selezione delle regioni di Compute Engine.

Registrati agli sconti per impegno di utilizzo

Se 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 non sai di quante risorse eseguire il commit, controlla l'utilizzo minimo del computing, ad esempio durante la notte, e il pagamento per tale importo.

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

Esamina cluster di sviluppo di piccole dimensioni

Per cluster di sviluppo di piccole dimensioni in cui devi ridurre al minimo i costi, valuta l'utilizzo Pilota automatico cluster. Con i cluster in questa modalità di funzionamento, non ti viene addebitato alcun costo per Pod, costi del sistema operativo o carichi di lavoro non pianificati.

Rivedi le strategie di logging e monitoraggio

Se utilizzi Cloud Logging e Cloud Monitoring per offrire osservabilità nelle applicazioni e nell'infrastruttura, pagando solo per quello che usi. Tuttavia, più 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. Rivedi le tue strategie di logging e monitoraggio utilizzando Observability di Google Cloud.

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

I tipi di cluster GKE disponibili a zona singola, multizona, e regionale. Grazie all'elevata disponibilità di nodi nelle varie zone, a livello di regione e multi-zona sono adatti agli ambienti di produzione. Tuttavia, ti vengono addebitati dal il traffico in uscita tra zone. Per gli ambienti di produzione, consigliamo di monitorare il carico del traffico tra zone diverse e migliorare le API per ridurlo al minimo. Valuta anche l'utilizzo affinità e anti-affinità tra i pod per la collocazione di pod dipendenti da servizi diversi nello stesso nodi o nella stessa zona di disponibilità per ridurre al minimo i costi e la latenza di rete tra di loro. Il metodo consigliato per monitorare questo traffico è attivare Misurazione dell'utilizzo di GKE e le relative agente di rete in uscita, che è disattivato 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 per adattarlo al tipo di carico di lavoro

Le aziende hanno requisiti diversi in termini di costi e disponibilità. Loro possono essere suddivisi in carichi di lavoro di gestione, che devono rispondere rapidamente burst o picchi e carichi di lavoro in batch, riguardanti il lavoro finale da completare. 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 sono preoccupati per il lavoro finale, di risparmio sui costi su GKE, perché i carichi di lavoro sono generalmente tollerati una certa latenza al momento dell'avvio del job. Questa tolleranza concede spazio al gestore della scalabilità automatica del cluster di avviare nuovi nodi solo quando i job sono pianificati e di rimuoverli quando il completamento 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 del cluster può eliminare i nodi vuoti più velocemente quando non è necessario per riavviare i pod. Al termine dei job batch, il cluster accelera lo scale down se il carico di lavoro è in esecuzione su nodi dedicati che ora sono vuoti. Per migliorare ulteriormente la velocità delle scale down, valuta la possibilità di configurare Profilo di ottimizzazione-utilizzo di CA.
  • Alcuni pod non possono essere riavviati, quindi bloccano definitivamente lo scale down dei propri 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 prerilasciabili solo se esegui job a tolleranza di errore meno sensibili alla natura temporanea e non garantita dei modelli delle VM in esecuzione.

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

Carichi di lavoro di gestione

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 aumenti improvvisi del traffico possono derivare da fattori, ad esempio spot pubblicitari in TV, eventi su scala come il Black Friday ultime notizie. La tua applicazione deve essere preparata per gestirle.

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

  • Applicazioni non pronte per essere eseguite su Kubernetes, ad esempio le app con immagini di grandi dimensioni, tempi di avvio lenti o Kubernetes non ottimale configurazioni.
  • delle applicazioni dipende dall'infrastruttura che richiede tempo per essere di cui è stato eseguito il provisioning, come le GPU.
  • Gestori della scalabilità automatica e overprovisioning non sia impostata 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.

Comprendi la capacità dell'applicazione

Quando pianifichi la capacità dell'applicazione, scopri quante richieste in parallelo l'applicazione è in grado di gestire, la quantità di CPU e memoria richiesta e come essere sottoposti a 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 un singolo replica del pod dell'applicazione con scalabilità automatica disattivata, quindi esegui i test simulando un carico di utilizzo reale. Questo ti aiuta a comprendere la capacità per pod. Consigliamo quindi di configurare il gestore della scalabilità automatica del cluster, le richieste 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 utilizza lo strumento che preferisci per questi test, che si tratti di un copione artigianale o strumento per il rendimento più avanzato, Benchmark Apache, JMeter o Locust.

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

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

Assicurati che la tua applicazione possa crescere e ridursi. Ciò significa che puoi puoi scegliere di gestire gli aumenti del traffico aggiungendo più CPU e memoria aggiungendo altre 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 candidature sono organizzate in thread o è limitato da un numero fisso di worker o processi secondari che rendono questo esperimento impossibile senza un refactoring completo dell'architettura.

Imposta richieste e limiti appropriati per le risorse

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

Quando hai impostato correttamente le richieste di risorse, lo scheduler Kubernetes può utilizzarle per decidere su quale nodo posizionare il pod. Questo garantisce che i pod posizionati in nodi che possono farli funzionare normalmente, così da ottenere un'esperienza la stabilità e 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 container è utilizzare la stessa quantità di memoria per richieste e limiti e un limite di CPU maggiore 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 modello precedente si basa su come Gestione fuori risorse di Kubernetes funziona. 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 è contesa, questi pod possono essere limitati alle sue richieste. Tuttavia, poiché la memoria è una risorsa incomprimibile, quando la memoria è esaurita, è necessario rimuovere il pod. Per evitare che i pod vengano disattivati, destabilizzando 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é il VPA offre consigli di questo tipo, in base all'utilizzo dell'applicazione, ti consigliamo di abilitarla di produzione per affrontare il 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 container sia il più snello possibile

Quando esegui container su Kubernetes, l'applicazione può avviarsi e arrestarsi in qualsiasi momento. Per questo motivo è 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. Alcune applicazioni possono richiedono minuti per l'avvio a causa del caricamento della classe, 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, è possibile gestire meglio l'aumento del traffico senza preoccuparsi troppo sull'instabilità. Queste pratiche funzionano meglio con sulle best practice per la scalabilità automatica 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, kernel o quando qualcuno elimina 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 richieste per supportare il carico in qualsiasi momento, anche quando CA sta eseguendo lo scale down del cluster.

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

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

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

Il probe di attività è utile per comunicare a Kubernetes che un determinato pod non è in grado 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 corretto ciclo di vita dell'applicazione durante le attività di scale up, è importante fare quanto segue:

  • 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 l'accesso ad altri servizi della logica del probe. Può compromettere del ciclo di vita del pod se questi servizi non rispondono prontamente.

Per ulteriori informazioni, vedi Configura probe di attività, idoneità e avvio.

Assicurati che le tue applicazioni vengano arrestate secondo le 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 per la gestione dei pod deve essere preparata per un avvio rapido o arrestato.

Poiché Kubernetes aggiorna in modo asincrono endpoint e bilanciatori del carico, è importante seguire queste best practice per garantire arresti anomali 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. L'aggiornamento di Kubernetes potrebbe richiedere un po' di tempo tutto kube-proxies e 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 la gancio preStop. La maggior parte dei programmi non smette di accettare subito le richieste. Tuttavia, se utilizzano codice di terze parti o gestiscono un sistema che non hai il controllo in eccesso, come nginx, l'hook preStop è una buona opzione per attivare una chiusura controllata senza modificare l'applicazione. Una strategia comune è eseguire, l'hook di preStop, un sonno di qualche secondo per posticipare SIGTERM. In questo modo Kubernetes ha più tempo per completare il processo di eliminazione dei pod. riduce gli errori di connessione sul 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 per soddisfare le esigenze della tua applicazione. Alcune applicazioni richiedono più il limite predefinito è di 30 secondi. In questo caso, devi specificare terminationGracePeriodSeconds. Valori elevati potrebbero aumentare il tempo per il nodo o deployment, 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 chiusura dell'applicazione su un valore inferiore a 10 minuti perché Il gestore della scalabilità automatica del cluster lo rispetta solo per 10 minuti.
  • Se la tua applicazione utilizza bilanciamento del carico nativo del container, inizia a non riuscire nel probe di idoneità quando ricevi un SIGTERM. Questo segnala direttamente ai bilanciatori del carico di interrompere l'inoltro di nuove richieste il pod di backend. A seconda del gruppo etnico 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, vedi Best practice per Kubernetes: chiusura con grazia.

Configura NodeLocal DNSCache

Il DNS gestito da GKE implementata da kube-dns di 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 questo potrebbe funzionare come previsto, aumentando così l'utilizzo delle risorse e il numero totale Costo 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.

Utilizza 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, ne aumenta la visibilità, funzionalità avanzate di bilanciamento del carico e consente l'uso di Cloud Service Mesh 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 vengono usati i NEG con GKE Ingress, il controller Ingress semplifica la creazione di tutti gli aspetti del bilanciatore del carico L7. Sono inclusi creazione dell'indirizzo IP virtuale, regole di forwarding, controlli di integrità, firewall regole e altro.

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

Per ulteriori informazioni, vedi Documentazione di Ingress su GKE e Utilizzo del bilanciamento del carico nativo del container.

Valuta la possibilità di utilizzare nuovi tentativi con backoff esponenziale

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

Questi problemi sono temporanei e puoi mitigarli chiamando il servizio di nuovo dopo un ritardo. 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 nuovi tentativi, molte librerie esistenti implementano la logica esponenziale della nuova prova. Puoi utilizzare la libreria che preferisci o scrivere i tuoi codice personalizzato. Se utilizzi Istio o Cloud Service Mesh (ASM), puoi optare per il proxy a livello riprova che esegue in maniera trasparente i nuovi tentativi 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 il tuo ambiente e applica configurazioni e pratiche ottimizzate per i 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 una forte necessità di avere la responsabilità dell'utilizzo delle risorse e di assicurarsi che tutti i team seguano in base alle politiche aziendali. 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 un cluster presenta 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 un costo approssimativo i guasti, prova Misurazione dell'utilizzo di GKE. La misurazione dell'utilizzo di GKE ti consente di vedere dei cluster GKE profili di utilizzo suddivisi per spazi dei nomi 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 il costo complessivo della struttura dei cluster GKE, il team o l'applicazione di spendere di più, quindi quale ambiente o componente ha causato un improvviso picco di utilizzo o costi aggiuntivi, oltre che uno spreco di 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

Il server delle metriche è l'origine delle metriche delle risorse container per Pipeline di scalabilità automatica integrate di GKE. Recupero di Metrics Server metriche da kubelet e le espone tramite l'interfaccia utente API Metrics. HPA e VPA utilizzano quindi queste metriche per determinare quando attivare la scalabilità automatica.

Per l'integrità della scalabilità automatica di GKE, devi disporre di un del server delle metriche. Con il deployment GKE metrics-server, strumento di ridimensionamento nanny è installato, in modo da far crescere il container del server delle metriche verticalmente aggiungendo o rimuovendo CPU e memoria in base al nodo del cluster conteggio. 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 GKE che supporta metrics-server ritardi nel ridimensionamento. Puoi verificarlo controllando se il valore-chiave Il file YAML del deployment metrics-server ha il scale-down-delay nel container metrics-server-nanny.
  • Monitora il deployment di metrics-server. Se il server delle metriche non è attivo, significa la scalabilità automatica non funziona. Vuoi che il tuo monitoraggio per la massima priorità per monitorare il deployment.
  • Segui le best practice descritte in Scalabilità automatica di GKE.

Utilizza le quote delle risorse Kubernetes

Nei cluster multi-tenant, diversi team diventano comunemente responsabili il deployment di applicazioni in spazi dei nomi diversi. Per una piattaforma centralizzata gruppo infrastrutturale, la preoccupazione che un team possa utilizzare del necessario. Stai esaurendo tutte le risorse di computing del cluster o persino l'attivazione di troppe scale up può aumentare i costi.

Per risolvere questo problema, devi utilizzare 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 consentono di assicurare che nessun tenant utilizzi rispetto alla quota di risorse del cluster assegnata a quest'ultimo.

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

Valuta la possibilità di utilizzare GKE Enterprise Policy Controller

Controller dei criteri di GKE Enterprise (APC) è un cluster Kubernetes controller di ammissione dinamico che verifica, verifica e applica in modo forzato i cluster conformità alle norme relative a sicurezza, normative o regole commerciali arbitrarie. Policy Controller utilizza i vincoli per applicare le regole conformità. Ad esempio, puoi installare nel tuo cluster i vincoli 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 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 in modo forzato e scrivere le tue regole, consulta Creazione di vincoli e Scrittura di 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 APC.

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

GKE Enterprise Policy Controller ti aiuta a evitare il deployment 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 procedura consente di trovare e correggere rapidamente gli errori di configurazione e capisci a cosa devi prestare attenzione creando dei guardrail.

Valuta anche l'utilizzo funzioni kpt nella tua pipeline CI/CD per verificare se i tuoi file di configurazione Kubernetes adempiere ai vincoli applicati da GKE Enterprise Policy Controller, e stimare l'utilizzo delle risorse o i costi del deployment. In questo modo può arrestare la pipeline quando viene rilevato un problema relativo ai costi. Oppure puoi creare un diverso processo di approvazione dei deployment per le configurazioni che, ad esempio, Ad esempio, aumenta 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.

Diffondi la cultura del risparmio sui costi

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 consente 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 la spesa su Google Cloud e addestra i tuoi sviluppatori e operatori sui tuoi dell'infrastruttura. Puoi farlo creando programmi e incentivi per l'apprendimento in cui puoi utilizzare lezioni tradizionali o online, gruppi di discussione, revisioni, programmazione di coppie, gamification di CI/CD e risparmio 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 ricerca DORA di Google, le capacità culturali sono alcuni dei principali fattori che favoriscono prestazioni organizzative, meno rilavorazioni, meno 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 seguente tabella riassume le best practice consigliate in questa documento.

Argomento Attività
Funzionalità e opzioni di ottimizzazione dei costi di GKE
Prepara le tue applicazioni Kubernetes cloud-native
Monitora il tuo ambiente e applica configurazioni e pratiche ottimizzate per i costi
Cultura

Passaggi successivi