Approfondimento

Ottimizzazione dei costi di Kubernetes: 8 passaggi e 23 strumenti

aggiornato il 18 set. 2026

I cluster Kubernetes possono sembrare del tutto sani mentre il conto sale. L'autoscaling è configurato, le dashboard sono verdi e la spesa aumenta comunque. In un sondaggio, il 42% di 455 ingegneri di piattaforma ha indicato il costo come la sfida numero uno con Kubernetes, mentre l'88% ha visto il costo totale di proprietà aumentare di anno in anno.¹

Abbiamo raccolto 68 case study sull'ottimizzazione dei costi di Kubernetes e abbiamo mappato ogni caso d'uso menzionato a ciascun fornitore che lo ha pubblicato:

Kubernetes cost optimization: use cases by tool

Caricamento del grafico

Le celle più scure indicano più menzioni. Le celle vuote indicano che lo strumento non ha casi pubblicati per quel caso d'uso.

Scorri per una guida in 8 passaggi con esempi reali per ridurre la spesa del cluster e il confronto degli strumenti di ottimizzazione dei costi di Kubernetes.

1. Misura prima di cambiare qualsiasi cosa

Ogni numero nel resto di questa guida è un delta, e un delta ha bisogno di un punto di partenza. Senza una baseline catturata prima della prima modifica, non c'è modo di dire se il passaggio 1 ha funzionato, né di attribuire i risparmi del passaggio 3 al consolidamento piuttosto che al rightsizing che lo ha preceduto. Questo conta di più qui che nella maggior parte del lavoro di ingegneria, perché tutte e sei le azioni riducono la stessa bolletta e i loro risparmi non si sommano. Liberare capacità nel passaggio 1 non produce nulla in fattura finché il passaggio 3 non rimuove i nodi.

Misura quattro cose:

Richiesta rispetto a utilizzata CPU e memoria, per workload. Il divario è il tuo backlog del passaggio 1, ordinato per dimensione.
Costo per namespace e per workload. Questo è ciò che rende le quote del passaggio 2 una negoziazione piuttosto che un'imposizione.
Efficienza di bin-packing, allocabile rispetto a richiesto per nodo. L'obiettivo del passaggio 3.
Costo dell'inattività per ora del giorno e giorno della settimana in non produzione. Dimensiona il passaggio 5 prima di costruirlo.

Misura per almeno un ciclo aziendale completo. Sette giorni è il minimo e trenta è meglio. La finestra non è cautela procedurale. Il passaggio 1 imposta le richieste di memoria al massimo osservato, e un massimo osservato vale quanto la finestra che lo ha osservato. Un massimo rilevato su 48 ore non coglie un job batch settimanale e produce un OOMKill la domenica successiva.

1# The step 1 backlog, largest gaps first
2sort_desc(
3  sum by (namespace, pod) (
4    kube_pod_container_resource_requests{resource="cpu"}
5  )
6  -
7  sum by (namespace, pod) (
8    rate(container_cpu_usage_seconds_total[7d])
9  )
10)

Strumenti

Allocazione dei costi: OpenCost, il progetto CNCF alla base del modello di allocazione, è il livello gratuito. Il tier gratuito di Kubecost racchiude lo stesso motore in una UI fino a 250 core.
Utilizzo: Prometheus con kube-state-metrics è il substrato. Robusta KRR lo legge direttamente senza installare nulla nel cluster.
Spesa più ampia: Dove Kubernetes è una parte di una bolletta che anche la finanza deve spiegare, CloudZero, Vantage e Finout si collocano sopra questo livello piuttosto che sostituirlo.

Entrambi gli strumenti di costo attribuiscono per etichetta, quindi l'etichettatura viene prima. La spesa non etichettata è il motivo più comune per cui una baseline si rivela inutile tre settimane dopo.

1helm install opencost opencost/opencost \
2  --namespace opencost --create-namespace \
3  --set opencost.prometheus.internal.enabled=true

Ogni azione di seguito indica la raccomandazione, il metodo, la configurazione e un'azienda che ha compiuto quel passo. Ogni case study e ogni statistica riporta un link alla fonte.

2. Imposta le quote dei namespace come guardrail

I risparmi decadono man mano che i team distribuiscono nuovi workload senza richieste specificate. Un LimitRange fornisce richieste predefinite ai container che le omettono, e una ResourceQuota limita ciò che un namespace può consumare in aggregato.

