Kubernetes Operator: cosa sono (con esempi)

Per garantire flessibilità e scalabilità Kubernetes offre funzionalità iniziali limitate. I K8s Operator sono estensioni software che sfruttano le API di Kubernetes per estenderne il comportamento. Cosa c’è da sapere sul loro funzionamento e quali sono i vantaggi concreti?

Kubernetes ha un asso nella manica che lo rende ancora più utile, potente e flessibile. Quell’asso si chiama Operator. Ed è reso possibile dal fatto che Kubernetes è stato progettato fin dall’inizio per l’automazione, che è integrata direttamente nel cuore stesso del software. Con Kubernetes, infatti, si possono automatizzare non solo la distribuzione e l’esecuzione di workload ma anche il modo con il quale Kubernetes stesso lo fa.

Per questo motivo gli Operator sono così potenti: consentono infatti di far funzionare in maniera automatica cluster e sistemi complessi sulla base di una serie di pattern e di principi. Gli Operator, cioè, sono dei pattern che consentono di estendere il comportamento del cluster senza modificare il codice di Kubernetes grazie alle API di quest’ultimo, che fungono infatti da controller di risorse personalizzate.

Per capire a cosa serve un Operator occorre prima capire cos’è, e cioè capire come funziona Kubernetes e perché gli Operator sono così utili.

Perché Kubernetes ha bisogno degli Operator

Se stai leggendo questo articolo probabilmente conoscerai già Kubernetes. Facciamo solo un breve ripasso per capire come si inseriscono gli Operator nella sua logica.

Kubernetes è un software open source per l’orchestrazione dei container, cioè per automatizzare il deployment, il dimensionamento e la gestione dei carichi di lavoro su container. Creato da Google nel 2014 - ispirato al proprio sistema di orchestrazione di workload, Borg - Kubernetes è stato donato alla Cloud Native Computing Foundation. Quest’ultima, parte della Linux Foundation, oggi lo mantiene e lo sviluppa insieme ad altre grandi aziende come Microsoft e Redhat.

Kubernetes segue due principi di base: semplicità e flessibilità da un lato, e la possibilità di rendere automatiche più funzioni possibili dall’altro. Questi sono i suoi principali punti di forza che lo rendono capace di scalare ed essere utilizzabile in contesti e con applicativi estremamente diversi tra loro.

Tuttavia questi stessi principi ne limitano anche le funzionalità iniziali a un insieme ristretto di comandi e operazioni che sono esposti attraverso delle API. Per fare cose più complesse questo insieme deve essere esteso e vanno create delle automazioni più sofisticate, adatte a singoli applicativi e al loro dominio specifico di azione. È qui che entrano in gioco gli Operator.

Gli Operator di Kubernetes gestiscono la logica delle applicazioni e fanno parte del piano di controllo di Kubernetes. Come tali sono controller che eseguono dei loop per verificare lo stato reale del cluster e quello desiderato, agendo per riconciliarli quando i due stati si stanno allontanando. Semplicità e flessibilità più automazione non solo consentono la creazione degli Operator, ma sono i principi di base che costituiscono le pietre angolari dell’architettura di Kubernetes.

Cos’è un Kubernetes Operator

Il concetto di Operator è stato introdotto nel 2016 dal team di sviluppo di CoreOS Linux (poi Container Linux).

La definizione di Operator fornita dallo stesso progetto Kubernetes è semplice: “Gli Operator sono delle estensioni software che utilizzano delle custom resources per gestire le applicazioni e le loro componenti”. Questo vuol dire che usando gli Operator è possibile considerare un’applicazione, anziché come un insieme di primitive (come Pods, Deployments, Services o ConfigMaps), come un singolo oggetto che espone solo le regolazioni che hanno senso per l’applicazione.

Si può dire di più, perché in realtà gli Operator consentono di implementare in modo automatico le attività tipiche dei Day-1 (installazione, configurazione, ecc.) e dei Day-2 (riconfigurazione, aggiornamento, backup, failover, ripristino, ecc.) per un software in esecuzione all’interno del cluster Kubernetes, integrandosi in modo nativo con i concetti e le API Kubernetes.

