Approfondimento

Ottimizzazione dei costi di Kubernetes: 8 passaggi, 23 strumenti e casi di studio

aggiornato il 18 set. 2026

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

Abbiamo raccolto 68 casi di studio sull'ottimizzazione dei costi di Kubernetes e mappato ogni caso d'uso citato al 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 dei cluster e il confronto degli strumenti per l'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 acquisita prima della prima modifica, non c'è modo di sapere 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 è più importante 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 aspetti:

Richieste rispetto a CPU e memoria effettivamente utilizzate, per carico di lavoro. Il divario è il tuo backlog del passaggio 1, ordinato per dimensione.
Costo per namespace e per carico di lavoro. È ciò che rende le quote del passaggio 2 una negoziazione piuttosto che un'imposizione.
Efficienza del bin-packing, allocabile rispetto a richiesto per nodo. 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 nell'arco di almeno un ciclo aziendale completo. Sette giorni sono il minimo e trenta sono meglio. La finestra non è cautela procedurale. Il passaggio 1 imposta le richieste di memoria al massimo osservato e un massimo osservato è valido solo quanto la finestra che lo ha osservato. Un massimo rilevato su 48 ore perde 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 minimo gratuito. Il piano gratuito di Kubecost avvolge 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 invece di sostituirlo.

Entrambi gli strumenti di costo attribuiscono i costi tramite etichette, 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 qui sotto indica la raccomandazione, il metodo, la configurazione e un'azienda che ha adottato quel passaggio. Ogni caso di studio e ogni statistica include un link alla fonte.

2. Imposta le quote dei namespace come guardrail

I risparmi decadono quando i team distribuiscono nuovi carichi di lavoro senza richieste specificate. Un LimitRange fornisce richieste predefinite ai container che le omettono e una ResourceQuota limita ciò che un namespace può consumare complessivamente.

Distribuisci il LimitRange prima della ResourceQuota. Una volta che una quota vincola una risorsa, qualsiasi pod senza una richiesta per quella risorsa viene rifiutato in fase di ammissione, quindi l'ordine inverso blocca le distribuzioni.²

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 la scomparsa dei relativi pod.

2. Ridimensiona le richieste di CPU e memoria

Le richieste determinano il conteggio dei nodi e il conteggio dei 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 di CPU pari al 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 anziché a un percentile e imposta il limite di memoria uguale alla richiesta. Un percentile lascia il container a corto di risorse durante il traffico rimanente e, poiché il limite coincide con la richiesta, quella carenza si presenta come OOMKill invece che come rallentamento.

Ometti il limite di CPU. Il throttling della CPU degrada la latenza senza arrestare il pod e la richiesta riserva già ciò di cui il carico di lavoro ha bisogno.

Il Vertical Pod Autoscaler in modalità solo raccomandazione produce queste cifre 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 attuale.

Caso di studio reale: Tryg Insurance

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

4. Consolida i nodi con Karpenter e scala a zero i carichi di lavoro inattivi

Il rightsizing libera capacità, ma quella capacità resta su nodi che continuano a funzionare finché qualcosa non li rimuove. Karpenter effettua il provisioning delle istanze just-in-time e ricompatta i carichi di lavoro su meno nodi. KEDA scala i carichi di lavoro guidati da code fino a zero repliche, cosa che un Horizontal Pod Autoscaler standard non può fare.

Imposta la policy di consolidamento su WhenEmptyOrUnderutilized. L'alternativa, WhenEmpty, limita la disruption ai nodi che non ospitano affatto pod di carico di lavoro, 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 spot diminuisce. Dovresti lasciarlo scegliere tra intere famiglie di istanze.

Caso di studio reale: Adidas

Adidas esegue 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 basato sugli eventi, ha automaticamente creato oggetti Vertical Pod Autoscaler tramite policy Kyverno e ha usato kube-downscaler per gli ambienti inattivi. Ha ridotto il costo di esecuzione dei propri cluster Kubernetes su AWS fino al 50%, usando uno stack interamente open source.⁶

5. Preparati adeguatamente prima di spostare i carichi di lavoro su spot

