Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Calcolo e scalabilità automatica

In qualità di sviluppatore, farai delle stime sui requisiti di risorse della tua applicazione, ad esempio CPU e memoria, ma se non li aggiusti continuamente potrebbero diventare obsoleti, il che potrebbe aumentare i costi e peggiorare le prestazioni e l'affidabilità. Adeguare continuamente i requisiti di risorse di un'applicazione è più importante che soddisfarli correttamente al primo tentativo.

Le migliori pratiche menzionate di seguito vi aiuteranno a creare e gestire carichi di lavoro attenti ai costi che consentano di raggiungere risultati aziendali riducendo al minimo i costi e consentendo all'organizzazione di massimizzare il ritorno sull'investimento. Un ordine di importanza elevato per l'ottimizzazione dei costi di elaborazione del cluster è:

Dimensiona correttamente i tuoi carichi di lavoro

Nella maggior parte dei cluster EKS, la maggior parte dei costi proviene dalle EC2 istanze utilizzate per eseguire i carichi di lavoro containerizzati. Non sarete in grado di dimensionare correttamente le risorse di elaborazione senza comprendere i requisiti dei vostri carichi di lavoro. Ecco perché è essenziale utilizzare le richieste e i limiti appropriati e apportare le modifiche necessarie a tali impostazioni. Inoltre, le dipendenze, come la dimensione dell'istanza e la selezione dello storage, possono influire sulle prestazioni del carico di lavoro, con una serie di conseguenze indesiderate su costi e affidabilità.

Le richieste devono essere in linea con l'utilizzo effettivo. Se le richieste di un container sono troppo elevate, ci sarà una capacità inutilizzata, che è un fattore importante nei costi totali del cluster. Ogni contenitore in un pod, ad esempio l'applicazione e i sidecar, dovrebbe avere le proprie richieste e limiti impostati per garantire che i limiti aggregati dei pod siano il più precisi possibile.

Utilizza strumenti come Goldilocks, KRR e Kubecost che stimano le richieste di risorse e i limiti per i tuoi contenitori. A seconda della natura delle applicazioni, dei performance/cost requisiti e della complessità, è necessario valutare quali sono le metriche migliori su cui basare la scalabilità, in che momento le prestazioni dell'applicazione peggiorano (punto di saturazione) e come modificare di conseguenza le richieste e i limiti. Per ulteriori informazioni su questo argomento, consulta Application right sizing.

Ti consigliamo di utilizzare Horizontal Pod Autoscaler (HPA) per controllare quante repliche dell'applicazione devono essere in esecuzione, Vertical Pod Autoscaler (VPA) per regolare il numero di richieste e limiti necessari all'applicazione per replica e uno scaler automatico a nodi come Karpenter o Cluster Autoscaler per regolare continuamente il numero totale di nodi nel cluster. Le tecniche di ottimizzazione dei costi che utilizzano Karpenter e Cluster Autoscaler sono documentate in una sezione successiva di questo documento.

Il Vertical Pod Autoscaler può regolare le richieste e i limiti assegnati ai container in modo che i carichi di lavoro funzionino in modo ottimale. È necessario eseguire il VPA in modalità di controllo in modo che non apporti automaticamente modifiche e non riavvii i pod. Suggerirà modifiche in base alle metriche osservate. In caso di modifiche che influiscono sui carichi di lavoro di produzione, è consigliabile esaminarle e testarle prima in un ambiente non di produzione, poiché possono avere un impatto sull'affidabilità e sulle prestazioni dell'applicazione.

Ridurre i consumi