Questo è il motivo per cui sono chiamate “applicazioni native di Kubernetes ”.Questa definizione può essere anche vista in un altro modo, più operativo. I K8s Operator sono dei controller per il packaging, la gestione e il deploying di applicazioni su Kubernetes. Per farlo, l’Operator utilizza delle Custom Resource (CR) che definiscono la configurazione e lo stato voluto di una specifica applicazione tramite delle Custom Resource Definition (CRD).

Il ruolo dell’Operator è quello di riconciliare lo stato reale dell’applicazione con quello voluto dalla CRD usando un loop di controllo nel quale può automaticamente far scalare, aggiornare o riavviare l’applicazione. In pratica, Kubernetes offre dei comandi base, delle primitive, che possono essere utilizzate dagli Operator per definire azioni più complesse.

In definitiva gli Operator sono dei programmi veri e propri che girano nel cluster e interagiscono tramite le API di Kubernetes per automatizzare funzioni più complesse di quelle nativamente gestite da Kubernetes stesso.

Leggi anche: Kubernetes: quali sono i vantaggi per le aziende

K8s Operator: a che cosa serve e quali problemi risolve

Se tutto questo ti suona come un software automatico per l’amministrazione di un sistema, beh, hai ragione. Un Operator se vogliamo è proprio quello: un esperto al quale indicare cosa vogliamo e con quali strumenti, e che poi lavora incessantemente per raggiungere quell’obiettivo.

Da questo punto di vista gli Operator sono degli strumenti dichiarativi e non imperativi, perché il nostro ruolo è definire gli obiettivi e le risorse desiderate mentre la loro responsabilità è quella di adeguare il sistema per mantenerlo il più possibile vicino allo stato voluto.

Il numero di cose che possono essere automatizzate tramite un Operator è pressoché infinito, anche se ci sono alcune operazioni tipiche che sono più comuni.

• La possibilità di fare il deploying on demand di una applicazione;
• Fare backup dello stato di un’applicazione o ripartire da un determinato backup;
• Gestire l’aggiornamento di un’applicazione con tutte le sue dipendenze inclusi i nuovi settaggi di configurazione e le modifiche necessarie al database;
• Esporre un servizio a delle applicazioni che non supportano le API di Kubernetes.

Sono solo alcune delle possibili applicazioni dei K8s Operator. Il limite di quello che si può fare con gli Operator è legato alle capacità di chi li programma e alle necessità del progetto.

Mettiamola in questo modo: rispetto a Kubernetes, che permette di gestire un’applicazione utilizzando le sue API (e kubectl), un Operator è un controller che estende le funzionalità delle API e gestisce istanze complesse dell’applicazione al posto dell’utente. Per farlo usa da un lato le risorse proprie di Kubernetes e dall’altro delle competenze specifiche per quella particolare applicazione o dominio.

In questo modo gli Operator servono per automatizzare l’intero ciclo di vita del software che gestiscono, prendendo in carico le classiche attività da fare per il day 1 e day 2 che, senza automazione, sarebbero attività legate a uno o più operatori umani.

I vantaggi dei Kubernetes Operator

Gli Operator sono molto utili perché sono dei controller specifici per la singola applicazione, che estendono le funzionalità delle API di Kubernetes. In altre parole gli Operator insegnano nuovi trucchi a Kubernetes. Ma quali sono i vantaggi concreti che offrono? Vediamo un elenco dei principali benefici.