Le istanze spot offrono lo sconto più ampio disponibile e l'applicabilità più ristretta. Niente dovrebbe passare a spot finché PodDisruptionBudget, diversificazione delle istanze, topology spread e gestione della terminazione non sono tutti in atto.

Un PodDisruptionBudget che non lascia margine blocca tutta la disruption volontaria, incluso il consolidamento di Karpenter, quindi i valori devono avere un margine. ⁷

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 carichi di lavoro eseguiti su AWS EKS. Il loro team è migrato alle istanze Spot in circa sei mesi, integrando nel processo la gestione della terminazione e un descheduler, invece di cambiare direttamente 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 da 4 a 5 volte il volume normale.⁸

6. Spegni gli ambienti non di 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 incontestato a livello politico, il che lo rende il risparmio più rapido da realizzare e una prima azione utile dove modifiche più difficili avranno bisogno di supporto in seguito.

Applica la pianificazione per impostazione predefinita a tutti i namespace non di 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 uscire.

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

Il risparmio arriva alla fattura solo se il consolidamento dei nodi è già in esecuzione, perché i deployment ridotti lasciano dietro di sé nodi vuoti.

Caso di studio reale: Bud Financial

Bud Financial arricchisce i dati delle transazioni finanziarie per il settore dei servizi finanziari ed esegue circa 25 cluster su Google Kubernetes Engine. Il suo team ha usato pause e ripristino pianificati per ridurre i nodi del cluster durante la notte e nei fine settimana, insieme a un 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 sopra il 90%.⁹

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

Automatizza un processo

7. Migra i carichi di lavoro compatibili su ARM

Le istanze basate su ARM cambiano il prezzo unitario invece di competere per la stessa capacità inattiva delle azioni precedenti, quindi questi risparmi si sommano davvero agli altri. Gli ostacoli saranno le dipendenze senza build ARM64.

Gli utenti dovrebbero valutare questo per carico di lavoro anziché 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 suo carico di lavoro API web su istanze AWS Graviton basate su ARM64, motivato sia dalla riduzione dei costi sia da quella delle emissioni di 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 architettura

Le sei azioni precedenti ottimizzano i carichi di lavoro all'interno dei cluster esistenti. Una volta esaurite, ulteriori guadagni richiedono un cambiamento architetturale invece di ulteriore tuning.

Due risultati pubblicati segnano il limite pratico. InCred Finance ha ridotto la spesa del 30% su cluster che il suo team già considerava ottimizzati¹¹, e Yotpo ha ottenuto 30–40% pur eseguendo già l'80% dei carichi di lavoro su istanze spot¹². Oltre quell'intervallo, lo spreco rimanente non si trova più all'interno dei cluster, ma nel numero di cluster. Ognuno comporta un costo per il control plane e forma un'isola di scheduling che il bin-packing non può attraversare.

Il multi-tenancy elimina entrambi i costi. Invece di dedicare un cluster a ogni cliente, team o ambiente, i cluster virtuali girano su un'infrastruttura fisica condivisa. Ogni tenant riceve il proprio API server e control plane virtuale mentre i nodi sono condivisi. Questo elimina il costo del control plane per cluster e consente il bin-packing nell'intero pool di nodi condiviso invece che all'interno di ambienti 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 va fatta in base alla separazione richiesta dai tenant, non al costo.

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

¹³

Caso di studio reale: Atlan

Atlan è un'azienda di data catalogue che ospita la piattaforma per circa il 95% dei suoi clienti, molti in ambito sanitario e finanziario dove l'isolamento dei dati è contrattuale. Gestiva un intero cluster EKS per cliente e ha superato i 100 cluster, un parco costoso da eseguire 24 ore su 24 e difficile da mantenere. Dal primo trimestre 2022 ha valutato opzioni di multi-tenancy e ha ricostruito su vCluster, assegnando a ogni cliente un cluster virtuale anziché fisico.

I cluster EKS fisici sono scesi da più di 100 a 20, continuando a servire più di 100 clienti
La spesa per Kubernetes è diminuita di 600.000 dollari.¹⁴

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 vengono per ultimi nonostante siano 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 sequenza più costoso disponibile ed è comune perché richiede un acquisto invece di lavoro di ingegneria.

L'azione 7 è una diramazione, non un passaggio. Va intrapresa solo dopo che le prime sei sono complete e il risultato è ancora insufficiente, poiché cambia quanti cluster vengono eseguiti invece di quanto efficientemente ciascuno viene eseguito.

¹⁵

Strumenti per l'ottimizzazione dei costi di Kubernetes

Strumento	Modello	Passaggio della strategia	Capacità FinOps	Distribuzione
CAST IA	Commerciale	S1, S3, S4, S6, S8	Ottimizzazione dell'utilizzo Architettura e posizionamento dei carichi di lavoro Ottimizzazione delle tariffe	SaaS control plane più agente in-cluster
CloudZero	Commerciale	S0	Fase di informazione	Senza agente
Finout	Commerciale	S0	Fase di informazione	Senza agente
Kubecost Enterprise by IBM	Commerciale	S0 + S2	Fase di informazione Fase operativa	Nel cluster
Kubex (precedentemente Densify)	Commerciale	S1 + S6	Ottimizzazione dell'utilizzo Fase operativa	Non verificato
nOps	Commerciale	S0, S1, S4, S8	Ottimizzazione delle tariffe Ottimizzazione dell'utilizzo Fase di informazione	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 carichi di lavoro	Self-hosted, interamente nel cluster
Sedai	Commerciale	S1	Ottimizzazione dell'utilizzo Architettura e posizionamento dei carichi di lavoro	SaaS
Spot by Flexera (precedentemente NetApp)	Commerciale	S0, S3, S4, S8	Ottimizzazione delle tariffe Architettura e posizionamento dei carichi di lavoro Fase di informazione	SaaS

Abbiamo rappresentato gli strumenti con tre o più casi di studio pubblicati che coprono 47 dei 68 casi di studio nel dataset:

Orizzontale: quanti casi di studio ha ogni strumento, contati una volta ciascuno.
Verticale: quante categorie di casi d'uso distinte coprono quei casi, su dieci. Uno strumento conta una volta per categoria, indipendentemente da quanto spesso vi compare, quindi le 12 menzioni separate di rightsizing di CAST IA contribuiscono con 1 al suo punteggio di 10.
Dimensione della bolla: in quanti degli otto stadi della strategia compare lo strumento.

Framework open source

I framework open source possono essere adottati per gli stadi da 0 a 6. Gli utenti si fanno carico degli aggiornamenti, del turnover di versione, della bolletta di retention di Prometheus e delle decisioni che un recommender commerciale prenderebbe al posto loro.

Strumento	Licenza / governance	Applicazione	Prometheus	Cloud
Cluster Autoscaler	Repository Kubernetes autoscaler, Apache 2.0	Agisce entro i confini del node group	Non richiesto	AWS, Azure, GCP e altri
Goldilocks (Fairwinds)	Apache 2.0	Raccomanda	Non richiesto	Qualsiasi
Horizontal Pod Autoscaler	Nucleo di Kubernetes	Agisce entro i limiti che imposti	Solo per metriche personalizzate, tramite adapter	Qualsiasi
Karpenter	CNCF, Apache 2.0	Agisce entro i confini del 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 su annotazioni e pianificazione	Non richiesto	Qualsiasi
Robusta KRR	MIT	Raccomanda	Richiesto	Qualsiasi
Vertical Pod Autoscaler	Repository Kubernetes autoscaler, Apache 2.0	Raccomanda in updateMode: Off, agisce in Auto	Non richiesto	Qualsiasi

Ognuno di questi presidia 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 gestisce i nodi: provisioning, consolidamento, selezione delle istanze, diversificazione spot, architettura. Copre i passaggi 3, 4 e 6.
KEDA gestisce il numero di repliche, incluso lo scale-to-zero, cosa che il solo HPA non può fare.
py-kube-downscaler o kube-green gestisce la pianificazione della non produzione. Il risparmio più economico dell'elenco.
OpenCost misura in modo continuo e non partecipa a nulla.

Piattaforme commerciali