Il modo migliore per risparmiare è fornire meno risorse. Un modo per farlo è adattare i carichi di lavoro in base ai requisiti attuali. Dovresti iniziare qualsiasi iniziativa di ottimizzazione dei costi assicurandoti che i carichi di lavoro definiscano i requisiti e si scalino dinamicamente. Ciò richiederà l'acquisizione di metriche dalle applicazioni e l'impostazione di configurazioni come Pod Readiness Gates per garantire che l'applicazione possa scalare verso l'alto PodDisruptionBudgetse verso il basso in modo sicuro e dinamico. È importante considerare che un approccio restrittivo PodDisruptionBudgets può impedire a Cluster Autoscaler e Karpenter di ridimensionare i nodi, poiché sia Cluster Autoscaler che Karpenter lo rispettano. PodDisruptionBudgets Il valore 'minAvailable' in PodDisruptionBudget deve essere sempre inferiore al numero di pod nella distribuzione e dovresti mantenere un buon buffer tra i due, ad esempio in una distribuzione di 6 pod in cui desideri che siano sempre attivi almeno 4 pod, imposta 'minAvailable' nel tuo PodDisruptionBidget su 4. Ciò consentirà a Cluster Autoscaler e Karpenter di drenare ed eliminare in sicurezza i pod dai nodi sottoutilizzati durante un evento di scale-down del nodo. Consulta il documento delle domande frequenti su Cluster Autoscaler.

Horizontal Pod Autoscaler è un autoscaler flessibile per carichi di lavoro in grado di regolare il numero di repliche necessarie per soddisfare i requisiti di prestazioni e affidabilità dell'applicazione. Dispone di un modello flessibile per definire quando scalare verso l'alto e verso il basso in base a varie metriche come CPU, memoria o metriche personalizzate, ad esempio profondità della coda, numero di connessioni a un pod, ecc.

Il Kubernetes Metrics Server consente la scalabilità in risposta a metriche integrate come l'utilizzo di CPU e memoria, ma se desideri scalare in base ad altre metriche, come la profondità della coda di Amazon CloudWatch o SQS, dovresti prendere in considerazione progetti di scalabilità automatica basati su eventi come KEDA. Consulta questo post del blog su come utilizzare KEDA con le metriche. CloudWatch Se non sei sicuro delle metriche da monitorare e su cui basare la scalabilità, consulta le migliori pratiche per monitorare le metriche più importanti.

La riduzione del consumo del carico di lavoro crea un eccesso di capacità in un cluster e, con una corretta configurazione di scalabilità automatica, è possibile ridimensionare automaticamente i nodi e ridurre la spesa totale. Ti consigliamo di non cercare di ottimizzare la capacità di elaborazione manualmente. Lo scheduler Kubernetes e gli autoscaler dei nodi sono stati progettati per gestire questo processo al posto tuo.

Riduci la capacità inutilizzata

Dopo aver determinato la dimensione corretta per le applicazioni, riducendo le richieste in eccesso, è possibile iniziare a ridurre la capacità di elaborazione assegnata. Dovresti essere in grado di eseguire questa operazione in modo dinamico se hai impiegato il tempo necessario per dimensionare correttamente i carichi di lavoro illustrato nelle sezioni precedenti. Esistono due scaler automatici di nodi principali utilizzati con Kubernetes in AWS.

Karpenter e Cluster Autoscaler

Sia Karpenter che Kubernetes Cluster Autoscaler ridimensioneranno il numero di nodi del cluster man mano che i pod vengono creati o rimossi e i requisiti di elaborazione cambiano. L'obiettivo principale di entrambi è lo stesso, ma Karpenter adotta un approccio diverso per la gestione dei nodi, il provisioning e il de-provisioning, che può aiutare a ridurre i costi e ottimizzare l'utilizzo a livello di cluster.

Con l'aumentare delle dimensioni dei cluster e l'aumento della varietà di carichi di lavoro, diventa sempre più difficile preconfigurare gruppi di nodi e istanze. Proprio come per le richieste di carichi di lavoro, è importante impostare una linea di base iniziale e adattarla continuamente in base alle esigenze.