Distribuisci il LimitRange prima della ResourceQuota. Una volta che una quota vincola una risorsa, qualsiasi pod senza una richiesta per quella risorsa viene rifiutato all'ammissione, quindi l'ordine inverso interrompe i deployment.²

1apiVersion: v1
2kind: LimitRange
3metadata:
4  name: defaults
5  namespace: team-payments
6spec:
7  limits:
8    - type: Container
9      defaultRequest:
10        cpu: "100m"
11        memory: "128Mi"
12      default:
13        cpu: "500m"
14        memory: "512Mi"
15      maxLimitRequestRatio:
16        memory: "1"
17---
18apiVersion: v1
19kind: ResourceQuota
20metadata:
21  name: team-quota
22  namespace: team-payments
23spec:
24  hard:
25    requests.cpu: "40"
26    requests.memory: "80Gi"
27    pods: "150"
28    persistentvolumeclaims: "20"
29    services.loadbalancers: "3"

Ogni load balancer viene fatturato separatamente dal cloud provider e i volumi orfani continuano a essere fatturati dopo che i loro pod sono spariti.

2. Ridimensiona le richieste di CPU e memoria

Le richieste determinano il numero di nodi, e il numero di nodi determina la bolletta. La maggior parte dei cluster gira molto al di sotto della capacità per cui paga, perché le richieste sono state stimate una volta e mai più riviste. Un'analisi di 23.000 cluster di produzione su AWS, Azure e Google Cloud ha rilevato un utilizzo medio della CPU dell'8%, della memoria al 20% e della GPU al 5%. ³

Imposta le richieste di CPU vicino al 95 percentile dell'utilizzo osservato. Imposta le richieste di memoria al massimo osservato piuttosto che a un percentile, e imposta il limite di memoria uguale alla richiesta. Un percentile lascia il container a corto durante il traffico rimanente, e poiché il limite corrisponde alla richiesta, quel deficit arriva come un OOMKill piuttosto che un rallentamento.

Ometti il limite di CPU. Il throttling della CPU degrada la latenza senza uccidere il pod, e la richiesta riserva ciò di cui il workload ha bisogno.

Il Vertical Pod Autoscaler in modalità solo raccomandazione produce questi valori senza rischi per la produzione.

1resources:
2  requests:
3    cpu: 200m
4    memory: 512Mi
5  limits:
6    memory: 512Mi
7---
8apiVersion: autoscaling.k8s.io/v1
9kind: VerticalPodAutoscaler
10metadata:
11  name: payments-api
12spec:
13  targetRef:
14    apiVersion: apps/v1
15    kind: Deployment
16    name: payments-api
17  updatePolicy:
18    updateMode: "Off"

Leggi le raccomandazioni con kubectl describe vpa payments-api e confronta il valore target con la richiesta corrente.

Caso di studio reale: Tryg Insurance

Tryg Insurance è la più grande compagnia assicurativa generale della regione nordica e gestisce Kubernetes su Oracle Cloud Infrastructure. Il suo team di ingegneria ha combinato Horizontal Pod Autoscaler e Vertical Pod Autoscaler per ridimensionare dinamicamente i workload mantenendo i livelli di servizio, e ha ridotto i costi cloud di Kubernetes del 50% utilizzando solo autoscaler open source, senza alcuna piattaforma commerciale di ottimizzazione.⁴

4. Consolida i nodi con Karpenter e scala a zero i workload inattivi

Il rightsizing libera capacità, ma quella capacità rimane su nodi che continuano a girare finché qualcosa non li rimuove. Karpenter effettua il provisioning delle istanze in tempo e ricompatta i workload su un numero minore di nodi. KEDA scala a zero repliche i workload guidati da code, cosa che un Horizontal Pod Autoscaler standard non può fare.

Imposta la policy di consolidamento su WhenEmptyOrUnderutilized. L'alternativa, WhenEmpty, limita l'interruzione ai nodi che non ospitano alcun pod di workload, e questi si verificano raramente senza intervento. ⁵

1apiVersion: karpenter.sh/v1
2kind: NodePool
3metadata:
4  name: default
5spec:
6  template:
7    spec:
8      requirements:
9        - key: karpenter.sh/capacity-type
10          operator: In
11          values: ["spot", "on-demand"]
12        - key: karpenter.k8s.aws/instance-category
13          operator: In
14          values: ["c", "m", "r"]
15  disruption:
16    consolidationPolicy: WhenEmptyOrUnderutilized
17    consolidateAfter: 1m
18    budgets:
19      - nodes: "10%"
20  limits:
21    cpu: "2000"

