Der Datenverkehr von Benutzern die sich auf Hotspot-Systemen einloggen wird via VPN in diesen Kubernetes Cluster gerouted. Die üblichen öffentlichen Cloudanbieter verlangen hohe Preise für ausgehenden Traffic, monatliche Kosten hätten sich anhand des üblichen Aufkommens berechnet auf über 15000€ belaufen. Der Cluster wird deshalb on-premises und auf bare-metal betrieben.

Eine Herausforderung des Projektes war die netzwerktechnische Kopplung zwischen dem Kubernetes Cluster und dem Rest des Datacenters. Dabei wurde jeder Node via BGP an den top-of-rack-Router gebunden um zu ermöglichen, dass jedes Service eine öffentliche IP erhalten kann um 100%ige Kontrolle über die Quelle ausgehenden Datenverkehrs zu halten.

Ein Hauptaugenmerk des Projektes war die Installation des Clusters so weit zu automatisieren, dass weitere physikalische Server/Kubernetes-Nodes ohne Aufwand hinzugefügt und in das Netzwerk integriert werden können.

Die Unwired Cloud umfasst diverse Services die gemeinsam den korrekten Betrieb von netzwerktechnischen Geräten im Feld sichern oder auch selbst verkauften Produkte darstellen.

Als Hauptansprechpartner für Infrastrukturthemen bin ich verantwortlich für das Design und den Betrieb eines Systems das sowohl auf Google Compute Engine als auch selbst verwalteten Linux-Servern vor Ort in Wien verteilt läuft und den Betrieb dieser Services ermöglicht. Dabei geht es um die Automatisierung der Installation der Plattform und der darauf laufenden Komponenten, Erhebung und Auswertung von Metriken und Logs ebendieser, sichere Kommunikation zwischen Cloud und on-premises Services und Automatisierung der unterstützenden Komponenten(DNS, HTTP-Ingress, SSL-Zertifikate,…).

Abgesehen von direkt am Produkt beteiligten Komponenten gilt es den restlichen Entwicklern eine Plattform bereitzustellen die via CI/CD, selbst gemanagten Alerts und Anbindung an GitHub einen reibungslosen und effizienten Arbeitsablauf ermöglicht. Diverse interne Services betreffend Backup, Cluster Management und anderen Infrastrukturthemen wurden selbst in Golang entwickelt.

Das Service ermöglicht Zugriff auf Netzwerkgeräte(Router, Access Points, …) im Feld unabhängig von deren aktueller Position, externer IP usw. da sich diese Geräte großteils über dynamische Mobilfunknetzwerke verbunden sind und auf Zügen, Gondeln in Skigebieten o.Ä. unterwegs sind. Dabei muss der User nur via SSH dem Service die eindeutig das Gerät identifizierende MAC-Adresse bereitstellen und sich korrekt authentifizieren um Kommandozeilenzugriff auf das Gerät zu erhalten. Die API des Services wurde für automatisierten Zugriff designed und im Zuge der Implementierung auch eine Client-Library bereitgestellt die für automatisierte remote-Upgrades von Geräten verwendet wird. Ebenfalls wird Abruf von Telemetriedaten/Metriken über dieses Service gelöst.

Als technische Notwendigkeit für Produkte und interne Services wurde eine Golang-Anbindung an das management interface von OpenVPN entwickelt. Dabei regelt ein „neben“ dem OpenVPN-Server laufendes Service die Kommunikation mit dem single-threaded management interface und stellt alle OpenVPN-Kommandos(Abrufen und Freigeben von Sessions, usw.) über eine REST- oder GRPC-API anstatt telnet bereit. Damit ist es reibungslos und thread-safe ermöglicht moderne Applikationen die auch dem heutigen Sicherheitsstandard entsprechen basierend auf OpenVPN zu entwickeln.

Gemeinsam mit dem Service wird eine Client-Library bereitgestellt die Entwickler ohne Vorkenntnisse einbinden können. Die Library wurde in mehreren Projekten verwendet von mir und/oder anderen Entwicklern verwendet.

Im Team wurde ein Framework entwickelt das es ermöglichte Kubernetes Cluster in einer plattformunabhängigen Art zu erstellen und verwalten. Das Ziel war es anderen Teams in unserer Organisation innerhalb von Cisco zu ermöglichen ihre eigene Infrastruktur zu verwalten und pro Projekt zu entscheiden ob public oder private Cloud-Umgebungen verwendet werden sollen, jedoch ohne plattformspezifische Einbußen oder zusätzlichen  Verwaltungsaufwand in Kauf nehmen zu müssen. Jeder mit dem Framework erstellter Cluster war mit dem gleichen Set an unterstützenden Services betreffend Logging, Monitoring, Alerting, automatischem DNS, Ingresslösungen usw. ausgestattet.

Die initiale Version wurde in einer Kombination aus Python und Ansible und Terraform implementiert, zusätzlich wurden Terraform-Anbindungen an Cisco-interne Komponenten wie DNS-Services in Golang entwickelt. Als unterliegende Plattformen wurde unser selbst gemanagter VMware-vSphere Cluster, eine Cisco-interne OpenStack-Umgebung und AWS unterstützt. Um gleichwertige Integration auf allen Plattformen zu erreichen wurden einzelne Kubernetes-Erweiterungen wie Unterstützung für automatisierte Snapshots auf OpenStack und VMware als Kubernetes Operators realisiert.

Abgesehen von diesem Framework war unser Team dafür verantwortlich die Softwareentwicklungsteams unserer Organisation bei der Entwicklung von cloud-native Software zu unterstützen und laufend ihre Anforderungen an die von uns bereitgestellte Plattform zu erheben.   

Die Neuentwicklung einer Continuous Integration + Continuous Delivery-Plattform für unser internes Softwareentwicklungs-Team. Die Plattform umfasste den Weg des Codes von der Maschine des Entwicklers über das Source Code Management und Build-System bis hin zu dem Betrieb der entwickelten Services auf einem internen bare-metal Kubernetes-Cluster. Dabei lag ein starkes Augenmerk auf Automatisierung und den reibungslosen Ablauf aus der Sicht der Entwickler um effizient und oft releasen zu können.

Es wurde eine Software-as-a-Service Plattform für ein Java-basiertes Content Management System entwickelt. Die Plattform lief auf Google Kubernetes Engine. Das Herzstück des Systems war ein in Golang geschriebenes Service welches es ermöglichte, Instanzen der CMS-Software während ihres kompletten Lebenszyklus zu managen indem es eine REST-API für Operationen wie Erstellen, Löschen, Upgraden dieser Instanzen bereitstellte und zusätzlich das Benutzermanagement übernahm. Usern wurde es über ein Web-Frontend ermöglicht eine Instanz des CMS zu kaufen, die dann automatisch unter einer eigenen Domain mit den korrekten Zugangsdaten verfügbar gemacht und ohne weiteres Zutun sofort vom User verwendet werden konnte.

Das Service erstellte und modifizierte alle notwendigen Kubernetes-Ressourcen für solche Instanzen und war essentiell ein Vorläufer des damals noch nicht vollständig etablierten Kubernetes Operator-Patterns.

Eine Anbindung von Kubernetes an das ZFS-Dateisystem. Das Projekt ermöglichte es ein auf ZFS basiertes Storagesystem via den in Kubernetes integrierten Ressourcen zu nutzen, direkt vergleichbar mit AWS EBS storage, GCP disks usw.

Die Anbindung wurde sowohl für die danach entstehende interne CI/CD-Plattform als auch das oben erwähnte SaaS-Projekt genutzt.