1. Gli Operator permettono di estendere le funzionalità di Kubernetes anche alle applicazioni di tipo stateful e non solo a quelle stateless. E già questo è un notevolissimo vantaggio, perché le applicazioni e i servizi cloud stateful sono molto più complessi da gestire di quelle stateless. Tra gli operatori stateful possiamo segnalare: Prometheus Operator per la soluzione di monitoraggio e Postgres Operator per gestire cluster di database PostgreSQL ad alta disponibilità.
2. Standardizzano le attività manuali e creano un approccio all’automazione comune e coerente.
3. Gli Operator possono essere facilmente trasportati da un ambiente all’altro e da un progetto all’altro. Questo ha permesso la nascita di un ecosistema con molti Operator più generici scaricabili, configurabili e utilizzabili per progetti diversi, senza bisogno di svilupparli internamente. Più avanti vedremo quali sono gli hub più popolari per trovare Operator generici.

Quest’ultimo vantaggio non è da sottovalutare. Infatti, la creazione da zero di un Operator non è propriamente facile. Per fortuna ci sono diverse alternative.

Best practice 2026

Quando possibile, è consigliabile limitare lo scope degli Operator a un singolo namespace anziché concederne l’accesso all’intero cluster. Questo approccio riduce la superficie di attacco, semplifica la gestione dei permessi RBAC e minimizza l’impatto di eventuali malfunzionamenti, mantenendo al contempo un maggiore isolamento tra i diversi team e progetti che condividono lo stesso cluster Kubernetes.

La questione della sicurezza merita un’attenzione particolare, perché è proprio qui che molti Operator¹ introducono rischi spesso sottovalutati. Per automatizzare deployment, riconciliazione dello stato e gestione delle risorse custom, un Operator richiede permessi che, se mal calibrati, diventano un punto debole: molti operatori distribuiti tramite Helm chart o OLM richiedono di default un ClusterRole con verbi ampi (get, list, watch, create, update, delete) su risorse cluster-wide. Un Operator compromesso, o affetto da un bug nella logica di riconciliazione, eredita quei privilegi e può agire su ogni namespace, inclusi i secret di altri team.

La differenza tra i due modelli di autorizzazione RBAC² ha un impatto diretto sul blast radius in caso di incidente:

Il percorso che segue una richiesta dall’Operator fino all’azione sul cluster aiuta a capire dove intervenire per applicare il principio del privilegio minimo:

Dalla nostra esperienza su cluster multi-tenant, la contromisura più efficace non è eliminare i ClusterRole, che restano necessari per gli Operator di piattaforma, ma applicare tre pratiche concrete: assegnare a ogni Operator un ServiceAccount dedicato invece di riutilizzare quello di default, ridurre i verbi RBAC allo stretto indispensabile evitando le wildcard (*), e verificare i manifest degli Operator di terze parti prima dell’installazione, poiché i valori di default dei chart tendono a essere permissivi per massimizzare la compatibilità. Strumenti come kubectl auth can-i --list per lo specifico ServiceAccount, o policy engine come Kyverno e OPA Gatekeeper, permettono di rendere questa verifica parte integrante della pipeline anziché un controllo manuale una tantum.

Operator prefabbricati e soluzioni Custom

Gli Operator sono decisamente complessi da creare da zero. Richiedono competenze di programmazione (Go³ preferibilmente, ma possono essere implementati in qualsiasi linguaggio trattandosi di comunicazioni client/server) e una conoscenza approfondita dei controller nativi di Kubernetes⁴ e dei suoi meccanismi di funzionamento (reconciliation loop). Per lo sviluppo in Go, lo standard de facto è oggi l’Operator SDK, parte dell’Operator Framework: gestisce gran parte del boilerplate del reconciliation loop e semplifica scaffolding, test e packaging degli Operator, riducendo la barriera d’ingresso per chi non vuole partire dai controller nativi.

Esistono però framework che permettono di ridurre questa complessità come:

• Operator Framework⁵
• Kubebuilder⁶
• Kubernetes Operators Framework⁷

Per fortuna, come abbiamo visto, gli Operator possono essere trasferiti da un ambiente all’altro e configurati in modo semplice. Per questo motivo è nata una vera e propria cottage economy che ha l’obiettivo di arricchire e semplificare le operazioni di deploy, gestione e dimensionamento delle applicazioni su Kubernetes tramite gli Operator.

Kubernetes Operator: alcuni esempi