Un elenco ristretto di istanze vanifica questo, perché Karpenter non riesce a trovare outlier economici e la resilienza allo spot diminuisce. Dovresti lasciargli scegliere tra intere famiglie di istanze.

Caso di studio reale: Adidas

Adidas gestisce più cluster Kubernetes su AWS EKS. Il suo team di platform engineering ha adottato Karpenter per il provisioning dei nodi, ha aggiunto KEDA per lo scaling event-driven, ha auto-creato oggetti Vertical Pod Autoscaler tramite policy Kyverno e ha usato kube-downscaler per gli ambienti inattivi. Hanno ridotto il costo di gestione dei cluster Kubernetes su AWS fino al 50%, utilizzando uno stack interamente open source.⁶

5. Preparati adeguatamente prima di spostare i workload su spot

Le istanze spot offrono lo sconto più ampio disponibile e l'applicabilità più ristretta. Niente dovrebbe essere spostato su spot finché PodDisruptionBudgets, diversificazione delle istanze, topology spread e gestione delle terminazioni non sono tutti in atto.

Un PodDisruptionBudget che non lascia margine blocca tutte le interruzioni volontarie, inclusa la consolidazione di Karpenter, quindi i valori devono avere un certo gioco. ⁷

1apiVersion: policy/v1
2kind: PodDisruptionBudget
3metadata:
4  name: payments-api
5spec:
6  minAvailable: 60%
7  selector:
8    matchLabels:
9      app: payments-api

Caso di studio reale: Delivery Hero

Delivery Hero gestisce 390 applicazioni in 43 paesi, con circa il 90% dei workload in esecuzione su AWS EKS. Il suo team è migrato alle istanze Spot in circa sei mesi, integrando nel processo la gestione delle terminazioni e un descheduler piuttosto che cambiare direttamente il tipo di capacità.

I costi dell'infrastruttura sono diminuiti di circa il 70%
Gli sconti spot hanno raggiunto fino al 90% rispetto ai prezzi on-demand
La piattaforma assorbe picchi di traffico pari a 4-5 volte il volume normale.⁸

6. Spegni la non produzione secondo una pianificazione

Gli ambienti di sviluppo e staging hanno poco o nessun carico durante la notte e nei fine settimana. Lo spegnimento pianificato è tecnicamente semplice e politicamente incontestato, il che lo rende il risparmio più rapido da realizzare e una prima azione utile laddove modifiche più difficili avranno bisogno di supporto in seguito.

Applica la pianificazione per impostazione predefinita ai namespace di non produzione e richiedi ai team di disattivarla esplicitamente. Una policy che richiede un'azione per aderire raggiunge meno team di una che richiede un'azione per uscirne.

1metadata:
2  annotations:
3    downscaler/uptime: "Mon-Fri 08:00-19:00 Europe/Paris"
4    downscaler/exclude: "false"

Il risparmio arriva in fattura se è attiva la consolidazione dei nodi, poiché i deployment ridotti lasciano nodi vuoti alle spalle.

Caso di studio reale: Bud Financial

Bud Financial arricchisce i dati delle transazioni finanziarie per il settore dei servizi finanziari e gestisce circa 25 cluster su Google Kubernetes Engine. Il suo team ha utilizzato pause e ripresa pianificate per ridurre i nodi del cluster durante la notte e nei fine settimana, insieme al ribilanciamento quotidiano.

I costi sono diminuiti del 47% solo grazie alla modifica della pianificazione
La pianificazione ha eliminato 80 ore di funzionamento del cluster a settimana
L'utilizzo delle risorse è salito oltre il 90%.⁹

Lascia che il nostro team automatizzi uno dei tuoi processi aziendali con agenti IA, gratuitamente.

Automatizza un processo

7. Migra i workload compatibili su ARM

Le istanze basate su ARM modificano il prezzo unitario anziché competere per la stessa capacità inattiva delle azioni precedenti, quindi questi risparmi si sommano davvero al resto. I blocchi saranno le dipendenze senza build ARM64.

Gli utenti dovrebbero valutare questo per singolo workload piuttosto che per l'intero parco, e creare immagini multi-architettura prima di pianificare qualsiasi cosa.

1nodeSelector:
2  kubernetes.io/arch: arm64

Caso di studio reale: Pinterest

Pinterest ha migrato il proprio workload web API su istanze AWS Graviton basate su ARM64, motivato sia dalla riduzione dei costi sia da quella del carbonio.

I costi sono diminuiti del 47%
Il consumo di calcolo è diminuito del 38%
Le emissioni di carbonio sono diminuite del 62%.¹⁰

8. Quando il tuning non basta più, cambia l'architettura

Le sei azioni precedenti ottimizzano i workload all'interno dei cluster esistenti. Una volta esaurite, ulteriori guadagni richiedono un cambiamento architetturale piuttosto che ulteriore tuning.

Due risultati pubblicati segnano il limite pratico. InCred Finance ha ridotto la spesa del 30% su cluster che il suo team considerava ottimizzati¹¹, e Yotpo ha ottenuto il 30–40% facendo girare l'80% dei workload su istanze spot¹². Oltre quella gamma, lo spreco rimanente non si trova più all'interno dei cluster ma nel numero di cluster. Ognuno comporta un costo per il piano di controllo e forma un'isola di scheduling che il bin-packing non può attraversare.

La multi-tenancy elimina entrambi i costi. Invece di dedicare un cluster a ogni cliente, team o ambiente, i cluster virtuali girano su infrastruttura fisica condivisa. Ogni tenant riceve il proprio server API e piano di controllo virtuale mentre i nodi sono condivisi. Questo elimina il costo del piano di controllo per cluster e consente il bin-packing attraverso il pool di nodi condiviso piuttosto che all'interno di parchi isolati.

yaml

1sync:
2  fromHost:
3    nodes:
4      enabled: false

bash

1vcluster create tenant-acme --namespace tenant-acme -f vcluster.yaml

Sono disponibili due meccanismi. I namespace sono sempre più economici, quindi la scelta si basa sulla separazione richiesta dai tenant, non sul costo.

I namespace suddividono un singolo cluster e non aggiungono un proprio piano di controllo. Sono sufficienti quando i tenant si fidano l'uno dell'altro e possono condividere un unico server API e un unico set di CRD.
I cluster virtuali danno a ogni tenant il proprio server API, in esecuzione come workload sull'host. Questo costo è giustificato in due casi: tenant che necessitano di risorse cluster-scoped proprie e requisiti di isolamento che un server API condiviso non può soddisfare.

L'immagine confronta i cluster virtuali con i cluster host.

Caso di studio reale: Atlan

Atlan è un'azienda di data catalogue che ospita la piattaforma per circa il 95% dei suoi clienti, molti nei settori sanitario e finanziario dove l'isolamento dei dati è contrattuale. Gestiva un cluster EKS completo per cliente ed è arrivata oltre 100 cluster, un parco costoso da mantenere attivo 24 ore su 24 e difficile da gestire. Dal Q1 2022 ha valutato opzioni di multi-tenancy e ha ricostruito su vCluster, offrendo a ogni cliente un cluster virtuale anziché fisico.

I cluster EKS fisici sono passati da più di 100 a 20, continuando a servire oltre 100 clienti
La spesa Kubernetes è diminuita di $600.000.¹³

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Ordine di esecuzione

I commitment stanno all'ultimo posto pur essendo l'azione più semplice. Acquistarli prima del rightsizing blocca da uno a tre anni lo spreco che il rightsizing stava per eliminare. È l'errore di sequenziamento più costoso disponibile, ed è comune perché richiede un acquisto piuttosto che lavoro di ingegneria.

L'azione 7 è una diramazione, non un passaggio. Va intrapresa una volta completate le prime sei e se il risultato è ancora insufficiente, poiché cambia quanti cluster girano piuttosto che quanto efficientemente ciascuno gira.

Il diagramma mostra come Karpenter (un autoscaler Kubernetes) consolida automaticamente i workload per ottimizzare la capacità di calcolo e ridurre i costi dell'infrastruttura cloud.

¹⁴

Strumenti per l'ottimizzazione dei costi di Kubernetes

