Kubernetes: il grande bluff dell’era DevOps

Tra poco arriverà Kubernetes 2. E, come prevedibile, si dirà addio allo YAML. Finalmente. Sarà anche l’occasione per ammettere, in modo neanche troppo velato, che Kubernetes è stato — ed è tuttora — un caos ingestibile. Non un’innovazione, ma un groviglio tecnico elevato a standard, senza che nessuno abbia mai avuto il coraggio di fermarsi a dire: “Aspettate, ma ha davvero senso tutto questo?”.

La verità è che Kubernetes non è mai stato pensato per le persone normali, per gli sviluppatori comuni, per chi gestisce progetti reali con budget, deadline e ambienti in produzione da mantenere vivi 24/7. Kubernetes è stato concepito da un’élite tecnica — in gran parte ex ingegneri Google — che ha provato a replicare fuori da Google alcuni concetti presi da Borg, il sistema di orchestrazione interno dell’azienda. Peccato che Borg sia un sistema pensato per una scala che la maggior parte delle aziende non vedrà mai nemmeno da lontano. E che replicarlo male fuori da quel contesto non abbia portato ad alcuna rivoluzione, ma solo a ulteriore complessità.

Docker e il mito del mini-cloud fai da te

Per capire dove nasce la confusione, torniamo un attimo indietro. Docker ha avuto un senso quando è nato: era una scorciatoia per evitare il costo delle VM, gestendo ambienti pseudo-isolati in modo più leggero. Bene. Ma poi è arrivata la grande illusione: la possibilità di costruirsi un mini-cloud “come i grandi” usando solo qualche YAML e un po’ di scripting.

Ed è lì che il castello è crollato. Perché creare e gestire un ambiente containerizzato, orchestrato da Kubernetes, non è affatto semplice, né tanto meno automatico. Richiede competenze che non tutti hanno. Anzi, richiede una quantità impressionante di conoscenza trasversale:

• Semantica Kubernetes, che è di una complessità fuori scala. La semantica di Kubernetes rappresenta uno degli ecosistemi più complessi dell’IT moderno. Non si tratta solo di comprendere pod, service e deployment, ma di padroneggiare un intero universo di primitive interconnesse: ReplicaSet, StatefulSet, DaemonSet, Job, CronJob, ConfigMap, Secret, PersistentVolume, StorageClass, Ingress, NetworkPolicy, RBAC, CustomResourceDefinition. Ogni oggetto ha il proprio ciclo di vita, stati, condizioni e finalizer. La complessità si amplifica quando si considera l’interazione tra questi elementi: come un HorizontalPodAutoscaler monitora metriche custom attraverso il metrics server, come gli admission controller validano e mutano le risorse in ingresso, come il garbage collector gestisce le dipendenze owner-reference. Il modello dichiarativo richiede una mentalità completamente diversa dalla gestione imperativa tradizionale, dove si descrive lo stato desiderato piuttosto che i passi per raggiungerlo.

• Networking TCP/IP a livello profondo, con overlay, plugin, service mesh, DNS interni. Il networking in Kubernetes opera su multiple layers di astrazione che richiedono una comprensione profonda dello stack TCP/IP. Gli overlay network come Flannel, Calico, Weave creano reti virtuali che attraversano nodi fisici, utilizzando tecnologie come VXLAN, BGP, IP-in-IP tunneling. I Container Network Interface (CNI) plugin gestiscono l’assegnazione di IP ai pod, la configurazione di routing tables, iptables rules, e bridge virtuali. I service mesh come Istio, Linkerd, Consul Connect introducono un ulteriore layer di complessità con sidecar proxy che intercettano tutto il traffico, implementando load balancing avanzato, circuit breaking, retry policies, mutual TLS. Il DNS interno (CoreDNS) deve risolvere service discovery dinamico, gestire zone splitting, e sincronizzarsi con service registry esterni. La troubleshooting richiede competenze in packet capture, analisi di iptables chains, comprensione di netfilter hooks, e debugging di conntrack tables.

