L’evoluzione dell’orchestrazione dei workload all’interno di container negli anni ha portato Kubernetes a diventare lo standard de-facto. Tuttavia, la crescente complessità delle applicazioni e dei sistemi su cui esse girano ha portato ad avere maggiore necessità di automazione e astrazione rispetto alle risorse native dell’API di Kubernetes.
Si è quindi sviluppato il concetto di Operator in Kubernetes, un pattern avanzato che offre un grado di automazione su misura per rispondere alle nuove esigenze
I Controller
Per capire il concetto di Operator, è necessario aver ben chiaro il concetto di Controller.
Infatti, in Kubernetes, i Controller gestiscono le risorse native di Kubernetes. Ad esempio, è molto probabile che abbiate installato sul vostro cluster Kubernetes un Ingress Controller, come ingress-nginx, HAProxy, Kong, o quelli messi a disposizione dal Cloud Provider di riferimento.
In questo caso specifico, il Controller verificherà attivamente la creazione, modifica o cancellazione di risorse Ingress e stabilirà come agire di conseguenza (in questo caso verranno fatte modifiche alle configurazioni di rete).
Le Custom Resource Definitions (CRD)
Le Custom Resource Definitions, comunemente abbreviate con l’acronimo CRD, sono un potente meccanismo messo a disposizione di Kubernetes che permette di estendere l’API nativa di Kubernetes. Tali risorse possono essere installate dinamicamente sul proprio cluster Kubernetes grazie ad un meccanismo di auto-registrazione che rende possibile la loro gestione anche tramite il noto client kubectl. Sono particolarmente adatte per rappresentare un’API dichiarativa che si integra bene con il ciclo di vita che Kubernetes adotta per le proprie API native.
Come Funzionano gli Operator
Un Operator è quindi composto dagli elementi che abbiamo appena esaminato: il Controller e la Custom Resource Definitions (CRD). Il Controller, può essere implementato utilizzando diversi linguaggi di programmazione e costituisce il nucleo dell’Operator stesso. Questo componente monitora costantemente le istanze delle Custom Resource definite dagli utenti, agendo in base agli eventi che si verificano in modo tale da garantire che il sistema si trovi nello stato desiderato. Tale meccanismo prende il nome di Reconciliation.
Ad oggi, esistono numerosi Operator pronti all’uso.
Ad esempio se ne possono trovare per la gestione di database all’interno di Kubernetes, per la gestione dell’autoscaling (vedi KEDA ), per la gestione della multi-tenancy all’interno di un Cluster Kubernetes (vedi Capsule) e così via… Si possono trovare Operator che risolvono diverse categorie di problemi. Laddove per soddisfare un bisogno fosse presente un Operator attivamente manutenuto ed evoluto e con un certo grado di maturità, è una soluzione preferibile rispetto alla gestione autonoma delle stesse funzionalità tramite API native di Kubernetes.
In ogni caso, è sempre possibile scrivere il proprio Operator, qualora ce ne fosse la necessità.
I benefici
L’utilizzo di questo pattern porta a svariati benefici:
- Automazione su misura: Gli Operator sono come sarti dell’automazione: consentono la creazione di logiche di gestione personalizzate per le applicazioni. Soprattutto se si parla di applicazioni stateful, è utile poter gestire agevolmente il ciclo di vita di più risorse.
- Riduzione della complessità nelle operazioni: Gli Operator semplificano le operazioni day-by-day, automatizzando compiti quali il provisioning, la scalabilità e la gestione degli aggiornamenti. Questo alleggerisce il carico di lavoro degli amministratori, liberandoli da attività manuali e soggette ad errori.
- Consistenza nell’Operatività: Gli Operator consentono di stabilire processi di gestione standardizzati per le applicazioni. Questo garantisce che tutte le istanze dell’applicazione vengano trattate in modo uniforme, rispettando le best practice, soprattutto in ambito di sicurezza e compliance.
- Ecosistema in Crescita: La comunità attorno a Kubernetes sviluppa attivamente nuovi Operator e quelli esistenti sono in continua evoluzione. Si tratta quindi sia di un mercato in crescita, sia di opportunità di progresso tecnologico grazie all’evoluzione della tecnologia.
Conclusioni
Il pattern Operator in Kubernetes è un passo avanti significativo nell’automazione delle operazioni per le applicazioni in container e rappresenta, oltre ad un modo efficace di implementare meccanismi personalizzati, anche di un’opportunità per esplorare meglio l’API di Kubernetes e il cambiamento culturale che ne deriva. Con la continua crescita della comunità e l’ampliamento dell’ecosistema di Operator, il futuro dell’automazione in Kubernetes si dirige sempre più verso una gestione personalizzata delle applicazioni.