Se si utilizza Cluster Autoscaler, rispetterà i valori «minimo» e «massimo» di ciascun gruppo di Auto Scaling (ASG) e regolerà solo il valore «desiderato». È importante prestare attenzione durante l'impostazione di questi valori per l'ASG sottostante poiché Cluster Autoscaler non sarà in grado di ridimensionare un ASG oltre il numero «minimo». Imposta il conteggio «desiderato» come il numero di nodi necessari durante il normale orario lavorativo e «minimo» come il numero di nodi necessari durante le ore non lavorative. Consulta il documento delle domande frequenti su Cluster Autoscaler.

Cluster Autoscaler Priority Expander

Kubernetes Cluster Autoscaler funziona scalando gruppi di nodi, chiamati gruppi di nodi, verso l'alto e verso il basso man mano che le applicazioni si scalano verso l'alto e verso il basso. Se non stai scalando dinamicamente i carichi di lavoro, Cluster Autoscaler non ti aiuterà a risparmiare denaro. Cluster Autoscaler richiede che un amministratore del cluster crei in anticipo gruppi di nodi per l'utilizzo dei carichi di lavoro. I gruppi di nodi devono essere configurati per utilizzare istanze con lo stesso «profilo», ovvero all'incirca la stessa quantità di CPU e memoria.

È possibile avere più gruppi di nodi e Cluster Autoscaler può essere configurato per impostare livelli di scalabilità prioritari e ogni gruppo di nodi può contenere nodi di dimensioni diverse. I gruppi di nodi possono avere diversi tipi di capacità e l'espansore di priorità può essere utilizzato innanzitutto per scalare gruppi meno costosi.

