Custom Control of NetworkServices in Kubernetes

L’obiettivo di questa tesi è definire e sviluppare un operatore Kubernetes, model driven e non specifico per una determinata applicazione, in grado di acquisire un numero di input generico, trattarli con una logica di business programmabile dall’esterno e non nota a priori, e generare un certo numero di output arbitrari. Questo paradigma applicativo ben si colloca nella gestione del ciclo di vita dei servizi basati su Virtual Network Function in una rete di telecomunicazioni ed in particolare copre le fasi di maintenance di un servizio tramite il concetto di closed loop. Come primo passo si è scelto di analizzare il funzionamento degli Operatori e dei Controller in Kubernetes e cercare di sfruttarli per creare un sistema in grado di rispettare i vincoli imposti dall’obiettivo. Dopo alcune prove e nonostante la potenzialità degli operatori, ci si è resi conto un sistema basato solo su di essi non è abbastanza versatile, le componenti sono molto dipendenti le une dalle altre e diventa difficile estenderlo. Esattamente il contrario delle caratteristiche che dovrebbe avere un’applicazione cloud-native. Per questo motivo si è deciso di seguire un paradigma di tipo event-driven, che con l’avvento dei microservizi, dei container e della computazione serverless si dimostra la soluzione migliore. In questo senso, è stato usato il framework Knative, la cui componente Eventing ci fornisce tutta l’infrastruttura per creare e gestire eventi. Grazie a Knative che ci offre Sources e Consumer possiamo risolvere il problema degli input e degli output generici, ma resta ancora il problema della logica di business programmabile. Quest’ultimo è stato risolto mediante l’utilizzo del framework Krules, che ci permette di scrivere delle regole in Python basate sul paradigma evento-condizione-azione. Mediante la definizione di queste regole è possibile definire a run-time il comportamento che dovrà avere l’applicazione, senza doverla riprogrammare e consentendole di controllare servizi generici semplicemente cambiando la logica di business. In altre parole il sistema è in grado di modificare il suo comportamento, a seconda del caso d’uso, in maniera semplice e dichiarativa. Infine per mostrare le potenzialità della soluzione adottata è stata realizzata l’implementazione di un caso d’uso specifico in cui, dopo la conferma di un operatore di sistema su Slack, sviene modificata la configurazione di un LoadBalancer per bilanciare il carico su un Firewall che ha aumentato il numero delle sue repliche.