Ad oggi, le fonti ufficiali dove poter cercare gli Operator esistenti in modo semplice, sono queste due applicazioni:

• Artifact HUB - dove troviamo sia operators che helm charts (CNCF project)
• Operator Hub - dedicato esclusivamente agli Operator (Redhat project)

Gli Operator ci permettono di trovare soluzioni a problemi molto diversi tra loro. Anziché da una lista di Operator, partiamo da alcune situazioni da risolvere e facciamo alcuni esempi.

Un caso emblematico è lo scaling basato su eventi esterni. L’Horizontal Pod Autoscaler nativo di Kubernetes ragiona su metriche come CPU e memoria, ma queste raramente riflettono il carico reale di un workload event-driven: un consumer che processa messaggi da una coda può restare a basso utilizzo di CPU pur avendo migliaia di messaggi arretrati. KEDA (Kubernetes Event-driven Autoscaling) risolve proprio questo scarto. È un progetto CNCF (graduato nel 2023) che agisce come Operator: introduce la Custom Resource ScaledObject e, tramite un set di scaler pronti all’uso, legge metriche da sorgenti esterne come Kafka, RabbitMQ, Prometheus, AWS SQS o Azure Service Bus, traducendole in decisioni di scaling.

La caratteristica più interessante, e spesso sottovalutata, è la capacità di scale-to-zero: quando non ci sono eventi da elaborare, KEDA porta a zero le repliche del deployment, per poi riattivarle non appena arriva il primo messaggio. Questo lo rende particolarmente efficace in ottica FinOps per workload intermittenti come job batch, pipeline di elaborazione asincrona o funzioni serverless self-hosted, dove pagare per pod inattivi è puro spreco.

Vuoi monitorare il tuo cluster?

Una soluzione end-to-end molto efficiente per il monitoraggio del cluster Kubernetes è basata sullo stack kube-prometheus. Si tratta di una raccolta di manifest Kubernetes, dashboard Grafana e regole Prometheus combinate con documentazione e script che forniscono un monitoraggio di facile utilizzo sfruttando l**’ Operator Prometheus**.

Vuoi automatizzare la gestione dei certificati TLS

In questo caso possiamo utilizzare Cert-manager⁸, l’add-on Kubernetes che permette di ottenere certificati SSL/TLS emessi da una lista di certification authority configurate nel cluster. In questo modo possono essere richiesti nuovi certificati al volo a ciascuno degli emittenti e utilizzati nel ciclo di vita dei servizi in maniera automatica, con supporto nativo sia per gli Ingress sia per la più recente Gateway API.

Vuoi automatizzare la gestione di una service mesh basata su Istio

L’Istio Operator⁹ è stato l’approccio storico per installare, aggiornare e gestire in automatico le configurazioni di Istio¹⁰ direttamente dal cluster. Oggi, però, questo metodo è deprecato: l’operator in-cluster è stato dichiarato deprecato in Istio 1.23 e rimosso a partire dalla 1.24. Per i nuovi progetti, quindi, l’installazione e la gestione del service mesh vanno affidate a Helm¹¹ oppure a istioctl¹², che restano gli strumenti supportati e consigliati per gestire il ciclo di vita di Istio e validare le relative API. La community si sta muovendo verso modelli di installazione più snelli e, soprattutto, verso l’architettura Ambient Mesh¹³, che elimina la necessità di iniettare un sidecar per ogni pod e sposta la gestione del traffico su un livello infrastrutturale condiviso, riducendo overhead e complessità operativa.

L’utilizzo sia in scenari DevOps che SRE permette di automatizzare fin dall’inizio la gestione mesh dei microservizi usati nel cluster Kubernetes: gestione, orchestrazione, sicurezza, comunicazioni e monitoraggio. Dopodiché si potrà rifinire questa iniziale implementazione in maniera non traumatica.