Di seguito è riportato un esempio di un frammento di configurazione del cluster che utilizza ConfigMap` a per dare priorità alla capacità riservata prima di utilizzare istanze su richiesta. È possibile utilizzare la stessa tecnica per dare priorità alle istanze Graviton o Spot rispetto ad altri tipi.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
managedNodeGroups:
  - name: managed-ondemand
    minSize: 1
    maxSize: 7
    instanceType: m5.xlarge
  - name: managed-reserved
    minSize: 2
    maxSize: 10
    instanceType: c5.2xlarge

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*ondemand.*
    50:
      - .*reserved.*

L'uso dei gruppi di nodi può aiutare le risorse di elaborazione sottostanti a eseguire le operazioni previste per impostazione predefinita, ad esempio distribuendo i nodi tra i vari carichi di lavoro AZs, ma non tutti i carichi di lavoro hanno gli stessi requisiti o aspettative ed è meglio lasciare che le applicazioni dichiarino i propri requisiti in modo esplicito. Per ulteriori informazioni su Cluster Autoscaler, consulta la sezione sulle migliori pratiche.

Descheduler

Cluster Autoscaler può aggiungere e rimuovere la capacità dei nodi da un cluster in base alla necessità di pianificare nuovi pod o al sottoutilizzo dei nodi. Non fornisce una visione completa del posizionamento dei pod dopo che sono stati pianificati su un nodo. Se utilizzi Cluster Autoscaler, dovresti anche dare un'occhiata al descheduler Kubernetes per evitare di sprecare capacità nel tuo cluster.

Se hai 10 nodi in un cluster e ogni nodo è utilizzato al 60%, non stai utilizzando il 40% della capacità assegnata nel cluster. Con Cluster Autoscaler è possibile impostare la soglia di utilizzo per nodo al 60%, ma in questo modo si cercherà di ridurre un singolo nodo solo dopo che l'utilizzo è sceso al di sotto del 60%.

Con il descheduler può esaminare la capacità e l'utilizzo del cluster dopo che i pod sono stati pianificati o i nodi sono stati aggiunti al cluster. Tenta di mantenere la capacità totale del cluster al di sopra di una soglia specificata. Può anche rimuovere i pod in base a problemi di nodo o nuovi nodi che si uniscono al cluster per assicurarsi che i pod funzionino nel loro ambiente di calcolo ottimale. Nota che, descheduler non pianifica la sostituzione dei pod eliminati, ma a tale scopo si affida allo scheduler predefinito.

Consolidamento Karpenter

Karpenter adotta un approccio «senza gruppi» alla gestione dei nodi. Questo approccio è più flessibile per diversi tipi di carico di lavoro e richiede meno configurazioni iniziali per gli amministratori del cluster. Invece di predefinire i gruppi e scalare ogni gruppo in base alle esigenze dei carichi di lavoro, Karpenter utilizza i provisioner e i modelli di nodi per definire in generale il tipo di EC2 istanze che possono essere create e le impostazioni relative alle istanze man mano che vengono create.

Il bin packing è la pratica di utilizzare una maggiore quantità di risorse dell'istanza impacchettando più carichi di lavoro su un numero inferiore di istanze di dimensioni ottimali. Sebbene ciò contribuisca a ridurre i costi di elaborazione fornendo solo le risorse utilizzate dai carichi di lavoro, presenta un compromesso. L'avvio di nuovi carichi di lavoro può richiedere più tempo perché è necessario aggiungere capacità al cluster, specialmente durante eventi di scalabilità su larga scala. Considerate l'equilibrio tra ottimizzazione dei costi, prestazioni e disponibilità quando impostate l'imballaggio dei contenitori.

Karpenter può monitorare e comprimere continuamente per migliorare l'utilizzo delle risorse delle istanze e ridurre i costi di elaborazione. Karpenter può anche selezionare un nodo di lavoro più efficiente in termini di costi per il tuo carico di lavoro. Ciò può essere ottenuto attivando il flag «consolidation» su true nel provisioner (frammento di codice di esempio riportato di seguito). L'esempio seguente mostra un provider di esempio che consente il consolidamento. Al momento della stesura di questa guida, Karpenter non sostituirà un'istanza Spot in esecuzione con un'istanza Spot più economica. Per ulteriori dettagli sul consolidamento di Karpenter, consulta questo blog.

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: enable-binpacking
spec:
  consolidation:
    enabled: true

Per carichi di lavoro che potrebbero non essere interrompibili, ad esempio lavori in batch di lunga durata senza checkpoint, prendi in considerazione l'idea di annotare i pod con l'annotazione. do-not-evict Disattivando lo sfratto dai pod, stai dicendo a Karpenter che non deve rimuovere volontariamente i nodi che contengono questo pod. Tuttavia, se un do-not-evict pod viene aggiunto a un nodo mentre il nodo si sta esaurendo, i pod rimanenti verranno comunque espulsi, ma quel pod bloccherà la terminazione finché non viene rimosso. In entrambi i casi, il nodo verrà isolato per evitare che vengano pianificati lavori aggiuntivi sul nodo. Di seguito è riportato un esempio che mostra come impostare l'annotazione:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
  annotations: +
    "karpenter.sh/do-not-evict": "true"
spec:
  containers:

* name: nginx
image: nginx
ports:
 ** containerPort: 80

Rimuovi i nodi sottoutilizzati regolando i parametri di Cluster Autoscaler

L'utilizzo dei nodi è definito come la somma delle risorse richieste divisa per la capacità. Per impostazione predefinita, scale-down-utilization-threshold è impostato al 50%. Questo parametro può essere utilizzato insieme a andscale-down-unneeded-time, che determina per quanto tempo un nodo non deve essere necessario prima che sia idoneo per la riduzione. L'impostazione predefinita è 10 minuti. I pod ancora in esecuzione su un nodo ridimensionato verranno programmati su altri nodi da kube-scheduler. La modifica di queste impostazioni può aiutare a rimuovere i nodi sottoutilizzati, ma è importante testare prima questi valori in modo da non forzare il cluster a ridimensionarsi prematuramente.

È possibile evitare il ridimensionamento assicurandosi che i pod costosi da rimuovere siano protetti da un'etichetta riconosciuta da Cluster Autoscaler. A tale scopo, assicuratevi che i pod costosi da rimuovere abbiano l'annotazione. cluster-autoscaler.kubernetes.io/safe-to-evict=false Di seguito è riportato un esempio di yaml per impostare l'annotazione:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
  annotations: +
    "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
spec:
  containers:

* name: nginx
image: nginx
ports:
 ** containerPort: 80

Etichetta i nodi con Cluster Autoscaler e Karpenter

I tag delle risorse AWS vengono utilizzati per organizzare le risorse e tenere traccia dei costi AWS a livello dettagliato. Non sono direttamente correlati alle etichette Kubernetes per il monitoraggio dei costi. Si consiglia di iniziare con l'etichettatura delle risorse Kubernetes e utilizzare strumenti come Kubecost per ottenere report sui costi dell'infrastruttura basati sulle etichette Kubernetes su pod, namespace ecc.

I nodi di lavoro devono avere tag per mostrare le informazioni di fatturazione in AWS Cost Explorer. Con Cluster Autoscaler, tagga i nodi di lavoro all'interno di un gruppo di nodi gestito utilizzando il modello di avvio. Per i gruppi di nodi autogestiti, tagga le tue istanze utilizzando il gruppo di scalabilità EC2 automatica. Per le istanze fornite da Karpenter, etichettale usando spec.tags nel modello di nodo.

Cluster multi-tenant

Quando lavori su cluster condivisi da team diversi, potresti non avere visibilità sugli altri carichi di lavoro in esecuzione sullo stesso nodo. Sebbene le richieste di risorse possano contribuire a isolare alcuni problemi legati al problema dei «vicini rumorosi», come la condivisione della CPU, potrebbero non isolare tutti i limiti delle risorse, come l'esaurimento del disco. I/O Non tutte le risorse consumabili in base a un carico di lavoro possono essere isolate o limitate. I carichi di lavoro che consumano risorse condivise a ritmi più elevati rispetto ad altri carichi di lavoro devono essere isolati mediante contaminazioni e tolleranze dei nodi. Un'altra tecnica avanzata per questo tipo di carico di lavoro è il pinning della CPU, che garantisce una CPU esclusiva anziché una CPU condivisa per il contenitore.

L'isolamento dei carichi di lavoro a livello di nodo può essere più costoso, ma potrebbe essere possibile pianificare i BestEffortlavori o sfruttare ulteriori risparmi utilizzando istanze riservate, processori Graviton o Spot.

I cluster condivisi possono anche avere vincoli di risorse a livello di cluster, come l'esaurimento degli indirizzi IP, i limiti dei servizi Kubernetes o le richieste di scalabilità delle API. È necessario consultare la guida alle migliori pratiche di scalabilità per assicurarsi che i cluster evitino questi limiti.

È possibile isolare le risorse a livello di namespace o di provider Karpenter. Le quote di risorse forniscono un modo per impostare limiti al numero di risorse che i carichi di lavoro possono consumare in un namespace. Questa può essere una buona barriera iniziale, ma dovrebbe essere valutata continuamente per assicurarsi che non limiti artificialmente la scalabilità dei carichi di lavoro.

I provisioner di Karpenter possono impostare limiti su alcune delle risorse consumabili in un cluster (ad esempio CPU, GPU), ma sarà necessario configurare le applicazioni tenant per utilizzare il provisioner appropriato. Ciò può impedire a un singolo provider di creare troppi nodi in un cluster, ma deve essere continuamente valutato per assicurarsi che il limite non sia troppo basso e, a sua volta, impedire la scalabilità dei carichi di lavoro.

Scalabilità automatica pianificata

Potrebbe essere necessario ridimensionare i cluster nei fine settimana e fuori orario. Ciò è particolarmente importante per i cluster di test e non di produzione in cui si desidera ridurli a zero quando non sono in uso. Soluzioni come cluster-turndown possono ridurre a zero le repliche in base a una pianificazione cron. Puoi farlo anche con Karpenter, descritto nel seguente blog AWS.

Ottimizza i tipi di capacità di elaborazione

Dopo aver ottimizzato la capacità totale di elaborazione nel cluster e aver utilizzato il bin packing, è necessario esaminare il tipo di elaborazione a cui è stato assegnato il provisioning nei cluster e il modo in cui si paga per tali risorse. AWS offre piani Compute Savings in grado di ridurre i costi di elaborazione, che classificheremo nei seguenti tipi di capacità:

Ogni tipo di capacità presenta compromessi diversi in termini di sovraccarico di gestione, disponibilità e impegni a lungo termine e dovrai decidere qual è la soluzione più adatta al tuo ambiente. Nessun ambiente deve basarsi su un singolo tipo di capacità ed è possibile combinare più tipi di esecuzione in un unico cluster per ottimizzare requisiti e costi specifici dei carichi di lavoro.

Spot

Il tipo di capacità spot fornisce EC2 istanze dalla capacità inutilizzata in una zona di disponibilità. Spot offre gli sconti più elevati, fino al 90%, ma tali istanze possono essere interrotte quando sono necessarie altrove. Inoltre, potrebbe non essere sempre possibile effettuare il provisioning di nuove istanze Spot e le istanze Spot esistenti possono essere recuperate con un avviso di interruzione di 2 minuti. Se l'applicazione ha un processo di avvio o arresto lungo, le istanze Spot potrebbero non essere l'opzione migliore.

Spot Compute dovrebbe utilizzare un'ampia varietà di tipi di istanze per ridurre la probabilità che non disponga di capacità spot disponibile. Le interruzioni delle istanze devono essere gestite per chiudere i nodi in modo sicuro. I nodi forniti con Karpenter o facenti parte di un Managed Node Group supportano automaticamente le notifiche di interruzione delle istanze. Se utilizzi nodi autogestiti, dovrai eseguire il gestore di terminazione dei nodi separatamente per chiudere correttamente le istanze spot.

È possibile bilanciare istanze spot e on-demand in un unico cluster. Con Karpenter è possibile creare provisioner ponderati per raggiungere un equilibrio tra diversi tipi di capacità. Con Cluster Autoscaler è possibile creare gruppi di nodi misti con istanze spot, on-demand o riservate.

Ecco un esempio di utilizzo di Karpenter per dare priorità alle istanze Spot rispetto alle istanze On-Demand. Quando si crea un provisioner, è possibile specificare Spot, On-Demand o entrambi (come illustrato di seguito). Quando specificate entrambi, e se il pod non specifica esplicitamente se deve utilizzare Spot o On-Demand, Karpenter dà la priorità a Spot quando fornisce a un nodo una strategia di allocazione. price-capacity-optimization

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: spot-prioritized
spec:
  requirements:
    - key: "karpenter.sh/capacity-type"
      operator: In
        values: ["spot", "on-demand"]

Savings Plans, istanze riservate e AWS EDP

Puoi ridurre la spesa di elaborazione utilizzando un piano di risparmio di calcolo. I piani di risparmio offrono prezzi ridotti per un periodo di 1 o 3 anni di utilizzo dell'elaborazione. L'utilizzo può essere applicato alle EC2 istanze in un cluster EKS ma si applica anche a qualsiasi utilizzo di elaborazione come Lambda e Fargate. Con i piani di risparmio puoi ridurre i costi e continuare a scegliere qualsiasi tipo di EC2 istanza durante il periodo di impegno.

Il piano Compute Savings può ridurre i EC2 costi fino al 66% senza richiedere impegni sui tipi di istanze, sulle famiglie o sulle aree geografiche che desideri utilizzare. I risparmi vengono applicati automaticamente alle istanze man mano che le utilizzi.

EC2 Instance Savings Plans offre risparmi fino al 72% sull'elaborazione con un impegno di utilizzo in una regione e una EC2 famiglia specifiche, ad esempio istanze della famiglia C. È possibile spostare l'utilizzo in qualsiasi zona della regione, utilizzare qualsiasi generazione della famiglia di istanze, ad esempio c5 o c6, e utilizzare istanze di qualsiasi dimensione all'interno della famiglia. Lo sconto verrà applicato automaticamente a qualsiasi istanza del tuo account che soddisfi i criteri del piano di risparmio.

Le istanze riservate sono simili a EC2 Instance Savings Plan ma garantiscono anche la capacità in una zona o regione di disponibilità e riducono i costi, fino al 72%, rispetto alle istanze on demand. Una volta calcolata la capacità riservata necessaria, puoi selezionare per quanto tempo desideri prenotarle (1 anno o 3 anni). Gli sconti verranno applicati automaticamente man mano che eseguirai tali EC2 istanze nel tuo account.

I clienti hanno anche la possibilità di sottoscrivere un Enterprise Agreement con AWS. Gli accordi aziendali consentono ai clienti di personalizzare i contratti per adattarli alle loro esigenze. I clienti possono usufruire di sconti sui prezzi basati su AWS EDP (Enterprise Discount Program). Per ulteriori informazioni sugli accordi aziendali, contatta il tuo rappresentante di vendita AWS.

On demand

Rispetto ai piani di risparmio, EC2 le istanze On-Demand offrono il vantaggio di una disponibilità senza interruzioni, rispetto alle istanze spot, e di nessun impegno a lungo termine. Se stai cercando di ridurre i costi in un cluster, dovresti ridurre l'utilizzo di istanze on-demand. EC2

Dopo aver ottimizzato i requisiti del carico di lavoro, dovresti essere in grado di calcolare la capacità minima e massima per i tuoi cluster. Questo numero può cambiare nel tempo, ma raramente diminuisce. Prendi in considerazione l'idea di utilizzare un Savings Plan per tutto ciò che è al di sotto del minimo e una capacità spot che non influisca sulla disponibilità dell'applicazione. Qualsiasi altra cosa che potrebbe non essere utilizzata continuamente o che è necessaria per la disponibilità può essere utilizzata su richiesta.

Come indicato in questa sezione, il modo migliore per ridurre l'utilizzo è consumare meno risorse e utilizzare le risorse fornite nella massima misura possibile. Con Cluster Autoscaler è possibile rimuovere i nodi sottoutilizzati con l'impostazione. scale-down-utilization-threshold Con Karpenter si consiglia di abilitare il consolidamento.

Per identificare manualmente i tipi di EC2 istanze che possono essere utilizzati con i carichi di lavoro, è necessario utilizzare ec2-instance-selector, che può mostrare le istanze disponibili in ogni regione e le istanze compatibili con EKS. Esempio di utilizzo per istanze con architettura di processo x86, 4 GB di memoria, 2 v CPUs e disponibili nella regione us-east-1.

ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \
  -r us-east-1 --service eks
c5.large
c5a.large
c5ad.large
c5d.large
c6a.large
c6i.large
t2.medium
t3.medium
t3a.medium

Per gli ambienti non di produzione, è possibile ridimensionare automaticamente i cluster durante le ore non utilizzate, come la notte e i fine settimana. Il progetto kubecost cluster-turndown è un esempio di controller in grado di ridimensionare automaticamente il cluster in base a una pianificazione prestabilita.

Calcolo Fargate

Fargate Compute è un'opzione di elaborazione completamente gestita per i cluster EKS. Fornisce l'isolamento dei pod pianificando un pod per nodo in un cluster Kubernetes. Consente di dimensionare i nodi di elaborazione in base ai requisiti di CPU e RAM del carico di lavoro per controllare in modo rigoroso l'utilizzo del carico di lavoro in un cluster.

Fargate è in grado di scalare carichi di lavoro fino a 0,25 vCPU con 0,5 GB di memoria e fino a 16 vCPU con 120 GB di memoria. Esistono dei limiti al numero di varianti di dimensione dei pod disponibili e dovrai capire come il tuo carico di lavoro si adatta meglio a una configurazione Fargate. Ad esempio, se il carico di lavoro richiede 1 vCPU con 0,5 GB di memoria, il pod Fargate più piccolo sarà 1 vCPU con 2 GB di memoria.

Sebbene Fargate offra molti vantaggi, come l'assenza di gestione delle EC2 istanze o del sistema operativo, può richiedere una maggiore capacità di elaborazione rispetto alle EC2 istanze tradizionali, poiché ogni pod distribuito è isolato come nodo separato nel cluster. Ciò richiede una maggiore duplicazione per cose come Kubelet, gli agenti di registrazione e tutti quelli che normalmente si distribuiscono su DaemonSets un nodo. DaemonSets non sono supportati in Fargate e dovranno essere convertiti in pod «`sidecars"` ed eseguiti insieme all'applicazione.

