Quando serve un consulente Kubernetes

La domanda che arriva troppo tardi

Di solito non mi chiamano perché “vogliono Kubernetes”. Mi chiamano perché Kubernetes c’è già, i workload girano, eppure ogni rilascio o ogni incidente costa più di quanto il team riesca a spiegare. Qualcuno ha ereditato un cluster montato in fretta; qualcun altro ha tre ambienti che dovrebbero essere uguali e non lo sono; la security chiede evidenze che nessuno sa estrarre senza una settimana di lavoro manuale.

La domanda utile non è “serve Kubernetes?”. È quando ha senso un consulente Kubernetes esterno, invece di un’altra sprint interna di patch e chart.

Segnali che l’intervento interno non basta più

Non tutti i cluster hanno bisogno di un consulente. Se avete un solo ambiente, pochi servizi e un team che conosce il perimetro, spesso basta tempo e disciplina. L’intervento esterno diventa conveniente quando compare uno di questi pattern.

1. Il day-2 mangia il day-1

Il cluster “è su”, ma aggiornare nodi, certificati, CSI, ingress o un chart critico è un progetto ogni volta. Non esiste un percorso ripetibile: esiste la persona che l’ultima volta “ha fatto in un modo che ha funzionato”.

2. Multi-tenancy di fatto, governance di nome

Namespace condivisi, ResourceQuota assenti o decorative, NetworkPolicy a macchia di leopardo, ambienti di test che possono toccare segreti di staging. Il cluster ospita più team senza un modello di isolamento esplicito. È il punto in cui incidenti banali diventano incidenti organizzativi.

3. GitOps a metà

Uno strumento GitOps è installato — open source o commerciale, poco importa — ma metà dei cambiamenti passa ancora da kubectl e da ticket. Lo stato desiderato non è la fonte di verità: è una speranza. In queste condizioni ogni audit e ogni disaster recovery riparte da zero.

4. Drift che nessuno misura

Immagini e chart avanzano a velocità diverse tra cluster e namespace. Sapete che siete indietro; non sapete di quanto, dove, e cosa è deprecato. È un problema di fleet, non di un singolo deployment.

5. CI che crea ambienti “quasi uguali” alla produzione

I test passano su un cluster improvvisato o su un namespace temporaneo senza le stesse policy, gli stessi ingress, gli stessi limiti. Poi in produzione emergono differenze che il CI non aveva visto. Qui spesso serve un modello di ambienti effimeri o di virtual cluster, non un’altra pipeline cosmestica.

Cosa fa (e non fa) un consulente Kubernetes

Un buon intervento non sostituisce il team: riduce il perimetro in cui il team deve improvvisare.

Nella pratica lavoro su quattro piani, descritti anche nella pagina di consulenza Kubernetes:

1. Architettura e confini — cluster vs namespace vs virtual cluster, rete, identity, limiti.
2. Operatività day-2 — upgrade, backup/restore verificati, osservabilità utile agli incidenti.
3. Consegna — GitOps coerente, ambienti di test che assomigliano alla produzione, pipeline che non mentono.
4. Trasferimento — runbook e scelte documentate, così il vantaggio resta dopo la consulenza.

Quello che non faccio è “installare un operator e andarmene”. Se dopo tre mesi solo io so perché quella NetworkPolicy esiste, l’intervento è fallito.

Consulente, formazione o Platform Engineering?

Tre leve diverse, spesso confuse:

• Consulenza Kubernetes quando il problema è il cluster (o la fleet) e serve progettare o rimettere in ordine.
• Formazione DevOps e Cloud Native quando il team ha già una direzione chiara ma gli mancano pratica e linguaggio comune.
• Platform Engineering quando il problema non è un cluster, ma il fatto che ogni team deve reinventare lo stesso cluster.

Se riconoscete due o più segnali della lista e il costo interno degli incidenti supera qualche settimana di focus esterno, ha senso parlare. Se invece state ancora scegliendo se adottare Kubernetes, partite da un assessment di migrazione e adozione cloud prima di comprare complessità.

Come si svolge un intervento tipico

1. Assessment breve — flusso reale dal commit alla produzione, privilegi, drift, punti di fallimento.
2. Priorità motivate — non una wishlist di tool; una sequenza impatto/sforzo.
3. Implementazione incrementale — prima stabilità e osservabilità, poi automazione, poi self-service.
4. Chiusura con ownership interno — documentazione delle decisioni e affiancamento, non dipendenza.

Lavoro come consulente freelance, prevalentemente da remoto, con clienti in Italia e in Unione Europea. Dettagli, FAQ e perimetro sono sulla pagina dedicata: Consulenza Kubernetes.

Se volete un secondo parere sul vostro caso senza impegno, scrivimi in poche righe: ambiente gestito o self-managed, quanti team sul cluster, e qual è l’incidente o il vincolo che vi ha fatto aprire questa pagina.