Ogni strumento commerciale assume una di 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 usato	Multi-cloud
Finout	Osserva	Non usato	Multi-cloud più SaaS e piattaforme di dati
Kubecost Enterprise (IBM)	Osserva, raccomanda e agisce (dimensionamento automatico delle richieste, namespace turndown)	In bundle o porta il tuo	Multi-cloud, ibrido, on-prem
Kubex (precedentemente Densify)	Prima raccomanda, poi è stata aggiunta l'attuazione	Non verificato	Non verificato
nOps	Autonomo; mette a punto il tuo autoscaler invece di 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, vincolato dagli SLO	Non usato	Multi-cloud, più serverless e database
Spot by Flexera	Autonomo	Non usato	AWS, Azure, GCP

Lascialo stare: StormForge, PerfectScale, Sedai e Kubex si limitano al rightsizing dei carichi di lavoro. Richiedono Karpenter o Cluster Autoscaler sotto e non li toccano mai. È l'aggiunta più sicura a una configurazione esistente.
Lavora con esso: ScaleOps aggiunge il bin packing sopra Karpenter. nOps mette a punto 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. La copertura più ampia, il minor controllo.
Gli strumenti di visibilità stanno all'esterno: OpenCost, Kubecost, CloudZero, Vantage e Finout si limitano a leggere, quindi non entrano in conflitto con nulla e si possono sommare 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, il che libera spazio sui nodi esistenti ma non ne rimuove nessuno, quindi la bolletta resta invariata finché uno strumento per i nodi non consolida quello spazio. Gli strumenti per i soli nodi falliscono per la ragione speculare: compattano qualunque richiesta ricevano, quindi richieste sovradimensionate vengono semplicemente compattate 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 resta 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 rightsizer mutanti su un unico deployment: VPA in Auto insieme a StormForge, ScaleOps, PerfectScale o Zesty significa due controller che scrivono numeri diversi sullo stesso campo. Un solo admission controller mutante per carico di lavoro.
Karpenter e Cluster Autoscaler su un unico node group: entrambi effettuano il provisioning per 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 alza la richiesta, l'utilizzo misurato scende perché è uso diviso richiesta, HPA rimuove repliche, il carico per pod sale, e si ripete. È sicuro quando l'HPA scala su qualcosa che VPA non tocca, come la profondità della coda tramite KEDA.
Due strumenti di commitment sullo stesso account pagatore: entrambi acquistano per la stessa spesa non coperta, bloccando un over-commitment da uno a tre anni.
Due piattaforme complete: CAST IA, Zesty e Spot Ocean installano ciascuna il proprio provisioner e ciascuna si aspetta di possederlo.

Esamina tutti i casi di studio che abbiamo raccolto:

Strumento utilizzato	Modello dello strumento	Nome del caso di studio	Azienda	Caso d'uso 1	Caso d'uso 2	Caso d'uso 3	Risultati ottenuti	URL sorgente	Anno
Karpenter	Open source	Modernizzare l'infrastruttura con Karpenter e Amazon EKS con PicPay	PicPay (fintech, Brasile)	Autoscaling dei nodi / provisioning di calcolo just-in-time su Amazon EKS	Riprogettare un singolo cluster da 900 nodi in 121 cluster	Ottimizzazione delle istanze Spot con consolidamento spot-to-spot (100% della non produzione, 40% della produzione)	Oltre il 50% di riduzione dei costi mensili; aumento del 100% della base clienti; 35M utenti attivi; riduzione del 90% 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 bolletta AWS del 40% con Karpenter	Anthropic (ricerca sull'IA)	Autoscaling dei nodi per carichi di lavoro di addestramento, dati e inference su EKS	Selezione flessibile dei tipi di istanza tra molte famiglie	Utilizzo di istanze spot, in sostituzione di Cluster Autoscaler	Riduzione dei costi del 40% rispetto alle istanze on-demand (dichiarato dalla lead engineer Nova DasSarma ad 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 + node group gestiti a Karpenter	Mixing di spot e on-demand tramite NodePool (KEDA attiva HPA, Karpenter aggiunge capacità)	Consolidamento dei nodi e NodePool dedicati per monitoraggio e GPU	Utilizzo di spot superiore del 25% su tutti i cluster EKS senza impatto sulle prestazioni; circa 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 NodePool Karpenter su tre AZ	Selezione dinamica Spot / Graviton / x86 in base ai requisiti del carico di lavoro	Scalabilità dei pod con KEDA, assorbendo da poche centinaia di nodi durante la notte a migliaia di giorno	Riduzione dei costi dell'80% rispetto ai container autogestiti; un ulteriore 70% per la non produzione e 50% per i carichi di lavoro 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	Ridurre i costi cloud dei cluster Kubernetes (blog di ingegneria di adidas)	adidas (abbigliamento / e-commerce)	Generazione predefinita di VPA guidata da policy tramite Kyverno per tutti i carichi di lavoro dev e staging	Ridimensionamento delle richieste di risorse (minAllowed 10m CPU / 32MB, maxAllowed limitato al valore originale)	Combinato con Karpenter e kube-downscaler su tutta la piattaforma	Riduzione del 30% nell'uso di CPU e memoria nei cluster dev e staging; riduzione dei costi mensili fino al 50% per quei cluster. Limiti documentati: VPA non può essere combinato con HPA su metriche di 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	Recuperare la capacità nei periodi di basso carico invece di effettuare il provisioning per il picco	N/A	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: ottimizzare lo scaling dei worker Airflow in Kubernetes	TRM Labs (analisi blockchain)	Autoscaling basato su eventi dei worker Apache Airflow su GKE (migrati da Cloud Composer)	Scale-to-zero durante le ore non di picco	Gestione del carico di picco per oltre 150.000 task giornalieri per ambiente	Riduzione di circa il 50% dei costi del pool di nodi worker tramite circa il 50% di worker in meno 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	Adottanti	Diversi adottanti nominati, tra cui Supertext	Spegnimento programmato dei namespace non di produzione durante la notte e nei fine settimana	Riduzione della spesa AWS / GCP per gli account di sviluppo	Riduzione di CO2 / sostenibilità	Un adottante segnala un risparmio del 40% della bolletta AWS mensile (circa 10k pod su 3 cluster); un altro oltre il 20% sulla bolletta GCP mensile; un altro più del 30% delle risorse	https://kube-green.dev/docs/adopters/	2026
kube-green	Open source	Nuovi adottanti per kube-green (Step4Business)	Step4Business (fintech)	Spegnere tutti gli ambienti di sviluppo di notte e nei fine settimana	Riduzione delle emissioni di CO2	N/A	IT Manager Lorenzo De Francesco: ha risparmiato più del 30% dei costi, oltre a migliorare l'equilibrio vita-lavoro degli sviluppatori; kube-green riduce la CO2 di circa il 30% in media	https://www.innovationinbusiness.com/new-adopters-for-kube-green/	2023
py-kube-downscaler	Open source	Ridurre i costi cloud dei cluster Kubernetes (blog di ingegneria di adidas)	adidas (abbigliamento / e-commerce)	Riduzione programmata dei carichi di lavoro non di produzione fuori dall'orario lavorativo	N/A	N/A	Componente del piano adidas (VPA + Karpenter + kube-downscaler) che ha contribuito a un taglio dei costi dev/staging fino al 50%.	https://medium.com/adidoescode/reducing-cloud-costs-of-kubernetes-clusters-c8c1e3bdb669	2024

Letture aggiuntive

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

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, 23 strumenti e casi di studio". 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, 23 strumenti e casi di studio. AIMultiple. https://aimultiple.com/kubernetes-cost-optimization

@misc{simsek2026,
  author = {Şimşek, Hazal},
  title  = {{Ottimizzazione dei costi di Kubernetes: 8 passaggi, 23 strumenti e casi di studio}},
  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 114 punti dati. Scarica i dati di sintesi mostrati nei grafici e nelle tabelle di questo articolo come file ZIP contenente 4 file CSV.

Ultimo aggiornamento: 3 ottobre 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.

Page restricted | ScienceDirect

14.

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

vCluster

15.

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