Fargate non può trarre vantaggio dal bin packing o dall'overprovisioning della CPU perché il limite del carico di lavoro è un nodo che non è espandibile o condivisibile tra carichi di lavoro. Fargate consente di risparmiare tempo nella gestione delle EC2 istanze, il che di per sé ha un costo, ma i costi di CPU e memoria possono essere più costosi rispetto ad altri tipi di EC2 capacità. I pod Fargate possono sfruttare il piano di risparmio di calcolo per ridurre i costi on-demand.

Ottimizza l'utilizzo dell'elaborazione

Un altro modo per risparmiare sull'infrastruttura di elaborazione consiste nell'utilizzare un'elaborazione più efficiente per il carico di lavoro. Questo può derivare da elaborazioni generiche più performanti come i processori Graviton, che sono fino al 20% più economici e il 60% più efficienti dal punto di vista energetico rispetto all'x86, o da acceleratori specifici per carichi di lavoro come and. GPUs FPGAs Dovrai creare contenitori che possano funzionare sull'architettura ARM e configurare nodi con gli acceleratori giusti per i tuoi carichi di lavoro.

EKS ha la capacità di eseguire cluster con architettura mista (ad esempio amd64 e arm64) e se i contenitori sono compilati per più architetture, puoi sfruttare i processori Graviton con Karpenter, abilitando entrambe le architetture nel tuo provisioner. Per mantenere costanti le prestazioni, tuttavia, si consiglia di mantenere ogni carico di lavoro su un'unica architettura di elaborazione e di utilizzare un'architettura diversa solo se non è disponibile capacità aggiuntiva.

