Come scegliere il cloud provider per Kubernetes

In un contesto in cui Kubernetes è diventato lo standard de facto per orchestrare container, la scelta del cloud provider incide in modo diretto su come i tuoi workload verranno eseguiti e gestiti. In questa guida analizziamo gli aspetti tecnici che contano davvero quando si parla di Kubernetes cloud provider, a partire dall’integrazione con l’infrastruttura fino al confronto tra GKE, EKS e AKS.

Come Kubernetes si integra con l’infrastruttura cloud

Quando si parla di scegliere il cloud provider per Kubernetes, è fondamentale comprendere che il provider non è semplicemente “il posto dove installare il cluster”. Si tratta di un’integrazione profonda e bidirezionale tra Kubernetes e l’infrastruttura sottostante, che permette al cluster di sfruttare nativamente servizi come load balancer, storage persistente, nodi virtuali e networking cloud-native. Il componente chiave è il Cloud Controller Manager (CCM), che funge da ponte tra l’API di Kubernetes e le API del provider. Traduce ad esempio un Service LoadBalancer in una risorsa concreta del cloud (es. AWS ELB, Azure LB, GCP CLB).

Storicamente le integrazioni erano in-tree: codice cloud-specifico incluso nel core di Kubernetes. Questo approccio creava problemi di manutenzione, ritardi nelle feature e barriere di integrazione per nuovi provider. Dal 2017 Kubernetes si è spostato verso un modello out-of-tree (standard attuale): in cui il CCM è un componente esterno, mantenuto dal provider o dalla community, deployato separatamente.

Con Kubernetes v1.31 (2024) il codice della vecchia implementazione in-tree è stato completamente rimosso e ad oggi il parametro –cloud-provider=external è obbligatorio per qualsiasi provider (salvo nel caso di cluster bare metal/on-prem o senza integrazioni cloud).

I vantaggi principali dell’out-of-tree sono:

• Aggiornamenti del CCM indipendenti dal ciclo di release di Kubernetes
• Innovazione più rapida (nuovi servizi, fix veloci)
• Core più leggero e neutrale (vendor-agnostic)
• Una percezione più bassa del lock-in sulla piattaforma

Parallelamente a questa evoluzione del Cloud Controller Manager, Kubernetes ha standardizzato altre interfacce critiche per separare ulteriormente il core dalle implementazioni vendor-specifiche:

• CSI (Container Storage Interface): driver storage esterni (sostituiscono i vecchi plugin in-tree)
• CNI (Container Network Interface): plugin networking (es. Amazon VPC CNI, Azure CNI, Cilium)

In sintesi: prima di confrontare GKE, EKS e AKS ha senso capire quanto ogni provider investa nella qualità di queste integrazioni.

È importante, dunque, quando si valuta un cloud provider per un workload Kubernetes production-grade, guardare oltre le feature “managed” di alto livello. Bisogna verificare la maturità e la frequenza di aggiornamento del loro Cloud Controller Manager, la qualità e le performance del driver CSI, e l’efficienza dell’implementazione CNI. Sono questi i mattoni che determinano quanto fluidamente Kubernetes “percepisca” e sfrutti l’infrastruttura sottostante, influenzando direttamente affidabilità, costi e capacità di scaling.

Prima di proseguire, ti consigliamo una risorsa se stai valutando come introdurre K8s in azienda in modo strutturato. Nella nostra Guida all’adozione di Kubernetes puoi approfondire requisiti, roadmap ed errori da evitare: scarica l’ebook gratuito e usa la checklist per pianificare il percorso di adozione.

Architetture a confronto: control plane e gestione dei nodi

Chiarito come Kubernetes dialoga con il cloud, il passo successivo è capire “chi fa cosa” tra te e il provider nella gestione del cluster. Quando si sceglie un cloud provider per Kubernetes, l’architettura del control plane e la gestione dei worker nodes determinano il livello di astrazione, il carico operativo e la flessibilità. Ecco un confronto diretto tra i principali hyperscaler: GKE (Google), EKS (AWS) e AKS (Azure).

Control Plane: livello di astrazione