Strumento	Modello	Passaggio strategico	Capacità FinOps	Distribuzione
CAST IA	Commerciale	S1, S3, S4, S6, S8	Ottimizzazione dell'utilizzo Architettura e posizionamento dei workload Ottimizzazione delle tariffe	SaaS control plane più agente in-cluster
CloudZero	Commerciale	S0	Fase informativa	Senza agente
Finout	Commerciale	S0	Fase informativa	Senza agente
Kubecost Enterprise by IBM	Commerciale	S0 + S2	Fase informativa Fase operativa	In-cluster
Kubex (ex Densify)	Commerciale	S1 + S6	Ottimizzazione dell'utilizzo Fase operativa	Non verificato
nOps	Commerciale	S0, S1, S4, S8	Ottimizzazione delle tariffe Ottimizzazione dell'utilizzo Fase informativa	SaaS più agente EKS leggero
PerfectScale by DoiT	Commerciale	S1 + S4	Ottimizzazione dell'utilizzo Fase operativa	Agente in-cluster
ScaleOps	Commerciale	S1 + S3	Ottimizzazione dell'utilizzo Architettura e posizionamento dei workload	Self-hosted, interamente in-cluster
Sedai	Commerciale	S1	Ottimizzazione dell'utilizzo Architettura e posizionamento dei workload	SaaS
Spot by Flexera (ex NetApp)	Commerciale	S0, S3, S4, S8	Ottimizzazione delle tariffe Architettura e posizionamento dei workload Fase informativa	SaaS

Abbiamo tracciato gli strumenti con tre o più case study pubblicati che coprono 47 dei 68 case study nel dataset:

Orizzontale: quanti case study ha ciascuno strumento, contati una volta sola.
Verticale: quante categorie distinte di casi d'uso coprono quei casi, su dieci. Uno strumento conta una volta per categoria, non importa quanto spesso vi appare, quindi le 12 menzioni separate di rightsizing di CAST IA contribuiscono 1 al suo punteggio di 10.
Dimensione della bolla: in quante delle otto fasi strategiche lo strumento compare.

Framework open source

I framework open source possono essere distribuiti per le fasi da 0 a 6. Gli utenti possiedono gli aggiornamenti, il ricambio di versioni, il costo di retention di Prometheus e le decisioni che un raccomandatore commerciale prenderebbe per loro.

Strumento	Licenza / governance	Applicazione	Prometheus	Cloud
Cluster Autoscaler	Repo Kubernetes autoscaler, Apache 2.0	Agisce entro i limiti del gruppo di nodi	Non richiesto	AWS, Azure, GCP e altri
Goldilocks (Fairwinds)	Apache 2.0	Raccomanda	Non richiesto	Qualsiasi
Horizontal Pod Autoscaler	Kubernetes core	Agisce entro i limiti che imposti	Solo per metriche personalizzate, tramite adattatore	Qualsiasi
Karpenter	CNCF, Apache 2.0	Agisce entro i limiti dei NodePool	Non richiesto	Nativo AWS; esiste un provider Azure, altri in maturazione
KEDA	CNCF Graduated, Apache 2.0	Agisce entro i limiti che imposti	Opzionale	Qualsiasi
kube-green	CNCF Sandbox	Agisce in base alla pianificazione che definisci	Non richiesto	Qualsiasi
OpenCost	CNCF Incubating (ott 2024), Apache 2.0	Osserva	Richiesto	AWS, Azure, GCP, on-prem
py-kube-downscaler	Fork community di kube-downscaler	Agisce in base ad annotazione e pianificazione	Non richiesto	Qualsiasi
Robusta KRR	MIT	Raccomanda	Richiesto	Qualsiasi
Vertical Pod Autoscaler	Repo Kubernetes autoscaler, Apache 2.0	Raccomanda in updateMode: Off, agisce in Auto	Non richiesto	Qualsiasi

Ognuno di questi possiede un campo diverso, ed è per questo che diversi girano contemporaneamente.

Robusta KRR o VPA in updateMode: "Off" produce il backlog del passaggio 1. Non scrivono nulla.
Karpenter possiede i nodi: provisioning, consolidamento, selezione delle istanze, diversificazione spot, architettura. Copre i passaggi 3, 4 e 6.
KEDA possiede il numero di repliche, incluso lo scale a zero, cosa che HPA da solo non può fare.
py-kube-downscaler o kube-green possiede la pianificazione della non produzione. Il risparmio più economico dell'elenco.
OpenCost misura continuamente e non partecipa a nulla.

Piattaforme commerciali

Ogni strumento commerciale assume una delle tre posizioni sul livello dei nodi. Quella è la decisione, e conta più del prezzo o del numero di funzionalità, perché il manifest del NodePool del passaggio 3 o sopravvive o non sopravvive.

Strumento	Applicazione	Prometheus	Cloud
CAST IA	Autonomo; sostituisce Karpenter	Non richiesto	EKS, AKS, GKE
CloudZero	Osserva	Non utilizzato	Multi-cloud
Finout	Osserva	Non utilizzato	Multi-cloud più SaaS e piattaforme dati
Kubecost Enterprise (IBM)	Osserva, raccomanda e agisce (dimensionamento automatico delle richieste, spegnimento dei namespace)	In bundle o porta il tuo	Multi-cloud, ibrido, on-prem
Kubex (ex Densify)	Prima raccomanda, poi aggiunta l'attuazione	Non verificato	Non verificato
nOps	Autonomo; ottimizza il tuo autoscaler piuttosto che sostituirlo	Esegue il proprio	Solo AWS
PerfectScale (DoiT)	Autonomo	Non verificato	EKS, AKS, GKE
ScaleOps	Autonomo dall'installazione	Richiesto, e lo esegui tu	Qualsiasi Kubernetes
Sedai	Autonomo, limitato dagli SLO	Non utilizzato	Multi-cloud, più serverless e database
Spot by Flexera	Autonomo	Non utilizzato	AWS, Azure, GCP

Lascialo stare: StormForge, PerfectScale, Sedai e Kubex ridimensionano i workload. Hanno bisogno di Karpenter o Cluster Autoscaler sotto e non lo toccano mai. L'aggiunta più sicura a una configurazione esistente.
Lavora con esso: ScaleOps aggiunge il bin packing sopra Karpenter. nOps ottimizza un Cluster Autoscaler o Karpenter esistente invece di sostituirlo con il proprio. Maggiore copertura, il provisioner resta tuo.
Sostituiscilo: CAST IA e Spot Ocean installano il proprio provisioner e scartano il manifest. Copertura più ampia, minor controllo.
Gli strumenti di visibilità stanno all'esterno: OpenCost, Kubecost, CloudZero, Vantage e Finout sono in sola lettura, quindi non entrano in conflitto con nulla e si sommano liberamente. Eseguine uno indipendentemente da cos'altro venga adottato.

Come combinare questi strumenti

La fattura si basa sui nodi in esecuzione, non sulle richieste dichiarate. Il rightsizing riduce le richieste, liberando spazio sui nodi esistenti ma senza rimuoverne alcuno, quindi la bolletta resta invariata finché uno strumento per i nodi non consolida via quello spazio. Gli strumenti per i nodi da soli falliscono per la ragione speculare: compattano qualunque richiesta venga loro data, quindi le richieste sovra-provisionate vengono compattate ancora più strettamente.

Due modi per coprire entrambi i livelli:

Due strumenti: VPA, StormForge o PerfectScale per le richieste, più Karpenter per i nodi. Più economico, e il livello dei nodi rimane sotto controllo diretto.
Una piattaforma: CAST IA, Zesty o Spot Ocean fanno entrambi in un unico prodotto. Più costoso, e il loro provisioner sostituisce Karpenter.

Cinque combinazioni di strumenti che rompono le cose:

Due ridimensionatori mutanti su un deployment: VPA in Auto insieme a StormForge, ScaleOps, PerfectScale o Zesty significa due controller che scrivono numeri diversi nello stesso campo. Un controller di ammissione mutante per workload.
Karpenter e Cluster Autoscaler su un gruppo di nodi: Entrambi effettuano il provisioning contro gli stessi pod non schedulabili, quindi il cluster finisce con circa il doppio dei nodi necessari.
VPA e HPA sulla stessa metrica: L'utilizzo sale, VPA aumenta la richiesta, l'utilizzo misurato cala perché è utilizzo su richiesta, HPA rimuove le repliche, il carico per pod sale, ripeti. Sicuro quando HPA scala su qualcosa che VPA non tocca, come la profondità della coda tramite KEDA.
Due strumenti di commitment su un account pagatore: Entrambi acquistano contro la stessa spesa scoperta, bloccando un over-commitment da uno a tre anni.
Due piattaforme complete: CAST IA, Zesty e Spot Ocean installano ciascuno il proprio provisioner e si aspettano di possederlo.

Esamina tutti i case study che abbiamo raccolto:

Strumento utilizzato	Modello dello strumento	Nome del case study	Azienda	Caso d'uso 1	Caso d'uso 2	Caso d'uso 3	Risultati ottenuti	URL di origine	Anno
Karpenter	Open Source	Modernizzazione dell'infrastruttura con Karpenter e Amazon EKS con PicPay	PicPay (fintech, Brasile)	Autoscaling dei nodi / provisioning di calcolo just-in-time su Amazon EKS	Riarchitettura di un singolo cluster da 900 nodi in 121 cluster	Ottimizzazione delle istanze Spot con consolidamento spot-to-spot (100% di non prod, 40% di prod)	Oltre 50% di riduzione dei costi mensili; 100% di aumento della base clienti; 35M utenti attivi; 90% di riduzione dei ticket di supporto mensili; tempo di aggiornamento del cluster ridotto da 3 settimane a 2 ore	https://aws.amazon.com/solutions/case-studies/picpay-eks-case-study	2023
Karpenter	Open Source	L'azienda di IA Anthropic ha ridotto la sua bolletta AWS del 40% usando Karpenter	Anthropic (ricerca IA)	Autoscaling dei nodi per workload di training, dati e inferenza su EKS	Selezione flessibile dei tipi di istanza tra molte famiglie	Utilizzo di istanze spot, sostituendo Cluster Autoscaler	Riduzione dei costi del 40% rispetto alle istanze on-demand (dichiarato dal lead engineer Nova DasSarma a AWS re:Invent)	https://www.thestack.technology/aws-anthropic-cloud-bill-eks-karpenter/	2023
Karpenter	Open Source	Come Grover risparmia sui costi con l'80% di Spot in produzione usando Karpenter con Amazon EKS	Grover (noleggio tecnologico, Berlino)	Migrazione da Cluster Autoscaler + gruppi di nodi gestiti a Karpenter	Combinazione di Spot e on-demand tramite NodePools (KEDA attiva HPA, Karpenter aggiunge capacità)	Consolidamento dei nodi e NodePools dedicati per monitoraggio e GPU	Utilizzo di Spot superiore del 25% su tutti i cluster EKS senza impatto sulle prestazioni; ~80% di Spot in produzione	https://aws.amazon.com/blogs/containers/how-grover-saves-costs-with-80-spot-in-production-using-karpenter-with-amazon-eks/	2024
Karpenter	Open Source	Miro guida l'ipercrescita con Amazon EKS, riducendo i costi dell'80%	Miro (collaborazione visiva SaaS)	Autoscaling dei nodi su EKS con NodePools Karpenter su tre AZ	Selezione dinamica Spot / Graviton / x86 in base al requisito del workload	Scaling dei pod KEDA, assorbendo da poche centinaia di nodi durante la notte a migliaia durante il giorno	Riduzione dei costi dell'80% rispetto ai container self-managed; un ulteriore 70% per la non produzione e 50% per i workload di produzione specificamente tramite Karpenter; 15-20 cluster EKS	https://aws.amazon.com/solutions/case-studies/miro-eks-case-study/	2024
Vertical Pod Autoscaler (VPA)	Open Source	Riduzione dei costi cloud dei cluster Kubernetes (blog di ingegneria adidas)	adidas (abbigliamento / e-commerce)	Generazione predefinita di VPA guidata da policy tramite Kyverno per tutti i workload di dev e staging	Rightsizing delle richieste di risorse (minAllowed 10m CPU / 32MB, maxAllowed limitato all'originale)	Combinato con Karpenter e kube-downscaler sulla piattaforma	Riduzione del 30% dell'utilizzo di CPU e memoria tra i cluster di dev e staging; fino al 50% di riduzione dei costi mensili per quei cluster. Limiti documentati: VPA non può essere combinato con HPA sulle metriche delle risorse; le app Java con heap fisso non traggono beneficio	https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669	2024
Cluster Autoscaler	Open Source	Caso di studio Pinterest (kubernetes.io)	Pinterest (social / contenuti)	Scalabilità on-demand dell'infrastruttura di build Jenkins su Kubernetes	Recupero della capacità fuori picco invece di provisioning per il picco	N/D	Recuperato oltre l'80% della capacità durante le ore non di picco; 30% in meno di ore-istanza al giorno rispetto al precedente cluster statico	https://kubernetes.io/case-studies/pinterest/	2018
KEDA	Open Source	Viaggio verso KEDA: ottimizzazione dello scaling dei worker Airflow in Kubernetes	TRM Labs (analisi blockchain)	Autoscaling event-driven dei worker Apache Airflow su GKE (migrato da Cloud Composer)	Scale-to-zero durante le ore fuori picco	Gestione del carico di picco per oltre 150.000 task giornalieri per ambiente	~50% di riduzione dei costi del pool di nodi worker tramite ~50% in meno di worker nell'arco di 24h, con prestazioni SLO mantenute	https://www.trmlabs.com/resources/blog/journey-to-keda-optimizing-airflow-worker-scaling-in-kubernetes	2024
kube-green	Open Source	Adottatori	Molteplici adottatori nominati, tra cui Supertext	Spegnimento pianificato dei namespace di non produzione durante la notte e nei fine settimana	Riduzione della spesa AWS / GCP dell'account di sviluppo	Riduzione di CO2 / sostenibilità	Un adottatore segnala un risparmio del 40% della bolletta mensile AWS (~10k pod in 3 cluster); un altro oltre il 20% della bolletta mensile GCP; un altro oltre il 30% delle risorse	https://kube-green.dev/docs/adopters/	2026
kube-green	Open Source	Nuovi adottatori per kube-green (Step4Business)	Step4Business (fintech)	Spegnimento di tutti gli ambienti di sviluppo nelle notti e nei fine settimana	Riduzione delle emissioni di CO2	N/D	IT Manager Lorenzo De Francesco: risparmiato più del 30% dei costi, oltre a un migliore equilibrio lavoro-vita privata per gli sviluppatori; kube-green riduce la CO2 di ~30% in media	https://www.innovationinbusiness.com/new-adopters-for-kube-green/	2023
py-kube-downscaler	Open Source	Riduzione dei costi cloud dei cluster Kubernetes (blog di ingegneria adidas)	adidas (abbigliamento / e-commerce)	Scale-down pianificato dei workload di non produzione fuori dall'orario lavorativo	N/D	N/D	Componente contribuente dello stack adidas (VPA + Karpenter + kube-downscaler) segnalato per un taglio dei costi dev/staging fino al 50%.	https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669	2024

Ulteriori letture sui costi del cloud

Leggi di più per padroneggiare il posizionamento dei pod e ridurre la spesa per il calcolo cloud:

Cita questa ricerca

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

Hazal Şimşek (2026) - "Ottimizzazione dei costi di Kubernetes: 8 passaggi e 23 strumenti". Pubblicato online su AIMultiple.com. Consultato il 18 settembre 2026, da: https://aimultiple.com/kubernetes-cost-optimization [Risorsa online]

Şimşek, H. (2026, 18 settembre). Ottimizzazione dei costi di Kubernetes: 8 passaggi e 23 strumenti. AIMultiple. https://aimultiple.com/kubernetes-cost-optimization

@misc{simsek2026,
  author = {Şimşek, Hazal},
  title  = {{Ottimizzazione dei costi di Kubernetes: 8 passaggi e 23 strumenti}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
  note   = {AIMultiple. Consultato il 18 settembre 2026}
}

Scarica tutti i dati

Risultati e timestamp di 249 punti dati. Scarica i dati di sintesi mostrati nei grafici e nelle tabelle di questo articolo come file ZIP contenente 6 file CSV.

Ultimo aggiornamento: 18 settembre 2026

Scarica

Vuoi i dati granulari che ci stanno dietro? Passa a Premium

Collegamenti di riferimento

https://hs-20518613.f.hubspotemail.net/hubfs/20518613/Spectro%20Cloud%202025%20State%20of%20Production%20Kubernetes.pdf

Resource Quotas | Kubernetes

2026 Kubernetes Optimization: Data & Best Practices - Cast AI

Cast AI

How Tryg Insurance saved 50% of Kubernetes cloud costs: Patterns for dynamic right-sizing of Kubernetes | cloud-infrastructure

Disruption | Karpenter

https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669

Disruptions | Kubernetes

Spot Instances at Delivery Hero | Delivery Hero Tech

Bud Achieved 90%+ Utilization and Higher Engineering Productivity – Cast AI

Cast AI

10.

How potential performance upside with AWS Graviton helps reduce your costs further | AWS Compute Blog

11.

InCred Finance Unlocked 30% Cost Savings in Kubernetes Clusters – Cast AI

Cast AI

12.

Yotpo Kubernetes Optimization Case Study - Cast AI

Cast AI

13.

How Atlan Reduced Their Infrastructure From 100 Kubernetes Clusters To 1 Using vCluster

vCluster

14.

Save up to 60% on AWS costs with EKS and Karpenter - Qovery Blog

Qovery

Hazal Şimşek

Analista di settore

Segui

Hazal è analista di settore presso AIMultiple e si occupa di process intelligence (incluso il process mining) e automazione aziendale (inclusa l'automazione IT e l'automazione low-code/no-code).

Visualizza il profilo completo