I provider possono essere configurati con più architetture e i carichi di lavoro possono anche richiedere architetture specifiche nelle specifiche del carico di lavoro.

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
  - key: "kubernetes.io/arch"
    operator: In
    values: ["arm64", "amd64"]

Con Cluster Autoscaler dovrai creare un gruppo di nodi per le istanze Graviton e impostare le tolleranze dei nodi sul tuo carico di lavoro per utilizzare la nuova capacità.

GPUs e FPGAs può aumentare notevolmente le prestazioni del carico di lavoro, ma il carico di lavoro dovrà essere ottimizzato per utilizzare l'acceleratore. Molti tipi di carico di lavoro per l'apprendimento automatico e l'intelligenza artificiale possono essere utilizzati GPUs per l'elaborazione e le istanze possono essere aggiunte a un cluster e montate in un carico di lavoro utilizzando richieste di risorse.

spec:
  template:
    spec:
    - containers:
      ...
      resources:
          limits:
            nvidia.com/gpu: "1"

Alcuni hardware GPU possono essere condivisi tra più carichi di lavoro in modo da poter effettuare il provisioning e l'utilizzo di una singola GPU. Per scoprire come configurare la condivisione della GPU del carico di lavoro, consulta il plug-in del dispositivo GPU virtuale per ulteriori informazioni. Puoi anche fare riferimento ai seguenti blog: