Kubernetes per PMI 2022: serve davvero o è overkill? Alternative e roadmap

Negli ultimi 18 mesi non c’è conferenza tech, post su LinkedIn o pitch consulenziale che non citi Kubernetes. È diventato il sinonimo di “infrastruttura moderna”, quasi un requisito implicito per chiunque voglia essere considerato serio nel mondo cloud-native. Il problema è che, dietro l’hype, c’è una realtà che pochi raccontano onestamente: per circa l’80% delle PMI italiane, Kubernetes è semplicemente overkill. Costoso, complicato, fragile se mal gestito, e soprattutto sproporzionato rispetto al problema reale che hanno da risolvere.

Questo articolo non è un attacco a K8s — è una piattaforma straordinaria, nata per orchestrare carichi su scala Google e oggi standard de facto per il container orchestration. È piuttosto un invito alla lucidità: scegliere Kubernetes “perché lo usano tutti” significa pagare un costo enorme in termini di team, tooling, complessità e tempo sottratto al business. In una PMI con 8 persone e tre microservizi, quel costo non è ammortizzabile. L’opportunity cost — ciò che il team non sta facendo perché sta lottando con YAML, controller e ingress — è quasi sempre più alto del valore che K8s porta. Vediamo quando ha davvero senso adottarlo, quando no, e quali alternative pragmatiche esistono nel 2022.

Cos’è Kubernetes e quali componenti devi conoscere

Kubernetes (spesso abbreviato in K8s) è un sistema open source per automatizzare il deployment, lo scaling e la gestione di applicazioni containerizzate. Nasce in Google nel 2014 come reimplementazione open source di Borg, il sistema interno con cui Big G orchestra miliardi di container ogni settimana. Nel 2015 viene donato alla CNCF (Cloud Native Computing Foundation) e da allora è cresciuto fino a diventare il progetto open source con la community più attiva al mondo dopo il kernel Linux. La versione corrente al momento di scrivere è Kubernetes 1.23 (rilasciata a dicembre 2021), con la 1.24 in preview e attesa per fine aprile 2022.

Per capire se ti serve, devi conoscere almeno cinque concetti fondamentali:

• Control plane: il “cervello” del cluster. Include API server, scheduler, controller manager ed etcd (database chiave-valore distribuito). Su un managed K8s lo gestisce il provider; on-premise devi gestirlo tu.
• Node: una macchina (VM o bare metal) su cui girano i carichi. Su ogni node troviamo kubelet (l’agente che parla col control plane) e un container runtime (containerd è diventato il default da K8s 1.24; CRI-O è l’alternativa enterprise; dockershim è stato rimosso definitivamente).
• Pod: l’unità minima di deployment. Un pod contiene uno o più container che condividono rete e storage. È effimero: muore, ricrea, viene rischedulato altrove.
• Service: astrazione di rete che dà un endpoint stabile a un set di pod. Tipologie: ClusterIP (interno), NodePort (esposto su tutti i nodi), LoadBalancer (richiede integrazione cloud).
• Ingress: regole HTTP/HTTPS che routano traffico esterno verso i service. Richiede un ingress controller (NGINX, Traefik, Contour, Kong, HAProxy) installato a parte.

Intorno a questi cinque oggetti ne ruotano altri trenta (Deployment, StatefulSet, DaemonSet, Job, CronJob, ConfigMap, Secret, PersistentVolume, NetworkPolicy, ServiceAccount, RBAC, HPA, VPA, PDB, CRD). Qui inizia la curva di apprendimento.

Perché Kubernetes esiste: il problema che risolve davvero

Kubernetes è nato per risolvere un problema specifico: orchestrare migliaia di container su centinaia di server in modo dichiarativo, resiliente e self-healing. Quando dichiari “voglio 50 repliche di questo servizio, distribuite su tre zone, e se una muore ricreala automaticamente”, K8s lo fa per te. Per i rilasci senza downtime fa rolling update e rollback automatico se health-check falliscono. Quando il traffico raddoppia, K8s scala i pod (e i nodi via cluster autoscaler).

