Dentro KubeFed

Kubernetes Cluster Federation (KubeFed), ancora in fase di sviluppo, offre un buon approccio al Kubernetes multi-region.

Lo scopo del concetto di federazione è infatti quello di ottenere applicazioni che siano distribuite a livello geografico, permettendo la realizzazione di un sistema di alta affidabilità (HA) e misure di disaster recovery.

Kubernetes Cluster Federation consente la gestione di più cluster in modo agnostico per il backend. È possibile sfruttarlo su cluster bare metal, ovvero macchine fisiche, cluster virtuali sopra OpenStack o sopra cloud commerciali, ovvero macchine virtuali senza peraltro perdere in performance, attraverso un unico set di API presenti in un cluster denominato cluster host.

Marco Lorini e Matteo Di Fazio, insieme ai colleghi GARR del dipartimento CSD in occasione di Hack the Cloud 2019 all’Università di Milano-Bicocca

In particolare, la federazione di test UltraHA Kubernetes, realizzata in GARR, è composta da quattro cluster, uno definito come cluster host, esso stesso in HA, che ha il compito di gestire l’intera federazione, e tre cluster member, distribuiti sulle varie regioni della GARR Cloud, che hanno il compito di implementare ed eseguire le risorse federate come applicazioni e servizi.

Come previsto dal meccanismo di federazione Kubernetes, sul cluster host risiede il Control Plane che rappresenta la componente principale della federazione e che si occupa di federare i cluster member e di propagare su di essi le risorse che si intende federare. In questo modo si è riusciti a distribuire geograficamente, e quindi ad implementare, un sistema ad alta affidabilità di un’applicazione, federandola sulle diverse regioni della GARR Cloud. Per l’esposizione dell’applicazione verso l’esterno, si è voluto realizzare un sistema di gestione automatizzata del DNS, sfruttando la componente ExternalDNS, che si integra perfettamente con il concetto di federazione.

Grazie agli strumenti che KubeFed fornisce (Multi-Cluster Ingress DNS), è possibile rilevare tutti gli indirizzamenti IP con cui l’applicazione federata viene esposta e, tramite ExternalDNS, propagarli ad un DNS Provider per la creazione e l’aggiornamento di record DNS senza che l’utente finale si accorga di qualcosa.