Un tassello sempre più rilevante di questa automazione è la Kubernetes Gateway API, l’evoluzione dell’Ingress pensata per superarne i limiti storici: configurazione monolitica, dipendenza da annotation proprietarie e assenza di una netta separazione dei ruoli tra chi gestisce il cluster e chi espone i servizi. La Gateway API introduce risorse distinte (GatewayClass, Gateway, HTTPRoute, GRPCRoute) che formalizzano proprio quella separazione delle responsabilità utile nei team DevOps e SRE, e che si sposa naturalmente con la gestione mesh del traffico.

Il segnale più chiaro della maturità di questo standard arriva dagli operatori che storicamente hanno definito il layer di rete su Kubernetes. Cilium implementa la Gateway API sfruttando il data plane basato su eBPF ed Envoy, offrendo routing L7, traffic splitting e TLS termination senza un Ingress controller separato. Istio, dal canto suo, ha eletto la Gateway API a metodo di configurazione predefinito del traffico ingress, relegando le vecchie risorse Gateway e VirtualService del proprio API set al ruolo di alternativa legacy. La direzione è netta: il supporto Ingress viene mantenuto per retrocompatibilità, ma l’investimento e le nuove feature convergono sulla Gateway API.

Per chi progetta oggi un’architettura mesh, questo significa poter adottare un’unica astrazione portabile tra provider e implementazioni diverse, riducendo il rischio di vendor lock-in legato alle annotation specifiche di ciascun Ingress controller.

Automatizzare la creazione di risorse su public cloud

Crossplane¹⁴ è un Kubernetes Operator che permette di creare e gestire risorse in cloud tramite la sintassi dichiarativa di Kubernetes, mappando una collezione di CRD, fornite dai crossplane-provider, con i servizi cloud offerti dal vendor specifico. Il tutto è finalizzato all’utilizzo da parte dei team delle applicazioni, che per farlo non hanno bisogno di scrivere alcun codice. Si tratta, in pratica, di automatizzare la creazione di risorse sul cloud pubblico.

Come spiegano gli autori stessi del progetto, che fa parte della CNCF: “ abbiamo creato Crossplane per aiutare le organizzazioni a creare i propri cloud come i fornitori di cloud creano i propri: con un control plane.”

Come gestire l’Elastic Cloud nel nostro cluster

L’Elastic Kubernetes Operator - realizzato ufficialmente dal progetto di Elastic - permette di automatizzare Elastic Search e Kibana su Kubernetes con delle configurazioni di deployment molto semplificate e una gestione resa facile. L’Operator supporta sia i Frozen Indices per gli storage di dimensioni maggiori che i Kibana Spaces, Canvas ed Elastic Maps, più la parte di monitoraggio dell’infrastruttura Kubernetes.

Conclusioni

Come abbiamo detto, gli Operator che abbiamo visto fin qui sono solo alcuni esempi. Esistono moltissimi altri Operator: da KNative¹⁵ a Cloud Foundry on Kubernetes¹⁶ fino ad Azure Spring Cloud, oggi rinominato Azure Spring Apps¹⁷, ¹⁸. E ovviamente ci sono Operator anche per molte altre delle più diffuse tipologie di servizi e applicazioni: Grafana, Jaeger¹⁹, ArgoCD²⁰, MongoDB, Rbac (il modello di Controllo d’accesso basato sui ruoli o Role Based Access Control).

Nel 2026 l’ecosistema degli Operator ha raggiunto una piena maturità: OperatorHub raccoglie ormai centinaia di soluzioni certificate e i principali database, message broker e piattaforme di osservabilità distribuiscono il proprio Operator come metodo di installazione predefinito. Per la maggior parte dei casi d’uso in produzione non serve più scrivere un Operator da zero, ma valutare e adottare quello giusto tra le opzioni disponibili.

In tutti i casi tuttavia, seppur molto diversi tra loro, vale sempre lo stesso principio. Il vantaggio degli Operator è di espandere le possibilità di automazione di Kubernetes. La presenza di un ampio ecosistema di K8s Operator consente di trovare soluzioni già pronte per la maggior parte dei casi d’uso.

Note e fonti