• Sistemistica Linux a livello avanzato: debugging dentro container, tracing di processi zombie, troubleshooting di pod che non partono senza alcuna logica apparente. Su AlmaLinux, la sistemistica per Kubernetes richiede competenze Linux kernel-level applicate a ambienti containerizzati. Il debugging dentro container coinvolge namespace isolation (PID, NET, MNT, IPC, UTS, USER), cgroups v1/v2 per resource limiting, e capabilities per security boundaries. I processi zombie nei container richiedono comprensione di init systems (spesso tini o dumb-init), signal handling, e process reaping. Quando i pod non si avviano senza logica apparente, bisogna analizzare: kubelet logs, container runtime (containerd/CRI-O) status, seccomp profiles, AppArmor/SELinux policies su AlmaLinux, resource quotas, node affinity/anti-affinity rules. Gli strumenti essenziali includono nsenter per entrare nei namespace, crictl per debugging CRI, systemd-analyze per performance, strace per system call tracing, e perf per profiling. Su AlmaLinux specificamente, la gestione di SELinux contexts per container, firewalld rules, e systemd service dependencies aggiunge ulteriore complessità.

• Storage distribuito, replica di volumi, persistence di dati volatili in ambienti effimeri. Lo storage distribuito in Kubernetes affronta la sfida fondamentale di mantenere persistenza in un ambiente progettato per essere effimero. I PersistentVolume e PersistentVolumeClaim creano un’astrazione tra storage fisico e consumo applicativo, supportando provisioning dinamico attraverso StorageClass. I sistemi di storage distribuito come Ceph (Rook), GlusterFS, Longhorn implementano replica multi-nodo per alta disponibilità, con algoritmi di consensus per consistency. La gestione include snapshot e backup incrementali, resize dinamico di volumi, migrazione live di dati tra nodi. Le sfide specifiche comprendono: split-brain scenarios in network partitioning, performance tuning per IOPS/throughput, gestione di failure domains per replica placement, encryption at-rest e in-transit. I CSI (Container Storage Interface) driver devono gestire attach/detach operations, mount propagation, e filesystem specifics. La troubleshooting richiede comprensione di block devices, filesystem internals, network latency impact su distributed consensus, e monitoring di storage metrics per capacity planning e performance optimization.

Senza dimenticare tutto il carico mentale legato alla gestione degli aggiornamenti, ai problemi di sicurezza, alla gestione dei secrets, ai deployment automatizzati, ai container registry privati e chi più ne ha più ne metta.

YAML, quel linguaggio non-linguaggio

Il manifesto della follia Kubernetes si incarna nel suo uso estremo del formato YAML. L’idea era quella di “descrivere l’infrastruttura”, non di codificarla. Ma poi, come spesso accade, la teoria si è scontrata con la realtà: i file YAML sono diventati lunghi, contorti, pieni di proprietà obbligatorie e semantiche implicite. Cambiare una virgola può significare mandare giù un intero cluster.

E soprattutto, ogni YAML è strettamente dipendente dal comportamento dell’immagine Docker sottostante. E quell’immagine, a sua volta, è costruita su uno o più strati di filesystem derivati da chissà quale distribuzione Linux, con configurazioni spesso opache. Il risultato? Un delirio di astrazioni, in cui è difficilissimo prevedere cosa succederà esattamente quando lancerai il tuo deployment.

Un microservizio, mille problemi

Chi ha pensato che Kubernetes fosse la panacea per gestire architetture a microservizi dovrebbe fermarsi a riflettere. Perché ogni nuovo microservizio è un nuovo container, con un proprio ciclo di vita, una propria configurazione, un proprio set di variabili di ambiente, un proprio file YAML, una propria policy di rete.

Ogni container diventa, potenzialmente, una nuova bomba ad orologeria. E chi la innesca? Il developer.

Perché sono i developer che preparano le immagini. Non i sistemisti. Ma nella maggior parte dei casi gli sviluppatori non hanno le competenze sistemistiche necessarie per fare un lavoro sicuro, stabile e manutenibile. Non sanno come isolare correttamente i processi, come gestire le variabili sensibili, come implementare meccanismi di logging persistente o monitoraggio.

Ed è così che, lentamente, l’intera architettura si riempie di punti deboli. Non è una questione di se, ma di quando qualcosa esploderà.

L’illusione del cloud-native

A tutto questo si aggiunge un altro equivoco: la retorica del “cloud-native”.

Tutti vogliono essere cloud-native. Ma pochi sanno cosa significa davvero. Essere cloud-native non significa mettere Laravel in un container e chiamarlo microservizio. Significa ripensare completamente il modo in cui si costruiscono le applicazioni:

• Event-driven, non sincrone.

• Stateless by design.

• API-centriche.

• Fault tolerant.

• Scalabili dinamicamente.

• Con logging e observability nativi, non incollati dopo.

Tutto questo non lo ottieni mettendo un monolite in un container e dandogli in pasto Kubernetes. Eppure, è esattamente ciò che fanno in molti. Perché l’illusione è che Kubernetes “penserà a tutto”. Ma Kubernetes non pensa. Kubernetes esegue. Male, se configurato male. E viene configurato male spesso, perché è troppo complesso per essere configurato bene da chi non è specializzato.

Debugging: l’inferno sulla Terra

Un esempio su tutti: il debugging.

Hai mai provato a fare troubleshooting su un cluster Kubernetes reale in produzione, con dieci pod che girano, log dispersi su mille nodi, container che si riavviano senza log, metriche che spariscono, e il tuo unico strumento è un kubectl describe o un kubectl logs che spesso non restituisce nulla?

Hai mai provato a entrare in un container schiantato, magari basato su Alpine, senza bash, senza vi, senza strumenti di analisi, senza nulla?

Se non lo hai fatto, ti invidio. Se lo hai fatto, sai esattamente di cosa sto parlando.

Kubernetes non è un ambiente pensato per il troubleshooting. È un sistema che assume che tutto andrà bene, che ogni cosa sia idempotente, che i pod possano essere buttati giù e rialzati senza stato. Ma la realtà è diversa. La realtà è fatta di eccezioni, errori, condizioni impreviste. E in quel momento, Kubernetes non ti aiuta: ti ostacola.

E ora arriva l’AI

Se prima si poteva anche pensare di far finta di niente — costruire due container, usare Kubernetes come orchestratore di microservizi finti, e passare il resto del tempo a patchare i problemi — ora non è più possibile.

L’intelligenza artificiale ha cambiato le regole del gioco.

Le applicazioni AI moderne sono cloud-native per davvero. Sono fatte di decine di API che comunicano tra loro, spesso in streaming, con gestione di GPU, modelli da caricare in memoria, orchestration dinamica, logging intensivo, auditing, observability, costante aggiornamento.

Non puoi improvvisare. Non puoi più pensare di buttare un paio di container su un cluster e incrociare le dita. Serve un’infrastruttura solida, pensata per gestire complessità reali, ma con strumenti che non ti uccidono ogni volta che devi cambiare qualcosa.

Ed è per questo che sempre più aziende stanno cercando alternative. Vogliono semplificare. Vogliono tornare a un modello che ha senso, che possa essere gestito da team umani senza dover diventare dei Kubernetes Ninja. Vogliono un ambiente che sia stabile, prevedibile, manutenibile.

Il futuro? Meno orchestrazione, più standard

Il segnale è chiaro: la direzione giusta non è aggiungere ulteriori strati sopra Kubernetes (piattaforme PaaS, service mesh, tool di gestione YAML, interfacce grafiche… tutto fumo negli occhi), ma ridurre la complessità, partire da una base più semplice, standardizzata, serverless quando possibile.

Non serve orchestrare tutto. Serve orchestrare bene ciò che serve davvero, in modo ripetibile e automatico, lasciando che la maggior parte dei workload si comportino come servizi disaccoppiati, stateless, resilienti per progettazione.

Conclusione: è ora di svegliarsi

Kubernetes è stato utile per capire quanto può essere difficile fare orchestrazione a scala. Ma non è una soluzione per tutti. E, soprattutto, non è l’unica soluzione possibile. È un sistema che nasce da esigenze specifiche di aziende enormi, con team specializzati, processi interni rigidissimi.

La maggior parte delle aziende non ha bisogno di Kubernetes. Ha bisogno di ambienti più semplici, più umani, più standardizzati. Dove sviluppatori e sistemisti possano collaborare senza il costante rischio di creare architetture ingestibili.

Per questo, oggi, quando dici a un team che può fare AI cloud-native privata senza dover affrontare l’inferno di Kubernetes, ti guardano con stupore. E poi stappano lo champagne.

Perché finalmente — dopo anni di hype, complicazioni, YAML infernali e pod fantasma — qualcuno ha avuto il coraggio di dire la verità: Kubernetes non è il futuro. È stato un incidente di percorso.