• GKE Autopilot: Completamente gestito e astratto. Google controlla interamente control plane e nodi. Nessuna visibilità o gestione diretta dei nodi sottostanti. Ideale per focus su workload (SLA esteso su control plane + compute).
• GKE Standard: Control plane gestito da Google (HA multi-zona), ma nodi worker gestiti dal cliente (provisioning, scaling manuale o con autoscaler).
• EKS: Control plane sempre gestito da AWS (multi-AZ, auto-riparazione, endpoint via NLB). Alta disponibilità nativa, ma senza modalità “serverless” totale per i nodi (opzioni: managed node groups, self-managed, Fargate, EKS Auto Mode per automazione avanzata).
• AKS: Control plane gestito da Azure (gratuito, HA). Dal 2025, AKS Automatic introduce modalità fully-managed simile ad Autopilot, con autoscaling dinamico via Karpenter-like e patching automatico.

Il risultato di questa comparazione fa emergere come Autopilot / AKS Automatic riducano drasticamente il toil operativo, ma limitano il livello di personalizzazione possibile. EKS e GKE Standard offrono più controllo, a costo di maggiore gestione.

Gestione del ciclo di vita dei worker nodes

Qui entra in gioco un tema molto sentito dai team operativi: quanto lavoro manuale richiede mantenere sano il parco nodi? Vediamo il confronto.

Opzioni di personalizzazione dei nodi

Proseguiamo il confronto analizzando il livello di personalizzazione dei nodi offerto dai provider.

• GKE Autopilot: Personalizzazione molto limitata. Non è possibile la scelta diretta di instance type, OS, GPU custom (richiesta via pod spec, Google ottimizza). Supporta chip particolari (GPU/TPU) su richiesta.
• GKE Standard: Personalizzazione alta: tipi di VM custom (n2, c3, tau), OS (Container-Optimized OS), taints/labels, preemptible/spot, custom machine types.
• EKS: Personalizzazione molto alta. Controllo granulare tramite EC2 instance types, AMIs custom (Bottlerocket, AL2), Launch Templates, spot instances, GPU/ARM, Fargate per approcci serverless.
• AKS: Personalizzazione alta: VM sizes (Standard_D, Fsv2, etc.), Azure Linux/Windows, spot/low-priority, custom images, GPU/InfiniBand.

In pratica, più sali di astrazione (Autopilot/AKS Automatic), più scarichi responsabilità operative sul provider rinunciando a qualche leva fine di ottimizzazione. Il “punto giusto” dipende da quanto vuoi standardizzare e da quanto sei disposto a investire in gestione interna.

LEGGI ANCHE

• Kubernetes architecture: guida alle componenti principali
• Kubernetes operator: cosa sono ed esempi

Integrazione del networking: Service, Ingress e CNI a confronto

Una volta scelto il modello di control plane e nodi, il tema successivo è come il traffico entra, esce (Service, Ingress) e si muove dentro il cluster (CNI). L’integrazione networking è un altro elemento fondamentale per scegliere il cloud provider per Kubernetes: impatta latenza, costi, scalabilità e gestione IP.

Per mettere a confronto GKE, EKS e AKS ha senso guardare a tre livelli distinti ma collegati tra loro:

1. Come esponi i Service (LoadBalancer)
2. Come gestisci il routing HTTP/HTTPS (Ingress)
3. Quale CNI governa il traffico interno tra pod

1. Implementazione Service di tipo LoadBalancer

Il Service controller (parte del CCM esterno) crea un load balancer cloud quando si definisce un Service type: LoadBalancer. Qui la domanda è: che tipo di LB ottieni “out of the box” e con quali implicazioni su performance e costi?

• GKE: Usa un Passthrough Network Load Balancer (esterno/interno) che opera a Livello 4 (TCP/UDP). L’aspetto “passthrough” è importante perché mantiene l’indirizzo IP originale della richiesta. Inoltre, supporta il subsetting, una funzionalità per ottimizzare velocità e scalabilità del backend (ottimizza la distribuzione del carico inviando il traffico solo ai nodi che hanno effettivamente i pod attivi per quel servizio, ed evitando invii inutili verso nodi “vuoti”).
• EKS: Qui, AWS Load Balancer Controller agisce come controller predefinito per servizi di tipo LoadBalancer e, quando viene creato un tale servizio, crea automaticamente un Network Load Balancer (NLB) (Layer 4, alto throughput, IP statici, UDP/TCP). ALB per Ingress (Layer 7) e altri load balancers sono anche supportati (Gateway LB, e l’ormai legacy Classic LB).
• AKS: Crea Azure Standard Load Balancer di default (Layer 4) per gestire sia traffico pubblico che privato. Gestisce automaticamente anche il traffico in uscita del cluster (outbound type LoadBalancer per egress). Un’apposita annotation permette di creare un internal LB. Una caratteristica importante è la flessibilità del backend. Il backend pool (l’insieme dei destinatari del traffico) può essere configurato con nodeIP (invio ai nodi che ospitano i Pod) o con podIP (invio diretto ai singoli Pod, eliminando i passaggi intermedi nella rete Azure e massimizzando le prestazioni).