Questo modello dichiarativo basato su YAML versionato in Git è elegante. Risolve in modo unificato problemi che prima richiedevano Ansible, Puppet, script bash e tre persone in reperibilità. Ma risolve problemi che esistono solo a una certa scala. Se hai 3 servizi su una VM da 50 €/mese, non hai bisogno di orchestrare nulla: ti serve un PaaS che faccia git push.

5 segnali che ti serve davvero Kubernetes

Adottare K8s ha senso quando soddisfi almeno tre di questi cinque criteri, non quando ne soddisfi uno solo:

1. Hai più di 10 microservizi in produzione (o ne avrai a 12-18 mesi con roadmap verificata, non a sensazione). Sotto questa soglia, Docker Compose o un PaaS gestiscono tutto con meno friction.
2. Hai più team di sviluppo che devono operare in autonomia sullo stesso cluster. Il modello multi-tenant di K8s (namespace, RBAC, ResourceQuota, NetworkPolicy) è una delle sue killer feature.
3. Devi essere multi-cloud o ibrido per regolamentazione, lock-in avoidance o continuità operativa. K8s è quanto di più portabile esista oggi tra AWS, Azure, GCP e on-premise.
4. Fai più di 100 deploy al giorno e ti serve un’infrastruttura che supporti pipeline CI/CD e GitOps spinte (ArgoCD, Flux v2, Tekton).
5. Hai requisiti di networking complessi: service mesh, mTLS service-to-service, policy fine-grained, traffic splitting per canary release, multi-cluster federation.

5 segnali che NON ti serve Kubernetes

Specularmente, evita K8s come la peste se ti riconosci in tre o più di questi punti:

1. Hai meno di 5 servizi e un’architettura monolitica o 2-tier (web + DB). Per un Laravel + MySQL su DigitalOcean, K8s è come usare un escavatore per piantare un chiodo.
2. Il tuo team di sviluppo è composto da meno di 3 persone. K8s richiede tempo: ogni ora spesa a debuggare un Ingress è un’ora non dedicata al prodotto.
3. Non hai un DevOps o SRE senior in team. K8s production-grade richiede competenze su networking, storage, security, observability. Non è un weekend project.
4. Il tuo budget cloud è inferiore a 5.000 € al mese. Sotto questa soglia il cluster control plane e i tool circostanti (logging, monitoring, ingress, certificati) mangiano una percentuale enorme del budget infrastruttura.
5. Non hai una pratica SRE consolidata: niente SLO, niente runbook, niente post-mortem, niente on-call strutturato. K8s amplifica i problemi quando non sai gestirli.

Le alternative pragmatiche: PaaS, Container-as-a-Service e Docker Compose

Se i segnali ti dicono “no K8s”, non sei rimasto al 2010: il panorama di alternative moderne è ricchissimo. Ecco quelle più valide per una PMI italiana nel 2022:

PaaS classici (git push e ti deploya)

• Heroku: il padre di tutti i PaaS. Ottimo per startup, ma pricing aggressivo sopra i 25 dyno e dipendenza forte dal vendor.
• Render: alternativa Heroku più moderna, con free tier generoso e supporto nativo per Docker, cron job e static site. Crescita rapida nel 2021-2022.
• Railway: esperienza developer eccezionale, pricing trasparente basato su utilizzo. Ideale per progetti early-stage.
• Fly.io: esegue container sul loro edge globale con latenza bassissima. Ottimo per app distribuite geograficamente.

Cloud provider managed (livello intermedio)

• AWS Elastic Beanstalk: il “PaaS di AWS”, maturo e integrato con l’ecosistema AWS. Buono per migrazioni esistenti.
• AWS App Runner: GA nel 2021, esegue container HTTP senza dover gestire cluster. Auto-scaling fino a zero.
• Azure App Service / Container Apps: il workhorse di Microsoft. Container Apps (in preview pubblica al momento) è costruito sopra K8s + KEDA + Dapr ma completamente managed.
• Google Cloud Run: serverless container con scaling a zero. Paghi solo le richieste effettive. Eccellente per workload HTTP stateless.
• DigitalOcean App Platform: esperienza simile a Render con pricing prevedibile. Adatto a PMI che non vogliono complessità AWS.

Docker Compose + VPS (per chi vuole controllo senza orchestrazione)

Per molte PMI italiane, la soluzione più sensata resta Docker Compose su un VPS (Hetzner, OVH, Aruba, DigitalOcean). Con un singolo file docker-compose.yml orchestri 5-10 container, fai backup con cron, monitoraggio con Uptime Kuma e basta. Non è “moderno” come K8s, ma è robusto, comprensibile e costa 80 € al mese invece di 800.

HashiCorp Nomad: l’orchestratore semplice

Nomad merita un capitolo a parte. È un orchestratore di workload (non solo container: anche binari Java, exec, qemu) sviluppato da HashiCorp. Architetturalmente è 10 volte più semplice di K8s — un singolo binario, niente etcd, niente kubelet, modello a “task driver”. Per PMI che hanno bisogno di scheduling distribuito ma non vogliono adottare K8s, Nomad è l’opzione razionale. Si integra nativamente con Consul (service discovery) e Vault (secret).

La svolta Docker Desktop di gennaio 2022: cosa cambia per le PMI

Un evento spesso sottovalutato del 2022 è il cambio di pricing di Docker Desktop. Da gennaio 2022 (con periodo di grazia fino a fine mese), Docker Desktop è diventato a pagamento per le aziende con più di 250 dipendenti o con un fatturato superiore a 10 milioni di dollari. Per molte PMI italiane medio-grandi questo ha significato dover scegliere: pagare la licenza Pro/Team (5-7 $/mese per utente) o cercare alternative.

Le alternative gratuite valide oggi sono tre:

• Rancher Desktop (SUSE): esperienza simile a Docker Desktop, include un mini-Kubernetes (k3s) built-in. Ottimo per chi vuole anche giocare con K8s in locale.
• Podman (Red Hat): daemonless, rootless, compatibile drop-in con la CLI Docker. Eccellente per ambienti enterprise Linux, meno maturo su Mac/Windows nel 2022.
• colima (open source): runtime container minimale per macOS basato su Lima. Lightweight, veloce, perfetto per developer Mac.

Per una PMI con 30 developer, la differenza tra pagare le licenze Docker Desktop (circa 2.500 $/anno) e adottare Rancher Desktop o Podman è significativa. Vale la pena valutare.

Kubernetes managed: confronto EKS, AKS, GKE

Se hai deciso che K8s ti serve davvero, non installartelo da solo. Gestire il control plane di K8s in produzione è un lavoro a tempo pieno che nessuna PMI italiana può permettersi. Usa una delle tre offerte managed dei big cloud:

• Amazon EKS: $0.10 per ora per cluster di control plane (~73 $/mese), più i costi delle EC2 worker. Ottima integrazione con IAM, VPC, ALB. Curva di apprendimento ripida per IAM.
• Azure AKS: control plane gratuito (paghi solo i nodi). Pricing aggressivo, eccellente integrazione con Azure AD e Azure Monitor. Sceglilo se sei già su Microsoft.
• Google GKE: il più maturo (Kubernetes è nato in Google). Modalità Autopilot (lanciata 2021) astrae anche i nodi e paghi per pod. Modalità Standard è più classica. $0.10/ora per cluster (esente il primo cluster zonale).

A questi vanno aggiunti tooling indispensabili: load balancer (15-25 $/mese cadauno), storage persistente, network egress, image registry, secret manager, CI/CD, monitoring. Un cluster K8s production-grade su AWS non scende sotto i 600-800 $/mese di infrastruttura pura, prima ancora di parlare di team.

Una novità interessante di marzo 2022 è il GA di AWS EKS Anywhere, che permette di eseguire EKS on-premise con supporto Amazon. Per aziende con vincoli di sovranità del dato (settore sanitario, PA, finance), è un’opzione concreta da valutare.

Lightweight Kubernetes: K3s, MicroK8s, k0s

Esiste una famiglia di distribuzioni K8s pensate per edge, IoT, sviluppo locale e ambienti resource-constrained. Sono “veri” Kubernetes ma con footprint enormemente ridotto (50-100 MB di RAM invece di 2-4 GB):

• K3s (SUSE/Rancher): il più popolare, singolo binario, embedded SQLite o etcd. Production-ready per edge e IoT.
• MicroK8s (Canonical): basato su snap, aggiunge feature on/off come moduli. Buono per dev e CI.
• k0s (Mirantis): single binary zero-dependency, focus su sicurezza e simplicità di upgrade.

Per una PMI che vuole “provare” K8s o gestire deployment edge (es. punti vendita con un mini-cluster locale), queste distribuzioni sono molto più sensate di un cluster managed completo. Ma attenzione: il fatto che siano “lightweight” non significa che siano “semplici da gestire in produzione”.

Helm, Kustomize, GitOps: come si gestisce un cluster

Nessuno scrive YAML a mano: si usa templating e versioning. Le opzioni mature nel 2022 sono:

• Helm 3.x: il “package manager di Kubernetes”. Chart riusabili, template engine, repository pubblici e privati. Standard de facto.
• Kustomize: built-in in kubectl da K8s 1.14, gestisce overlay senza template engine. Approccio dichiarativo.
• ArgoCD / Flux v2: motori GitOps, sincronizzano lo stato del cluster con un repo Git. ArgoCD ha UI più ricca, Flux è più modulare. Entrambi CNCF graduated.
• Tekton: framework CI/CD cloud-native su K8s. Pipeline come custom resource. Alternativa Kubernetes-nativa a Jenkins.

Sul cluster girano anche distribuzioni enterprise come OpenShift (Red Hat/IBM dal 2019) e Rancher (SUSE dal 2020). Sono “K8s opinionato” con dashboard e supporto enterprise.

Service mesh: quando serve davvero (spoiler: quasi mai sotto i 20 servizi)

Service mesh come Istio, Linkerd, Consul Connect e Kuma aggiungono al cluster un layer di sidecar proxy (tipicamente Envoy) che gestisce mTLS, traffic management, observability e policy. È una tecnologia potente ma introduce complessità enorme.

La regola pragmatica del 2022 è: non installare un service mesh se hai meno di 20 servizi che comunicano tra loro. Sotto questa soglia, il valore aggiunto è marginale e il costo cognitivo è altissimo. Se ti serve mTLS service-to-service, valuta Linkerd: è 10 volte più semplice di Istio e copre il 90% dei casi d’uso reali. Istio resta lo standard quando ti servono feature avanzate (traffic mirroring, fault injection, policy engine).

Observability: OSS vs SaaS

Un cluster K8s senza observability è una scatola nera. Hai due strade:

• Stack OSS self-hosted: Prometheus per metriche, Grafana per dashboard, Loki per log centralizzati (più economico di ELK), Tempo o Jaeger per tracing distribuito. Costo: zero licenze, ma 1-2 persone dedicate a mantenerlo.
• Stack SaaS: Datadog (potente, costoso a scale: 15-30 $/host/mese), New Relic (modello user-based più predicibile dal 2020), Dynatrace (focus AI/auto-instrumentation), Grafana Cloud (offerta managed dell’azienda Grafana).

Per una PMI sotto i 50 nodi, Datadog finisce per costare quanto un SRE senior. Lo stack OSS è quasi sempre la scelta giusta — a patto di avere chi se ne occupa.

Sicurezza Kubernetes: il capitolo che nessuno legge

K8s non è sicuro by default. Lo diventa solo se configurato correttamente. Strumenti chiave:

• RBAC + NetworkPolicy: permessi granulari e firewall L3/L4 tra pod. Senza NetworkPolicy tutti i pod si parlano — disastro.
• Pod Security Admission (PSA): rimpiazza le PodSecurityPolicy (deprecate in K8s 1.21). Profili baseline e restricted.
• Falco (CNCF graduated): runtime security, rileva comportamenti anomali nei container.
• Trivy e kube-bench: scan vulnerabilità immagini e verifica CIS Benchmark.
• Cilium: CNI eBPF con policy L7 avanzate.

Non gestire nessuno di questi è la norma per i cluster K8s “fatti da soli” delle PMI. Ed è il motivo per cui molti finiscono nei titoli per data breach.

Quanto team serve per K8s production-grade

Numero realistico: 3-5 SRE/platform engineer come minimo. Servono copertura on-call (2 in rotazione), una persona sul security posture, un developer experience engineer per il platform layer. Le competenze su networking, storage e observability raramente convivono in una sola persona.

Costo annuo in Italia di un team simile: 250-400 K€ in salari, prima di tooling, formazione e certificazioni. Se il tuo budget IT è 200 K€, K8s non è la tua battaglia.

TCO realistico: K8s vs PaaS managed per una PMI tipo

Confrontiamo numeri reali per una PMI con 8 servizi backend, 1 milione di richieste/giorno, 30 developer:

• Soluzione Kubernetes (managed EKS): infrastruttura 800 €/mese, observability 400 €/mese, tool security 200 €/mese, team SRE (3 persone) 180.000 €/anno, tooling licenze 15.000 €/anno. Totale anno 1: ~210.000 €, anno 2+ ~196.000 €.
• Soluzione PaaS (Render/Fly.io/Cloud Run): infrastruttura 2.500 €/mese, observability 300 €/mese, 1 platform engineer 70.000 €/anno. Totale anno 1: ~104.000 €.

Differenza: circa 100.000 € all’anno a parità di carico. Se il tuo vantaggio competitivo non si gioca sulla portabilità multi-cloud o sulla complessità orchestrale, quei 100 K€ in marketing, prodotto o nuove assunzioni rendono molto di più.

Gli errori comuni delle PMI che adottano Kubernetes

Pattern ricorrenti di fallimento nelle adozioni K8s da parte di PMI italiane:

1. Adottare K8s perché “tutti lo usano”: motivazione FOMO, non tecnica. Cluster sovradimensionato, team in burnout, ritardi sul roadmap.
2. Nessun platform team dedicato: 5 implementazioni di logging, 3 ingress controller in parallelo, secret in plaintext.
3. Niente observability dal giorno 1: “lo aggiungiamo dopo”. Quando arriva l’incidente, sei cieco.
4. Secret in YAML committati su Git: usa SealedSecret, External Secrets Operator o SOPS + age.
5. Tag latest: deploy non riproducibili. Usa tag immutabili o digest SHA256.
6. Niente backup di etcd e cluster condivisi dev/staging/prod: due classici da evitare.

Decision framework: dovresti adottare Kubernetes?

Riassumiamo in un flowchart mentale. Rispondi sì/no:

1. Hai > 10 servizi o ne avrai entro 18 mesi con roadmap certa?
2. Hai almeno 2 team di sviluppo separati?
3. Hai budget per 2-3 SRE dedicati?
4. Hai requisiti multi-cloud o di portabilità verticale?
5. Hai una pratica SRE consolidata (SLO, runbook, on-call)?

Se hai risposto sì a 3 o più: K8s ha senso. Inizia con un PoC su managed K8s. Se hai risposto sì a 1-2: aspetta. Resta su PaaS o Nomad e rivaluta tra 12 mesi. Se hai risposto sì a 0: dimentica K8s per i prossimi 24 mesi. Concentrati su prodotto e team.

Roadmap 90 giorni se hai deciso di adottare K8s

Se la decisione è “sì K8s”, ecco un piano realistico che minimizza i rischi:

• Giorni 1-30 — Foundations: scelta provider (EKS/AKS/GKE), formazione team su K8s (CKA è un buon obiettivo), setup repo IaC (Terraform o Pulumi), definizione standard Helm chart aziendali.
• Giorni 31-60 — Cluster staging: deploy primo cluster staging con observability (Prometheus + Grafana + Loki), ingress (NGINX o Traefik), RBAC e NetworkPolicy di base, pipeline CI/CD GitOps con ArgoCD.
• Giorni 61-90 — Primo workload in produzione: migra un singolo servizio non-critico in produzione, definisci SLO, runbook, alerting. Solo dopo 30 giorni di stabilità migra il secondo.

