C'è un numero che non compare mai negli organigrammi: quello delle ore che un platform team dedica ogni settimana ad attività ripetitive, prevedibili e indispensabili. Rinnovo dei certificati TLS, rotazione delle credenziali, verifica dei backup, decisioni di scaling, approvazioni di rilascio. Lavoro che riempiva le board dei ticket e i venerdì pomeriggio, e che oggi — senza annunci, un ticket alla volta — viene assorbito da software pensato per farlo in modo più affidabile di un essere umano.
Il risultato si vede nelle revisioni di budget: team di piattaforma che restano sulla stessa dimensione mentre i team applicativi raddoppiano, e code di ticket che smettono di crescere. Non è magia: è il pattern degli operator Kubernetes che, da progetto CNCF a scelta standard di mercato, ha spostato la manutenzione dalla checklist umana al controllore automatico.
Cos'è un operator Kubernetes
La documentazione ufficiale di Kubernetes definisce l'operator pattern come la combinazione di un Custom Resource Definition (CRD) e di un controller: software che estende l'API di Kubernetes per codificare la conoscenza operativa di un dominio specifico, come la gestione di un database o di un certificato. In pratica, un operator osserva lo stato del cluster e lo porta verso lo stato desiderato dichiarato, esattamente come fa il controller nativo dei Deployment, ma per risorse che Kubernetes di default non conosce.
Tradotto: è un "collega" che non dorme mai, non dimentica un passaggio e applica la stessa procedura alle 2 di notte e alle 2 del pomeriggio. Non sostituisce il giudizio umano dove serve davvero (architettura, strategia, incident response): elimina la parte che giudizio non richiede, solo costanza.
Cosa assorbiva il tempo del platform team
Cinque anni fa, un team di piattaforma di medie dimensioni consumava gran parte della settimana su attività come:
- rinnovare i certificati TLS prima della scadenza, per evitare outage scoperti magari dal cliente;
- ruotare password e API key su decine di microservizi;
- controllare dashboard alla ricerca di pod da ridimensionare;
- ripristinare backup di prova per verificarne l'effettiva utilizzabilità;
- supervisionare e, al bisogno, annullare manualmente i rilasci.
Sono tutte attività importanti. E sono tutte attività che richiedono coerenza e velocità, non intuizione. Il candidato naturale a svolgerle è il software.
I sei operator che alleggeriscono la piattaforma
Ecco sei operator ampiamente adottati nell'ecosistema cloud native, con il riferimento alla documentazione ufficiale di ciascun progetto per chi volesse approfondire.
1. cert-manager: il rinnovo dei certificati che non scade mai
cert-manager è l'operator di riferimento per l'emissione e il rinnovo automatico dei certificati TLS in cluster Kubernetes e OpenShift. Come documenta il progetto, crea i certificati per i workload e li rinnova prima della scadenza, ottenendoli da una pluralità di autorità: Let's Encrypt tramite ACME, HashiCorp Vault, CA private e altre. Chiave privata e certificato finiscono in un Secret Kubernetes montato dal pod o usato dall'Ingress. Il risultato è che il "fire drill" del certificato in scadenza sparisce dalla scrivania: la risorsa Certificate dichiara cosa serve e il controller ci pensa, anche quando nessuno ha segnato il promemoria.
2. External Secrets Operator: la rotazione dei secret senza più martedì interi
External Secrets Operator (ESO) sincronizza i segreti da sistemi esterni — AWS Secrets Manager, Google Secret Manager, Azure Key Vault, HashiCorp Vault e molti altri — dentro i Secret di Kubernetes. Il tutto è dichiarativo: le risorse ExternalSecret, SecretStore e ClusterSecretStore descrivono cosa recuperare e da dove, e il controller aggiorna i Secret quando il valore sorgente cambia. La rotazione di una credenziale smette di essere un intervento manuale su una dozzina di servizi e diventa un evento propagato in automatico dal sistema che custodisce la verità.
3. Reloader: il riavvio dei workload alla modifica di configurazione
C'è un passaggio che i primi due operator da soli non chiudono: quando un Secret o una ConfigMap cambia, i pod in esecuzione continuano a usare la vecchia configurazione. Reloader è il controller che osserva Secret e ConfigMap referenziati dai workload (Deployment, StatefulSet, DaemonSet e anche Argo Rollout) e innesca automaticamente un rollout alla loro modifica. In combinazione con ESO, la catena si chiude da sola: rotazione del segreto nel vault, sincronizzazione nel cluster, riavvio pulito dei pod senza intervento umano.
4. KEDA: lo scaling guidato dagli eventi
KEDA porta l'autoscaling oltre CPU e memoria: scala Deployment, StatefulSet e Job in base a eventi reali, come la lunghezza di una coda su Kafka o RabbitMQ, il numero di richieste o qualunque metrica esterna. Non sostituisce l'Horizontal Pod Autoscaler: lo estende, alimentandolo con metriche esterne e gestendo in prima persona la scala da zero a uno e viceversa, fino allo scale-to-zero per i workload batch. Le decisioni di ridimensionamento smettono di dipendere da chi guarda la dashboard e diventano reattive al carico effettivo.
5. Velero: backup e ripristino che si possono verificare
Velero è lo strumento CNCF per il backup e il ripristino di risorse del cluster e volumi persistenti, pensato per disaster recovery, migrazione tra cluster e replicazione di ambienti. La vera differenza rispetto al passato è che il ripristino di prova non è più un'impresa da pianificare: la verifica dei backup diventa un'operazione ripetibile e programmabile, quindi qualcosa che si può davvero fare con regolarità, invece di scoprire all'occorrenza che un backup non era utilizzabile.
6. Argo Rollouts: rilasci progressivi con rollback automatico
L'ultimo anello è il rilascio. La strategia RollingUpdate nativa di Kubernetes offre garanzie limitate: pochi controlli sulla velocità, nessun controllo sul traffico verso la nuova versione e nessuna capacità di abortire e tornare indietro in automatico in caso di anomalia. Argo Rollouts aggiunge strategie blue-green e canary, spostamento graduale e pesato del traffico e analisi delle metriche (da Prometheus, Datadog, New Relic e altri) per decidere la promozione o il rollback. Le approvazioni manuali restano dove servono, ma la decisione di ritirare una release che degrada gli indicatori chiave può essere presa in pochi secondi dal controllore, senza aspettare che qualcuno se ne accorga.
Quale lavoro resta al team
Nessuno di questi strumenti elimina il platform team: ne cambia il lavoro. Le ore liberate dalla manutenzione ripetitiva possono tornare su attività a valore più alto: progettare la piattaforma, governare policy e costi, curare la sicurezza, affiancare i team applicativi. Ma è bene non idealizzare: ogni operator è software da installare, configurare, aggiornare e monitorare, e l'automazione sposta il rischio dall'esecuzione alla definizione delle regole. Un policy errata o un SecretStore mal configurato si ripetono in automatico, quindi revisione delle modifiche e osservabilità restano compiti irrinunciabili del team.
La lezione pratica è però chiara: quando una parte consistente del tempo del team è assorbita da attività deterministiche, il modo più efficace di "assumere" è automatizzare. I sei operator descritti coprono le aree che più spesso generano ticket: certificati, segreti, configurazione, scaling, backup e rilascio.
Come formarsi
Adottare questi strumenti richiede competenze solide su Kubernetes e sul modello dei controller: risorse dichiarative, RBAC, webhook, integrazione con i servizi cloud. Se vuoi portare queste competenze nel tuo team o prepararti a gestire una piattaforma più automatizzata, esplora il catalogo dei corsi Kubernetes e cloud native: trovi percorsi pratici per colmare il divario tra la teoria degli operator e l'operatività quotidiana.