GKE e EKS privilegiano passthrough/performance mentre AKS offre una integrazione semplice con il networking di Azure (NSG, outbound rules). In generale, i NLB/ALB su AWS tendono a essere più costosi per il traffico L7 rispetto ad Azure, che però offre un set di funzionalità complessive più limitato. Se i tuoi workload sono molto esposti verso l’esterno o ad alto volume di traffico, questo mix tra tipo di LB, funzionalità e pricing diventa un criterio di scelta importante.

2. Soluzioni Ingress consigliate o integrate

Ingress gestisce routing HTTP/HTTPS (Layer 7). Qui entrano in gioco non solo il bilanciamento e lo smistamento delle richieste, ma anche temi di security come certificati SSL/TLS, firewall WAF e integrazione con i servizi di sicurezza e observability del provider.

• GKE: L’Ingress controller di default crea un Google Cloud Application Load Balancer (classic o internal) per gestire il traffico. Supporta i LB container-native tramite NEGs (comunica direttamente con i singoli container senza passaggi intermedi per massimizzare la velocità). GKE è stato il primo a supportare nativamente la nuova Gateway API per una gestione del traffico ancora più precisa (routing avanzato e facile gestione di traffico multi cluster. È una soluzione raccomandata per workload HTTP globali.
• EKS: L’AWS Load Balancer Controller crea un Application Load Balancer (ALB) per Ingress. Gestisce il traffico in base all’indirizzo o al percorso (path/host routing). Il vantaggio principale è l’integrazione profonda e “chiavi in mano” con i servizi AWS: usa WAF per la sicurezza, ACM TLS per i certificati SSL, CloudWatch per i log. Alternativa: NGINX/Traefik, ma ALB è nativo e l’opzione preferita per l’integrazione con i servizi AWS.
• AKS: Offre l’Application routing add-on, che è il metodo raccomandato perchè semplice ed integrato. Per esigenze di sicurezza avanzata offre anche l’Application Gateway Ingress Controller (AGIC) per Azure Application Gateway (che include WAF, SSL offload, path-based). Gateway API è supportata.

Le componenti fornite nativamente dai provider (ALB, App Gateway, Google ALB) riducono l’overhead di gestione ed offrono feature di sicurezza (WAF) mentre i controller open-source (NGINX) si focalizzano nell’offrire meno funzionalità ma più semplicità di gestione. La scelta, quindi, è tra maggiore integrazione con l’ecosistema del cloud (LB gestiti) e maggiore portabilità/sobrietà operativa (Ingress controller open source). Da evidenziare anche come oggi molti Ingress stiano evolvendo nella Gateway API di kubernetes, che offrono ancora più controllo rispetto al classico Ingress.

3. Plugin CNI di default e implicazioni

Il CNI gestisce pod networking, IP allocation e policy. A differenza di Service e Ingress, che riguardano il traffico “verso” il cluster, qui ci concentriamo sul traffico interno tra pod, sull’assegnazione degli indirizzi IP ai Pod e sulle regole per farli parlare tra loro.

Per il mondo del networking, vale la pena scegliere un CNI nativo per semplicità/integrazione e un’alternativa (Cilium) per observability avanzata, eBPF puro e multi-cloud. Questa scelta incide direttamente sulla scalabilità degli IP, sulla complessità operativa e sulla visibilità del traffico interno: tre variabili da bilanciare in base al tipo di carichi che devi gestire e al livello di controllo che vuoi mantenere sul data plane.

Lo storage persistente: analisi dei driver CSI e delle performance

Networking a parte, la vera prova del nove per molti cluster Kubernetes arriva quando entrano in gioco database, code e componenti stateful. Lo storage persistente è un pilastro critico nella scelta del cloud provider per Kubernetes: influenza latenza, throughput e IOPS (velocità), costi e affidabilità per servizi come database, stateful app e workload AI/ML.

Tutti i principali provider usano driver CSI (Container Storage Interface) maturi per il provisioning dinamico di block-volumes per un singolo pod (ReadWriteOnce) e file system condivisi tra più pod (ReadWriteMany), sostituendo completamente i vecchi plugin in-tree.

Il driver CSI permette di creare PersistentVolume automaticamente da un PersistentVolumeClaim (PVC), gestendo attach/detach, espansione, snapshot e reclaim. In altre parole, il driver CSI automatizza il ciclo di vita dei dischi: quando un’app chiede spazio (tramite un PVC), il driver crea, collega e gestisce il volume senza interventi manuali, e supporta anche funzioni di aumento della dimensione e backup. Per scegliere la velocità dei dischi basta selezionare una StorageClass. Ogni provider offre StorageClass predefinite o custom, secondo diversi tier di performance, adatti a diversi contesti.

In basso, una tabella di un confronto diretto delle opzioni block (dischi) e file, con tier principali, performance indicative e casi d’uso tipici.

Qui, dunque, il criterio di scelta non è solo “chi offre più IOPS”, ma anche come si mappano i tuoi workload reali sui diversi tier: database OLTP, gestione dei log, AI/ML, ciascuno ha pattern di accesso molto diversi che possono far emergere vantaggi significativi di un provider rispetto a un altro.

LEGGI ANCHE

• Scegliere il cloud provider: confronto tra AWS, Azure, GCP e Alibaba

Oltre l’orchestrazione: servizi cloud nativi e valore aggiunto

Finora ci siamo concentrati su “core Kubernetes”: control plane, nodi, networking, storage. Ma nella pratica quotidiana, molto del valore di un Kubernetes cloud provider arriva dai servizi che lo circondano. Oltre alla gestione del cluster Kubernetes, il vero valore aggiunto di un cloud provider emerge dall’integrazione nativa con i servizi gestiti dell’ecosistema, che riducono complessità operativa e accelerano l’adozione di best practice enterprise. Ogni hyperscaler arricchisce Kubernetes con un intero ecosistema integrato in tre aree chiave:

• Identità e sicurezza: L’integrazione con i sistemi di identità permette workload identity federate e least-privilege senza chiavi statiche. Si tratta di concetti miliari della sicurezza moderna: invece di “iniettare” segreti e password nei pod, il pod stesso diventa un’identità IAM del cloud e grazie alla sua identità può accedere senza altre credenziali ad altre risorse (database, buckets, ecc). Ogni hyperscaler offre il poprio sistema: AWS IRSA (IAM Roles for Service Accounts), Azure Workload Identity con Microsoft Entra ID, Google Workload Identity Federation con Google IAM. Questo elimina il rischio di furto di credenziali (credential leakage) e semplifica i permessi RBAC cross-service.
• Osservabilità: Logging e monitoring nativi sono pronti all’uso e riducono notevolmente l’effort di setup. Amazon CloudWatch Container Insights raccoglie metriche, log e tracce da pod e nodi; Azure Monitor con Container insights offre Kube-state, Prometheus scraping e Log Analytics; Google Cloud Operations Suite (ex Stackdriver) fornisce logging strutturato, metriche Prometheus e tracing distribuito con OpenTelemetry nativo. Tutti supportano alerting centralizzato e dashboard pronti all’uso. Insomma, ognuno supporta il monitoraggio ottimizzato per il proprio ecosistema, con dashboard e avvisi già configurati, senza dover installare sistemi esterni.
• Service Mesh & Networking avanzato: Per gestire il traffico interno (east-west) in modo sicuro e osservabile, i provider offrono soluzioni gestite o plug-and-play: Google Anthos Service Mesh (basato su Istio, con policy e telemetry integrati), AWS App Mesh (serverless-friendly, con X-Ray tracing), Azure Service Mesh (Istio-based nel AKS add-on). Questi riducono la necessità di gestire Istio/Linkerd da zero (complesso), fornendo crittografica tra i servizi (mTLS) automatica, facilitano i rilasci graduali (canary rollout) e observability out-of-the-box.

In ottica progettuale, questi servizi spesso pesano quanto (se non più) delle differenze pure di Kubernetes: scegliere un provider significa anche scegliere il suo ecosistema “intorno al cluster”.

LEGGI ANCHE

• 3 errori da non commettere adottando Kubernetes
• Container e Kubernetes: 3 aziende che li usano con successo

Sintesi decisionale: scegliere il provider per costi, scenari e alternative

Arrivati a questo punto, il quadro è chiaro ma complesso: ogni provider ha aree di eccellenza e compromessi. Per orientarsi serve collegare le caratteristiche tecniche a scenari concreti. La scelta del cloud provider per Kubernetes dipende da priorità chiare e alcuni fattori importanti, quali: time-to-market, controllo operativo, integrazione con un ecosistema, costi totali e potenzialmente vincoli normativi.

• Google Kubernetes Engine (GKE): Migliore per ecosistemi ibridi/multicloud, AI/ML e workload globali. Eccelle in semplicità (soprattutto Autopilot), networking performante (Dataplane V2), storage flessibile (Hyperdisk) e Anthos per ibrido/on-prem. Ideale quando serve time-to-market rapido e innovazione Google (TPU, BigQuery federation).
• Amazon EKS: Migliore per massima configurabilità e integrazione profonda con AWS, creando sinergia con gli altri servizi di AWS e riducendo l’overhead operativo quando si è nell’ecosistema Amazon. Vince su workload enterprise complessi, uso intensivo di EC2 spot, Fargate serverless, App Mesh e IRSA. Scelta naturale se l’azienda è già heavy-AWS. È stato introdotto un free tier per il control plane per piccoli cluster sotto i 50 nodi, opzione attrattiva per le piccole imprese.
• Azure Kubernetes Service (AKS): Migliore per imprese Microsoft-centriche e costi competitivi su storage/networking. Forte su integrazione Entra ID, Azure Monitor, Application Gateway e workload .NET e non. Ottimo per chi cerca bilanciamento tra semplicità e controllo. Spesso un’opzione economicamente valida per carichi di lavoro generalisti sotto i 100 nodi grazie al control plane gratuito e a costi di networking/storage competitivi.

Modelli di costo (oltre il prezzo per nodo)

• Control plane: su AKS gratuito nel free tier, ma costo variabile di cluster management negli alti tier e altri SKU. GKE/EKS ~$73/mese (tipicamente fee orario per cluster). Dal 2026 anche EKS ha introdotto free tier per piccoli cluster (sotto i 50 nodi).
• Egress: Voce spesso dominante e dipende da regione e tier. AWS più caro (~$0.09/GB), Azure/Google simili.
• Load Balancer: costi per ogni istanza di LB; su AWS NLB/ALB costi cumulativi alti, con molti microservizi con bilanciatori singoli il costo esplode (“proliferazione di NLB”). Su Azure/Google costi più prevedibili; spesso usato un unico indirizzo IP per più servizi, consolidando il costo.
• Storage: AWS EBS gp3 è il punto di riferimento per il rapporto prezzo/prestazioni, è economico rispetto ai concorrenti soprattutto per dischi piccoli ma veloci perchè permette di configurare IOPS e Throughput indipendentemente dalla dimensione del disco. Persistent Disk di Google e Azure Managed Disk sono simili, ma IOPS separati “pesano” economicamente perchè spesso legate alla dimensione del disco.

Sotto questi aspetti, AKS vince su cluster multipli, EKS ha un modello di licensing che può portare all’esplosione dei costi su LB/egress, GKE Autopilot semplifica di molto la gestione ma costa di più.

Alternative valide

• DigitalOcean Kubernetes: Adatto a startup e budget limitato: prezzi semplici, control plane gratuito, interfaccia tra le più semplici sul mercato. Una valida alternativa per chi vuole far girare app senza una laurea in networking AWS.
• OVHcloud: Sovranità dati EU, totale conformità GDPR, protezione dai regolamenti extra-EU. Un grande vantaggio: zero costi di Egress (traffico dati in uscita) per la maggior parte dei casi in Europa.
• Altri (Linode, Scaleway, Hetzner) per scenari low-cost e presenza in EU (bare metal, istanze ARM a basso consumo energetico).

In definitiva, non esiste un “miglior Kubernetes cloud provider” in assoluto: esiste il provider più adatto al tuo contesto tecnico, ai tuoi vincoli di costo e alle tue roadmap di prodotto. La scelta passa attraverso una lettura combinata di architettura del cluster, integrazione con l’infrastruttura, servizi gestiti e modelli di pricing.

Se vuoi valutare in modo strutturato quale direzione prendere – o come progettare un’architettura Kubernetes portabile su più cloud – SparkFabrik può affiancarti dalla fase di analisi fino alla messa in produzione, aiutandoti a trasformare queste variabili tecniche in decisioni strategiche solide. Dai un’occhiata al nostro servizio di Kubernetes Consultancy e contattaci.