TL;DR
Kubernetes in sé è gratuito. A costare è tutto ciò che gli sta intorno: il control plane gestito, i worker node, lo storage e il networking.
Ecco cosa c'è da sapere:
- Tariffa del control plane: AWS EKS e Google GKE applicano circa $0,10/ora (~$73/mese) per cluster. Azure AKS costa $73/mese per la produzione. DigitalOcean non addebita nulla per il control plane
- Principale voce di costo: i worker node (VM), da cui deriva la maggior parte della spesa
- Tier gratuito di GKE: un cluster zonale o Autopilot gratuito al mese (credito di ~$74,40)
- Le opzioni serverless come GKE Autopilot e AWS Fargate fatturano in base alle risorse consumate dai pod, non ai nodi
- I modi migliori per ridurre i costi: applicare il right-sizing alle richieste di CPU e memoria, usare l'autoscaling, eseguire istanze Spot per i workloads non critici e definire budget per namespace e team
Più cluster si eseguono, più velocemente si accumulano le tariffe del control plane: un fattore da considerare prima di separare gli ambienti.
Che cosa si intende per prezzi di Kubernetes?
Kubernetes è una piattaforma gratuita e open source, ma molte organizzazioni scelgono soluzioni Kubernetes gestite, in genere nel cloud, per ridurre la complessità operativa. I prezzi del Kubernetes gestito prevedono di norma una tariffa di gestione di $0,10/ora ($73–$74/mese) per cluster sui principali cloud provider (AWS EKS, Google GKE, Azure AKS), a cui si aggiungono i costi di worker node (VM), storage e networking (traffico dati in uscita). GKE offre un tier gratuito, mentre alternative come DigitalOcean Kubernetes non applicano la tariffa del control plane e fatturano solo le risorse.
Componenti principali dei prezzi:
- Tariffa di gestione del cluster: i principali cloud (EKS, GKE, AKS) applicano in genere $0,10 per cluster all'ora per il control plane.
- Worker node (compute): si pagano le VM sottostanti (EC2, GCE, VM Azure) utilizzate dalle applicazioni, con costi che dipendono dai requisiti di CPU/RAM.
- Storage e networking: lo storage persistente (EBS, Persistent Disk) e il traffico dati in uscita comportano costi aggiuntivi.
In sintesi per provider:
- Amazon EKS: il supporto standard costa $0,10 per cluster all'ora; l'Extended Support comporta un costo aggiuntivo di $0,50/ora.
- Google GKE: offre un tier gratuito con $74,40 di crediti mensili (un cluster zonale o Autopilot).
- Azure AKS: la gestione del cluster è gratuita; si pagano solo nodi e risorse.
- DigitalOcean (DOKS): piano di gestione gratuito; i nodi partono da $12/mese.
Strategie di ottimizzazione dei costi:
- Right-sizing delle richieste di CPU e memoria: scegliere le dimensioni di VM appropriate per evitare l'overprovisioning
- Usare il Cluster Autoscaler o il provisioning in stile Karpenter: aggiungere o rimuovere automaticamente nodi in base ai pod in attesa e alla domanda dei workloads, per non pagare capacità inattiva.
- Usare l'autoscaling orizzontale e verticale dei pod: scalare le repliche dei pod o regolare le richieste di CPU/memoria in base all'utilizzo reale anziché a stime di picco fisse.
- Usare con attenzione le istanze Spot o preemptible: sfruttare le AWS Spot Instances o le VM preemptible di GCP per i workloads non critici, con risparmi fino al 90% sul compute.
- Definire budget per namespace e team: usare quote, label e strumenti di cost allocation per monitorare la spesa per team o ambiente e prevenire costi fuori controllo.
In questo articolo:
- Quali sono i principali modelli operativi e di costo di Kubernetes
- Quali fattori influenzano i prezzi del Kubernetes gestito?
- Prezzi di Kubernetes per cloud provider
- Strategie di ottimizzazione dei costi di Kubernetes
Quali sono i principali modelli operativi e di costo di Kubernetes
Kubernetes autogestito
Il Kubernetes autogestito prevede il deployment e la manutenzione dei propri cluster, on-premises o su macchine virtuali nel cloud. Con questo approccio, l'organizzazione è responsabile del provisioning dell'infrastruttura di compute, dell'installazione di Kubernetes, della configurazione di networking e storage e della gestione delle attività operative come aggiornamenti, scalabilità e troubleshooting. I costi principali derivano dall'hardware o dalle macchine virtuali sottostanti, dai dispositivi di storage, dalla larghezza di banda di rete e dai software o strumenti integrati per monitoraggio, sicurezza o backup.
L'overhead operativo è un aspetto rilevante del Kubernetes autogestito. Serve un team con le competenze per gestire il ciclo di vita del cluster, applicare le patch di sicurezza e garantire l'alta disponibilità. Sebbene questo modello offra flessibilità e controllo, spesso comporta un costo totale di proprietà più elevato, a causa del maggiore impegno di personale e dei potenziali downtime dovuti a errori di configurazione o guasti. Per le organizzazioni con requisiti di conformità rigorosi o esigenze infrastrutturali specifiche, il Kubernetes autogestito può essere necessario, ma è importante considerare sia i costi diretti sia quelli indiretti.
Kubernetes gestito nel cloud
I servizi Kubernetes gestiti, come Amazon EKS, Google Kubernetes Engine, Azure Kubernetes Service e DigitalOcean Kubernetes, offrono una gestione automatizzata dei cluster che include provisioning, aggiornamenti, patch e monitoraggio. Questi servizi riducono la complessità operativa, permettendo ai team di concentrarsi sul deployment e sulla gestione dei workloads invece che sull'infrastruttura sottostante. I cloud provider addebitano in genere una tariffa di gestione per cluster o control plane, oltre ai costi delle risorse di compute, storage e networking consumate dai workloads.
Il vantaggio principale del Kubernetes gestito è la riduzione del carico operativo e la maggiore rapidità di deployment. Tuttavia, i prezzi possono variare tra i provider e includere costi aggiuntivi per funzionalità come autoscaling, networking avanzato e osservabilità integrata. Pur semplificando le operazioni sui cluster, i servizi gestiti possono imporre limitazioni alla configurazione e alla personalizzazione. Le organizzazioni dovrebbero esaminare il modello di prezzo e le funzionalità di ciascun provider per verificarne l'allineamento con i requisiti operativi e di budget.
Kubernetes serverless o Autopilot
Le offerte Kubernetes serverless o Autopilot, come Google Kubernetes Engine Autopilot o AWS Fargate per EKS, astraggono la gestione dell'infrastruttura. In questi modelli, il cloud provider gestisce sia il control plane sia i worker node, e la fatturazione si basa sulle risorse consumate dai workloads anziché su una capacità fissa dei nodi. Questo approccio pay-as-you-go può ridurre gli sprechi eliminando le risorse sottoutilizzate e semplificando la scalabilità dei cluster.
Sebbene il Kubernetes serverless possa ridurre i costi dei workloads variabili, spesso ha un prezzo maggiorato rispetto ai servizi gestiti tradizionali. Possono esserci limitazioni nelle funzionalità supportate, nella personalizzazione e nell'integrazione con alcuni strumenti di terze parti. Inoltre, i workloads con pattern di utilizzo prevedibili e costanti potrebbero non registrare differenze di costo significative. Le organizzazioni dovrebbero analizzare le caratteristiche dei workloads e i calcolatori di prezzo dei provider per valutare se un modello serverless o Autopilot risponde alle loro esigenze.
Quali fattori influenzano i prezzi del Kubernetes gestito?
Costi di compute
I costi di compute rappresentano la quota maggiore delle spese di Kubernetes. Sono determinati dal tipo e dal numero di macchine virtuali o server fisici usati come worker node nel cluster. I prezzi variano in base alle specifiche di CPU, memoria e talvolta GPU, oltre che al cloud provider o all'hardware on-premises. Per i cluster nel cloud, i costi possono oscillare in funzione delle famiglie di istanze, dei commitments su istanze riservate e dell'uso di istanze on-demand, Spot o preemptible.
Gestire le risorse di compute è fondamentale per tenere sotto controllo i costi di Kubernetes. L'overprovisioning genera sprechi di spesa, mentre l'underprovisioning può causare problemi di prestazioni. Gli strumenti di autoscaling e right-sizing aiutano ad allineare l'allocazione delle risorse alla domanda dei workloads. Le organizzazioni dovrebbero monitorare l'utilizzo dei nodi e regolare le configurazioni per evitare spese superflue, garantendo al contempo l'affidabilità delle applicazioni.
Tariffe del control plane
Il control plane gestisce scheduling, scalabilità e orchestrazione dei workloads. I servizi Kubernetes gestiti applicano in genere una tariffa per il funzionamento del control plane, che può essere un canone mensile fisso per cluster o basata sull'utilizzo. Questa tariffa copre i costi sostenuti dal provider per gestire e mantenere l'API server di Kubernetes, il database etcd e gli altri componenti fondamentali per il funzionamento del cluster.
Le tariffe del control plane possono incidere sensibilmente sul costo totale, soprattutto quando si eseguono più cluster per motivi di isolamento, conformità o confini organizzativi. Alcuni provider offrono control plane gratuiti fino a una certa dimensione o tier del cluster, mentre altri li fatturano sempre. Nel definire il budget per Kubernetes, occorre considerare questi costi ricorrenti nelle decisioni sulla proliferazione dei cluster, sulle configurazioni multi-ambiente e sulla distinzione tra cluster di sviluppo e di produzione.
Costi di storage
I costi di storage in Kubernetes dipendono da tipo, dimensione e tier di prestazioni dei volumi di storage persistente collegati ai workloads. I cloud provider offrono diverse opzioni di storage, come block storage, object storage e network-attached storage, ciascuna con una propria struttura di prezzo. I costi possono derivare sia dalla capacità di storage sottoposta a provisioning sia dalla quantità di dati letti o scritti, soprattutto per workloads ad alto I/O o applicazioni stateful come i database.
Scegliere la storage class giusta e ottimizzare le dimensioni dei volumi è essenziale per gestire i costi di storage. L'overprovisioning dello storage può generare spese inutili, mentre l'underprovisioning rischia di causare downtime delle applicazioni o perdita di dati. Funzionalità come backup, snapshot e replica possono comportare costi aggiuntivi. Verificare l'utilizzo dello storage ed eliminare volumi inutilizzati o dati obsoleti aiuta a ridurre i costi ricorrenti.
Costi di networking
I costi di networking nei cluster Kubernetes derivano dalla comunicazione interna al cluster, dal traffico in ingresso e in uscita e dalle funzionalità di rete avanzate come load balancer o interconnessioni private. I cloud provider addebitano in genere il trasferimento di dati tra regioni o verso Internet, e per le applicazioni ad alto traffico questi costi possono accumularsi. Il networking intra-cluster, come la comunicazione pod-to-pod nella stessa regione o availability zone, è spesso meno costoso, ma va comunque monitorato.
Il deployment di load balancer esterni o l'uso di plugin di rete avanzati può introdurre costi aggiuntivi. È importante comprendere il modello di prezzo del networking del proprio cloud provider, inclusi i costi per indirizzi IP pubblici, VPN e interconnessioni. Ottimizzare l'architettura delle applicazioni per ridurre i trasferimenti di dati superflui e scegliere la configurazione di rete adeguata aiuta a tenere sotto controllo questi costi. Il monitoraggio e l'analisi dell'utilizzo di rete sono importanti per contenere le spese.
Costi di osservabilità
I costi di osservabilità riguardano le spese legate a monitoraggio, logging e tracing di cluster e workloads Kubernetes. Sebbene le metriche di base possano essere incluse nei servizi gestiti, un'osservabilità avanzata richiede strumenti aggiuntivi o integrazioni di terze parti. Questi strumenti applicano spesso tariffe basate sul volume di dati acquisiti, sul numero di risorse monitorate o sul periodo di conservazione di log e metriche.
Non considerare i costi di osservabilità può portare a sforamenti di budget, soprattutto in ambienti grandi o dinamici con volumi elevati di dati di telemetria. Le organizzazioni dovrebbero valutare i requisiti di monitoraggio e scegliere strumenti che offrano controllo sulla raccolta e sulla conservazione dei dati. Campionamento, filtraggio e aggregazione dei dati aiutano a ridurre i costi mantenendo la visibilità sullo stato dei cluster e sulle prestazioni delle applicazioni.
Add-on e strumenti di terze parti
Gli ambienti Kubernetes si affidano spesso ad add-on e strumenti di terze parti per funzioni come sicurezza, backup, service mesh o integrazioni CI/CD. Molti di questi strumenti adottano modelli in abbonamento o tariffe basate su metriche d'uso come numero di nodi, pod o chiamate API. Man mano che i cluster crescono e si integrano nuove funzionalità, questi costi possono diventare una parte significativa della spesa complessiva per Kubernetes.
È importante censire tutti gli add-on e valutarne il valore rispetto al costo. Gli strumenti inutilizzati o ridondanti andrebbero rimossi, mentre quelli necessari andrebbero configurati in modo efficiente. Nella scelta di nuove integrazioni, occorre considerare sia il prezzo diretto sia il consumo indiretto di risorse che introducono. Gestire add-on e strumenti di terze parti aiuta a prevenire spese superflue e a mantenere efficienti le operazioni su Kubernetes.
Prezzi di Kubernetes per cloud provider
Prezzi di Amazon EKS
Amazon Elastic Kubernetes Service (EKS) adotta un modello di prezzo a più livelli che combina le tariffe di gestione dei cluster con i costi dell'infrastruttura sottostante e delle funzionalità. Alla base, Amazon EKS applica una tariffa oraria per cluster che dipende dal tier di supporto della versione di Kubernetes. I cluster con una versione in supporto standard costano $0,10 per cluster all'ora, mentre quelli in supporto esteso costano $0,60 per cluster all'ora.
Oltre alla tariffa del cluster, si paga l'infrastruttura su cui girano i workloads. Questa include:
- Istanze Amazon EC2 usate come worker node
- Volumi di storage Amazon EBS
- Indirizzi IPv4 pubblici
- Traffico di rete, come la comunicazione tra Availability Zone.
Le organizzazioni che usano AWS Fargate con EKS pagano in base alle risorse di vCPU e memoria consumate dai pod, con un modello di prezzo al secondo e un addebito minimo di un minuto.
Amazon EKS offre inoltre tier e funzionalità di prezzo avanzati:
- Il control plane con provisioning dedicato consente alle organizzazioni di riservare capacità dedicata del control plane per workloads su larga scala o sensibili alla latenza. I prezzi partono da $1,65 per cluster all'ora per il tier XL e crescono in base al livello di capacità selezionato.
- EKS Auto Mode automatizza il provisioning e la gestione dei nodi. Con Auto Mode si paga un costo aggiuntivo rispetto al prezzo delle istanze EC2, in base alla durata e al tipo di istanze gestite dal servizio.
Possono applicarsi costi aggiuntivi per le funzionalità EKS e per i deployment ibridi. Le funzionalità EKS includono integrazioni gestite come Argo CD, AWS Controllers for Kubernetes (ACK) e Kubernetes Resource Orchestrator (KRO), fatturate su base oraria con una tariffa base e metriche basate sull'utilizzo. Per i deployment ibridi ed edge, i prezzi di Amazon EKS Hybrid Nodes si basano sulle vCPU-ora, con tariffe scaglionate che diminuiscono al crescere dell'utilizzo.
Prezzi di Google Kubernetes Engine
Google Kubernetes Engine (GKE) usa un modello di prezzo basato su gestione del cluster, risorse di compute, modalità operativa del cluster e costi legati all'ingress:
- GKE applica una tariffa fissa di gestione del cluster di $0,10 per cluster all'ora, fatturata a incrementi di un secondo. La tariffa vale per tutti i cluster, inclusi Autopilot e i cluster standard zonali, regionali e multizona.
- Google offre inoltre un tier gratuito con $74,40 di crediti mensili per account di fatturazione, che possono coprire il costo di un cluster Autopilot o standard zonale al mese.
Per i cluster standard, i costi di compute si basano sulle istanze Compute Engine sottostanti usate dai nodi del cluster. Queste istanze sono fatturate al secondo, con un minimo di un minuto, finché i nodi non vengono eliminati. Le organizzazioni possono ridurre questi costi con gli sconti per impegno di utilizzo di Compute Engine. GKE include senza costi aggiuntivi funzionalità come autoscaling, gestione del ciclo di vita del cluster, visibilità sui costi e gestione multi-cluster.
I prezzi di Autopilot funzionano diversamente:
- Per i workloads Autopilot generici, GKE usa una fatturazione basata sui pod. Si pagano CPU, memoria e storage effimero richiesti dai pod in esecuzione, invece dei nodi sottostanti. I pod non schedulati, completati o falliti non vengono fatturati.
- Per i workloads Autopilot che richiedono hardware specifico, come GPU, acceleratori o serie di macchine, GKE usa una fatturazione basata sui nodi. In questo modello si paga l'intero nodo Compute Engine sottoposto a provisioning per il workload, più un sovrapprezzo di gestione Autopilot.
Prezzi di Azure Kubernetes Service
Azure Kubernetes Service (AKS) offre le opzioni di prezzo Free, Standard, Premium e Automatic. Il tier Free è pensato per sperimentazione e sviluppo: non prevede SLA e si pagano solo le risorse sottostanti. Per i workloads di produzione, il tier Standard aggiunge uno SLA sull'uptime dell'API server con garanzia finanziaria e costa $73 per cluster al mese.
Il tier Premium prevede il supporto a lungo termine delle versioni di Kubernetes. Include lo SLA ed estende il supporto con correzioni di bug e aggiornamenti di sicurezza oltre la finestra di supporto standard della community Kubernetes. Il prezzo del tier Premium è di $438 per cluster al mese.
I costi di compute vengono addebitati separatamente in base alle macchine virtuali usate dai nodi AKS. Azure supporta prezzi pay-as-you-go, Savings Plans, prenotazioni e istanze Spot.
AKS Automatic offre un'esperienza gestita, con aggiornamenti automatici, provisioning dei nodi, scalabilità e configurazione di rete. Costa $116,80 per cluster al mese per i componenti hosted, oltre ai costi delle macchine virtuali e a tariffe aggiuntive per vCPU in base al tipo di workload, come general purpose, compute optimized, memory optimized, storage optimized, confidential compute, high performance compute o GPU accelerated compute.
Prezzi di DigitalOcean (DOKS)
DigitalOcean Kubernetes (DOKS) non addebita il control plane Kubernetes standard. Si pagano le risorse, tra cui i worker node Droplet, il block storage, i load balancer e le eccedenze di banda. L'alta disponibilità del control plane è disponibile come add-on a $40 al mese.
Il prezzo dei nodi dipende dal tipo di Droplet (opzioni con CPU basic o dedicata):
- I nodi basic partono da $12 al mese per nodo.
- Nodi CPU-optimized da $42 al mese.
- Nodi general purpose da $63 al mese.
- Nodi memory-optimized da $84 al mese.
- Nodi storage-optimized da $163 al mese.
- I nodi GPU con NVIDIA H100 hanno un prezzo on demand di $3,39 all'ora per nodo.
DOKS include senza costi aggiuntivi le funzionalità di gestione di Kubernetes, tra cui aggiornamenti, autoscaling e sicurezza e osservabilità basate su Cilium Hubble. DigitalOcean Container Registry è gratuito fino a 500 MiB.
I prezzi della banda si basano su quote condivise in pool. I nodi basic includono trasferimento dati in uscita gratuito a partire da 2.000 GiB per nodo al mese. Le eccedenze costano $0,01 per GiB, mentre i trasferimenti in ingresso e interni sono gratuiti.
Strategie di ottimizzazione dei costi di Kubernetes
Ecco alcuni dei modi in cui le organizzazioni possono migliorare la gestione dei costi quando usano Kubernetes.
1. Right-sizing delle richieste di CPU e memoria
Richieste di CPU e memoria errate sono una causa frequente di spesa eccessiva in Kubernetes. Quando le richieste sono troppo alte, Kubernetes riserva più risorse di quante i workloads ne utilizzino, con nodi sottoutilizzati e costi infrastrutturali sprecati. Quando sono troppo basse, i workloads possono subire throttling, instabilità o eviction in condizioni di pressione sulle risorse. Strumenti come il metrics server di Kubernetes, Prometheus, Goldilocks o le piattaforme cloud-native di gestione dei costi aiutano a identificare i workloads sovradimensionati.
Vantaggi
- Migliora l'utilizzo dei nodi e riduce i costi dell'infrastruttura inattiva
- Consente una maggiore densità di pod per nodo
- Riduce gli eventi di scaling del cluster non necessari
- Contribuisce a migliorare l'efficienza dello scheduling e la pianificazione della capacità
- Può ridurre il fabbisogno di compute cloud e di istanze riservate
Svantaggi
- Riduzioni aggressive possono causare throttling o instabilità
- Richiede monitoraggio continuo e regolazioni periodiche
- I pattern di utilizzo possono variare notevolmente tra i deployment
- I workloads stateful o soggetti a burst sono più difficili da dimensionare con precisione
Aspetti chiave da considerare
- Analizzare i trend di utilizzo di CPU e memoria sul lungo periodo invece di rilevazioni puntuali
- Configurare richieste e limiti separatamente per evitare throttling accidentale
- Usare strumenti di raccomandazione come Goldilocks o la modalità di raccomandazione di VPA
- Applicare richieste predefinite più contenute negli ambienti di sviluppo e staging
- Rivedere il dimensionamento dopo release importanti, variazioni di traffico o aggiornamenti architetturali
- Monitorare eventi OOMKilled, throttling della CPU e tassi di eviction dopo le regolazioni
2. Usare il Cluster Autoscaler o il provisioning in stile Karpenter
L'autoscaling del cluster riduce gli sprechi infrastrutturali aggiungendo o rimuovendo automaticamente worker node in base alla domanda dei workloads. Invece di eseguire un numero fisso di nodi, l'autoscaling regola dinamicamente la capacità del cluster. Il Cluster Autoscaler di Kubernetes monitora i pod in attesa e l'utilizzo dei nodi: aggiunge nodi quando i workloads non possono essere schedulati e rimuove i nodi sottoutilizzati quando la capacità non serve più. Sistemi di provisioning più recenti, come Karpenter per AWS, selezionano dinamicamente i tipi di istanza in base ai requisiti dei workloads.
Vantaggi
- Riduce i costi dovuti alla capacità inattiva del cluster
- Adatta automaticamente l'infrastruttura alla domanda dei workloads
- Migliora l'utilizzo delle risorse sui nodi
- Supporta il provisioning dinamico di tipi di istanza ottimizzati
- Consente un migliore utilizzo della capacità Spot o preemptible
Svantaggi
- Politiche di scaling inadeguate possono aumentare l'instabilità
- Eventi di scaling frequenti possono incidere sulle prestazioni delle applicazioni
- I ritardi di scaling possono penalizzare i workloads durante i picchi improvvisi
- Monitoraggio operativo e troubleshooting più complessi
Aspetti chiave da considerare
- Configurare soglie realistiche di scale-up e scale-down
- Testare il comportamento dell'autoscaling in condizioni di traffico simili alla produzione
- Adottare, quando possibile, un provisioning basato sulle caratteristiche dei workloads
- Combinare l'autoscaling con richieste di risorse dei pod accurate
- Monitorare il churn dei nodi, i pod in attesa e la latenza di scheduling
- Prevenire comportamenti di scale-down aggressivi per i workloads stateful
3. Usare l'autoscaling orizzontale e verticale dei pod
Horizontal Pod Autoscaler (HPA) e Vertical Pod Autoscaler (VPA) ottimizzano l'uso delle risorse a livello applicativo. HPA scala il numero di repliche dei pod in base a metriche come utilizzo di CPU, utilizzo di memoria o metriche applicative personalizzate. VPA regola le richieste di CPU e memoria assegnate ai singoli pod in base ai pattern di utilizzo osservati.
Vantaggi
- Riduce le risorse applicative sovradimensionate
- Si adatta automaticamente alle variazioni dei pattern di traffico
- Migliora l'efficienza del cluster e la densità dei workloads
- Favorisce prestazioni applicative migliori sotto carico
- Aiuta a ridurre le operazioni di scaling manuali
Svantaggi
- Soglie di scaling errate possono creare instabilità
- VPA può riavviare i workloads durante le regolazioni
- Le reazioni di scaling possono essere in ritardo rispetto a picchi di traffico improvvisi
- Combinare HPA e VPA può introdurre conflitti
Aspetti chiave da considerare
- Usare HPA principalmente per servizi stateless e scalabili
- Eseguire VPA in modalità di raccomandazione prima di attivare l'automazione
- Definire numeri minimi e massimi di repliche appropriati
- Usare metriche personalizzate per decisioni di scaling più accurate
- Monitorare la frequenza di scaling e la stabilità dei workloads
- Evitare di scalare solo in base alla CPU per applicazioni sensibili alla memoria
4. Usare con attenzione le istanze Spot o preemptible
Le istanze Spot su AWS e Azure e le istanze preemptible su Google Cloud offrono prezzi inferiori rispetto alle macchine virtuali on-demand. Queste istanze scontate sono adatte ai workloads fault-tolerant, perché i cloud provider possono revocarle con pochissimo preavviso. Workloads Kubernetes come elaborazioni batch, job CI/CD, worker in background e applicazioni stateless sono spesso buoni candidati per l'infrastruttura Spot.
Vantaggi
- Può ridurre notevolmente i costi di compute
- Migliora l'efficienza complessiva dell'infrastruttura
- Funziona bene per workloads batch e fault-tolerant
- Consente capacità di compute su larga scala a costi inferiori
- Si integra con i controlli di scheduling di Kubernetes
Svantaggi
- Le istanze possono essere interrotte in modo imprevisto
- Non adatte a workloads critici o stateful
- Richiede una progettazione applicativa resiliente
- La disponibilità Spot varia per regione e tipo di istanza
Aspetti chiave da considerare
- Usare la capacità Spot principalmente per workloads non critici
- Combinare nodi Spot e on-demand nello stesso cluster
- Configurare taint, toleration e politiche di node affinity
- Implementare retry, replica e gestione controllata delle interruzioni
- Monitorare la frequenza delle interruzioni e i tempi di ripristino dei workloads
- Diversificare tipi di istanza e availability zone per ridurre il rischio di interruzioni
5. Definire budget per namespace e team
Man mano che gli ambienti Kubernetes crescono, i cluster vengono comunemente condivisi tra più team, applicazioni e business unit. Senza controlli di governance, l'utilizzo delle risorse tende a espandersi senza una chiara titolarità o responsabilità, rendendo difficile la gestione dei costi infrastrutturali. Budget e controlli delle risorse a livello di namespace aiutano le organizzazioni a limitare la crescita incontrollata e a migliorare la visibilità sui costi. Le policy ResourceQuota e LimitRange di Kubernetes possono limitare CPU, memoria, storage e numero di oggetti all'interno dei namespace.
Vantaggi
- Aumenta la responsabilizzazione dei team sui costi
- Previene il consumo incontrollato di risorse
- Aiuta ad applicare politiche di governance e capacità
- Semplifica l'allocazione interna dei costi e il reporting
- Incoraggia una pianificazione più efficiente dei workloads
Svantaggi
- Quote rigide possono rallentare i flussi di sviluppo
- Le politiche di budget richiedono manutenzione continua
- L'attribuzione dei costi può diventare complessa nei cluster condivisi
- Politiche troppo restrittive possono creare attriti operativi
Aspetti chiave da considerare
- Usare le policy ResourceQuota e LimitRange in modo coerente
- Implementare la cost allocation con strumenti come Kubecost o OpenCost
- Monitorare la spesa per namespace, applicazione o business unit
- Rivedere regolarmente le politiche di quota man mano che i workloads evolvono
- Bilanciare i controlli di governance con la flessibilità degli sviluppatori
- Impostare avvisi per picchi di utilizzo anomali o sforamenti di budget
Ottimizzazione dei costi di Kubernetes con PerfectScale
[PLACEHOLDER - non ancora redatto] Al posto del testo definitivo, il file sorgente contiene qui un blocco di istruzioni dell'agenzia: il titolo della sezione è una proposta in attesa del posizionamento finale, e i paragrafi di prodotto e l'invito all'azione devono essere forniti separatamente, poiché Agile SEO non scrive contenuti di prodotto. Destinazione in bozza dell'invito all'azione:
https://www.perfectscale.io/contact-sales. Lo segnaliamo perché non venga pubblicato così com'è.
Domande frequenti
Quanto costa Kubernetes?
Kubernetes in sé è gratuito e open source. I costi derivano dalla sua esecuzione. Con un servizio Kubernetes gestito si paga in genere:
- Una tariffa per il control plane di circa $0,10/ora (~$73/mese) per cluster su AWS EKS e Google GKE
- I costi dei worker node per le VM su cui girano i workloads: di solito è la voce più consistente della fattura
- I costi di storage per i volumi persistenti
- I costi di networking per il traffico in uscita e i load balancer
Azure AKS costa $73/mese per il tier di produzione (Standard). DigitalOcean Kubernetes non addebita affatto il control plane.
Cosa si intende per prezzi del Kubernetes gestito?
I prezzi del Kubernetes gestito si riferiscono alle tariffe applicate dai cloud provider (come AWS, Google Cloud, Azure e DigitalOcean) per eseguire e mantenere il control plane di Kubernetes per conto dell'utente. Invece di configurare e gestire personalmente l'infrastruttura del cluster, è il provider a occuparsi di aggiornamenti, patch e disponibilità.
Si continuano a pagare le risorse sottostanti usate dai workloads: macchine virtuali, storage e traffico di rete. La tariffa di gestione si aggiunge a questi costi.
Quanto costa Amazon EKS?
Amazon EKS applica $0,10 per cluster all'ora (~$73/mese) per i cluster con una versione di Kubernetes in supporto standard. I cluster in supporto esteso costano $0,60 per cluster all'ora.
A questo si aggiungono:
- Istanze EC2 usate come worker node
- Volumi di storage EBS
- Traffico di rete (tra AZ, in uscita)
- Indirizzi IPv4 pubblici
Con AWS Fargate su EKS si paga per vCPU e memoria consumate da ciascun pod, con fatturazione al secondo e un minimo di un minuto.
Quanto costa Google GKE?
Google GKE applica $0,10 per cluster all'ora per tutti i tipi di cluster. Google offre inoltre $74,40 di crediti mensili per account di fatturazione, sufficienti a coprire gratuitamente un cluster zonale o Autopilot al mese.
Per i cluster standard si pagano le istanze Compute Engine su cui girano i nodi. Per i cluster Autopilot i prezzi funzionano diversamente:
- Workloads generici: si pagano CPU, memoria e storage richiesti dai pod, non i nodi sottostanti
- Workloads che richiedono GPU o hardware specifico: GKE usa una fatturazione basata sui nodi, in cui si paga l'intero nodo sottoposto a provisioning più un sovrapprezzo di gestione Autopilot
Quanto costa Azure AKS?
Azure AKS prevede diversi tier:
- Tier Free: nessuna tariffa di gestione, si pagano solo nodi e risorse. Nessuno SLA. Ideale per sviluppo e test
- Tier Standard: $73/mese per cluster, con uno SLA sull'uptime coperto da garanzia finanziaria. Per i workloads di produzione
- Tier Premium: $438/mese per cluster. Aggiunge il supporto a lungo termine con correzioni di sicurezza e bug estese
- Tier Automatic: $116,80/mese per i componenti hosted, più tariffe per vCPU in base al tipo di workload
I costi delle VM dei worker node vengono addebitati separatamente, in aggiunta al tier scelto.
Quanto costa DigitalOcean Kubernetes?
DigitalOcean Kubernetes (DOKS) non applica alcuna tariffa per il control plane. Si pagano solo le risorse utilizzate:
- Nodi basic: a partire da $12/mese per nodo
- Nodi CPU-optimized: da $42/mese
- Nodi general purpose: da $63/mese
- Nodi memory-optimized: da $84/mese
- Nodi GPU (NVIDIA H100): $3,39/ora per nodo
L'alta disponibilità del control plane è un add-on opzionale a $40/mese. Il trasferimento dati in uscita è gratuito fino a 2.000 GiB per nodo al mese, con eccedenze a $0,01 per GiB.