Kubernetes nel mio lavoro: quando è giustificato e come lo uso

Kubernetes ha un problema di reputazione: metà del settore lo esibisce come un distintivo, l’altra metà lo considera una tassa. Per me è uno strumento con un punto d’ingresso chiaro. Un sito marketing o un MVP funziona benissimo su un solo server con un process manager e un job CI — è così che viene distribuito questo stesso sito. Kubernetes inizia a giustificarsi quando ci sono più servizi, carico variabile e più di un team che rilascia sulla stessa infrastruttura.

Tutto parte dal container. Dockerfile multi-stage, immagine runtime ridotta, nessuna dipendenza di sviluppo, utente non-root, un processo per container. Un’app Next.js viene compilata in modalità standalone; un’API NestJS include solo dist e node_modules di produzione. La stessa immagine passa dalla CI allo staging e alla produzione. Cambia soltanto la configurazione, tramite variabili d’ambiente, ConfigMap e Secret, mai una build per ogni ambiente.

Gli oggetti che uso ogni giorno sono pochi: un Deployment per servizio, un Service davanti, un Ingress con TLS per il traffico pubblico e un HorizontalPodAutoscaler per le parti che hanno davvero picchi di carico. Ogni container riceve requests e limits di risorse — senza, lo scheduler può solo tirare a indovinare. Le probe readiness e liveness sono separate apposta: readiness dice «non inviarmi ancora traffico», liveness «riavviami». Confonderle trasforma un database lento in una raffica di riavvii. Inoltre, ogni servizio Node.js gestisce SIGTERM e completa le richieste in corso, così un rolling update non interrompe un pagamento a metà.

Non tutto è un web server. I worker delle code hanno Deployment separati e scalano in base all’arretrato, non alla CPU. Le attività programmate — report, pulizie, riconciliazioni con un provider di pagamento — girano come CronJob con concurrencyPolicy: Forbid, così un’esecuzione lenta non si sovrappone alla successiva. Le migrazioni del database vengono eseguite come Job prima del rollout, non all’avvio dell’app: cinque repliche avviate insieme non devono tentare tutte la migrazione dello schema. PostgreSQL lo preferisco gestito, come RDS, invece che in uno StatefulSet: il cluster è per servizi stateless.

I manifesti vivono in Git e vengono revisionati come codice. Il deployment avviene con una pipeline CI che usa Helm o Kustomize, oppure con GitOps tramite Argo CD: un rollback diventa così un revert, non una sessione notturna con kubectl. kubectl apply dal portatile serve per imparare, non per la produzione. I log vanno su stdout e poi in uno storage centrale, le metriche su Prometheus e Grafana; seguo il rollout con kubectl rollout status invece di sperare. Su AWS questo significa di solito EKS con gruppi di nodi gestiti, così il team pensa al prodotto e non al control plane.

Rifiuto Kubernetes per un sito di due pagine, un service mesh prima ancora di avere più servizi, secret in YAML in chiaro nel repository e pod senza limiti perché «in staging funzionava». Se non sai se ti serve un cluster, mandami i servizi, il traffico e la dimensione del team. Ti dirò onestamente se è meglio Kubernetes, qualche container su un solo host oppure una piattaforma come Vercel — e quanto costa al mese, più o meno, ciascuna opzione.