Errore tipico: voler migrare tutto in 90 giorni. È un disastro garantito. Pianifica 12-18 mesi di migrazione graduale.

Domande frequenti

Kubernetes sostituisce Docker?

No. Docker è una piattaforma per costruire ed eseguire container; Kubernetes è un orchestratore che gestisce container in cluster. K8s può usare diversi container runtime (containerd è ora default, era Docker fino alla 1.23). Dal punto di vista developer, continui a usare i Dockerfile e a costruire immagini Docker.

Posso installare Kubernetes da solo on-premise?

Tecnicamente sì, con strumenti come kubeadm, kubespray o Talos. Operativamente sconsigliato: gestire control plane, etcd backup, upgrade, certificati richiede competenza che poche PMI italiane hanno internamente. Se vuoi K8s on-premise, valuta OpenShift, Rancher o EKS Anywhere.

Qual è la differenza tra K3s e Kubernetes “vero”?

K3s è una distribuzione completa di Kubernetes (conformant CNCF) ottimizzata per footprint ridotto. Rimuove feature legacy, usa SQLite di default invece di etcd, è un singolo binario. Per workload production a scale serve K8s standard; per edge, IoT e dev locale K3s è eccellente.

Quanto costa un cluster Kubernetes managed minimo?

Su AWS EKS: ~73 €/mese di control plane + 2 nodi t3.medium (~60 €/mese) + load balancer (~20 €/mese) + storage (~10 €/mese). Minimo realistico: 150-200 €/mese per un PoC. Per produzione, aggiungi observability, registry e secret manager: 500-1000 €/mese.

Ha senso usare Kubernetes solo per un’app monolitica?

No, è overkill puro. Per un monolite, un PaaS (Heroku, Render) o un VPS con Docker Compose risolve tutto. K8s ha senso quando hai multiple repliche, scaling dinamico, deploy frequenti e/o più servizi che interagiscono.

Serverless container come Cloud Run o App Runner sostituiscono K8s?

Per workload HTTP stateless, spesso sì e con un’ottima esperienza developer. Per workload stateful (database, queue, job long-running), no. La scelta dipende dal tipo di applicazione: se le tue app sono prevalentemente API HTTP stateless, Cloud Run o App Runner sono spesso la scelta ottimale.

Quanto tempo serve a un team per padroneggiare Kubernetes?

Per arrivare a un livello “production-ready” servono 6-12 mesi di lavoro intenso, includendo formazione, certificazioni (CKA, CKAD, CKS), pratica su cluster reali e gestione di almeno qualche incidente. Non sottostimare la curva.

Conclusioni: il pragmatismo come differenziale competitivo

Kubernetes è uno strumento straordinario. Risolve problemi reali a scala reale. Ma è anche, nelle parole di molti SRE veterani, “un cannone di precisione che a volte ti spari sui piedi”. Per la PMI italiana media — quella con 15 persone, 4 servizi, due deploy a settimana e un’unica persona che gestisce l’infrastruttura — adottare K8s significa pagare un costo enorme per benefici quasi nulli. Significa rallentare il prodotto, bruciare team e budget cloud, e finire con un cluster fragile gestito a metà.

Il messaggio chiave è questo: K8s è un power tool, e come ogni power tool va usato quando il problema lo richiede. Se il tuo problema è “deployare 3 servizi senza downtime”, un PaaS managed è la soluzione giusta. Se è “orchestrare 50 microservizi multi-team in multi-cloud”, K8s è la scelta. Non c’è bisogno di scusarsi se la propria architettura è “boring”: le architetture boring sono spesso quelle che generano più valore di business. Anche nel 2022, Heroku + Postgres + Sidekiq fa girare aziende multimilionarie. Anche nel 2022, Docker Compose su Hetzner regge migliaia di utenti senza patemi. La vera sofisticazione tecnica è scegliere lo strumento più semplice che risolva il problema. Tutto il resto è cargo cult.