Let’s develop a .NET smooth operator

Il caso di studio: realizzare una piattaforma per il rilascio di siti web

Per spiegare gli operator e i vantaggi di questo tipo di soluzione, Christian e Simone hanno preso come esempio la realizzazione di una piattaforma che permette il rilascio di siti web. A una prima analisi questa non sembra affatto una applicazione complessa, iniziamo però ad aggiungere alcuni requisiti:

• ogni sito deve essere indipendente e ogni problema al suo interno non deve compromettere il funzionamento degli altri;
• tutti i siti devono essere scalabili (per esempio, un sito che registra un carico extra improvviso deve continuare a funzionare) e veloci;
• la creazione deve essere totalmente dinamica.

Che opzioni abbiamo?

Dimentichiamoci di Kubernetes e affidiamoci a un professionista, per esempio un amministratore di siti web, il quale farebbe tutto il lavoro per noi. Opzione sconsigliata perché non dinamica, oltre che poco “automatica”.

Utilizziamo script che contengono il comando kubectl (comando principale per lanciare comandi verso un cluster Kubernetes) oppure ricorriamo a Helm, uno strumento per la gestione delle risorse Kubernetes (a tal proposito, leggete l’articolo di approfondimento “Helm: gestire in maniera semplice ed efficace i pod Kubernetes” scritto da Simone). Soluzioni del genere sono sicuramente veloci da implementare, ma sarebbero allo stesso tempo poco sicure perché richiederebbero l’esposizione delle API del cluster Kubernetes. Non solo. Queste soluzioni sono poco resilienti e non semplici da modificare, e comporterebbero un monitoraggio manuale, operazione che oltre a essere noiosa è anche tediosa.

E se esponessimo le API del Control Plane? (in un cluster Kubernetes, Control Plane è la risorsa base che permette di modificare il cluster. Sono delle API appunto, utilizzate da Christian e Simone nella demo mostrata durante la sessione). Una soluzione più sicura rispetto al precedente, ma non di semplice implementazione. Anche la fase di monitoraggio risulterebbe complessa.

Potremmo usare il pattern Operator. Sarebbe una strada totalmente sicura dato che non richiederebbe di esporre le API di Kubernetes e l’intera applicazione verrebbe eseguita sul cluster su cui si sta lavorando; è inoltre un pattern semplice da utilizzare che, tra le altre caratteristiche, gestisce molte complessità “out of the box”.

Vediamo quindi cosa vuol dire Operator e come funziona.

Gli Operator in Kubernetes

Cosa sono

Gli Operator in Kubernetes sono a tutti gli effetti delle sue estensioni. Kubernetes stesso mette a disposizione questo tipo di pattern, e ne suggerisce l’applicazione.

Lo stesso Prometheus, un’applicazione molto utilizzata per il monitoraggio degli eventi e quindi il log dei pod presenti nel cluster, è un operatore.

Come funzionano

Kubernetes è un framework con un’architettura che, tra le altre sue caratteristiche, lavora con stati dichiarativi. In breve, per ogni risorsa dell’applicazione, viene dichiarato lo stato atteso e l’Operator, che altro non è che un software, esegue tre azioni:

• osserva lo stato della risorsa;
• realizza un report, che sostanzialmente contiene le informazioni della differenza tra lo stato corrente (quello che c’è) e lo stato desiderato. La verifica avviene continuamente (in gergo tecnico, reconcile loop);
• agisce, ovvero ogni volta che si notano differenze tra gli stati, l’Operator applica queste differenze sul cluster e di conseguenza le risorse sono attive e funzionanti.

Lo stato desiderato, tradotto in termini tecnici, è una Custom Resource Definition, niente di diverso dal concetto di interfaccia che ogni programmatore già conosce. Una Custom Resource Definition in Kubernetes definisce come dovrebbe essere una risorsa, ed è lo stato dichiarativo che viene controllato da un Operator.
Una Custom resource è invece l’effettiva implementazione di una Custom Resource Definition, lo stato effettivo che vorremmo avere.

Come sono fatti?

Ogni Operator è composto da due componenti principali:

• watcher: resta in attesa e osserva gli eventi (un pod che cessa l’esecuzione, una nuova risorsa creata ecc.);
• controller: per ogni evento occorso, cerca le differenze tra i due stati e le applica alle risorse interessate. Esempi di eventi: cancellazione di un pod, modifica di una Custom Resource ecc.

Un esempio pratico: un’applicazione che permette la creazione di siti web

Riprendendo il caso di studio all’inizio della loro sessione, Simone e Christian hanno condotto una demo di un’applicazione, che fa uso di un Operator, per la creazione di un sito web con pochi e semplici passi.

Di seguito i due progetti, entrambi disponibili online nel profilo GitHub di Christian:

• Smooth Operator (https://github.com/TheSimon9/smooth-operator): Operator, sviluppato in .NET v8, usando la libreria KubeOps che rientra nella lista di librerie ufficiali proposte da Kubernetes e sviluppate dalla community. KubeOps è un vero e proprio SDK che semplifica la creazione di un Operator; è infatti possibile creare, grazie a una serie di comandi specifici, tutti i file necessari (Dockerfile, manifest ecc.) per rilasciare un Operator.
• Smooth Operator Dashboard (https://github.com/TheSimon9/smooth-operator-dashboard): un semplice frontend composto da una form in cui l’utente, dopo aver inserito il nome, l’indirizzo e il messaggio del proprio sito web, può crearlo e compilarlo direttamente in un cluster Kubernetes.

Compilando il form viene fatta la pubblicazione della risorsa (Site nel caso specifico) in un cluster. L’Operator, accorgendosi dell’evento di creazione di una Custom Resource, genera il pod.
Christian e Simone, attraverso l’IDE Lens, hanno mostrato la lista dei pod relativi ai siti creati e rilasciati nel cluster Kubernetes, dimostrando come si comporta l’Operator in caso di eliminazione di una risorsa e della conseguente eliminazione del pod relativo.

Per ulteriori domande, non esitate a contattare Christian e Simone.