Scalitys Erfahrungen, Lehren und Wege mit Kubernetes: 2016 – 2021

Es ist erstaunlich, dass sich Scalitys erfahrungsreiche Kubernetes-Reise nun über fünf Jahre erstreckt. 2016 begannen unsere Kunden, Lösungen für die Integration von Daten, die vor Ort in RING gespeichert sind, mit öffentlichen Cloud-Diensten wie AWS anzufragen. Es wurde rasch deutlich, dass auch andere große Cloud-Dienste wie etwa Azure und Google von Interesse waren, um eine Bindung an eine bestimmte Cloud zu vermeiden. Im Laufe der Zeit kamen auch spezialisierte und regionale Cloud-Dienste hinzu, vorrangig in Europa, wo die Datensouveränität in der Cloud ein heißes Thema ist. Der zentrale Aspekt der Kundenanfragen war damals wie heute die Möglichkeit, Daten in den Rechenzentren des Unternehmens und in den von ihnen bevorzugten öffentlichen Clouds anzuzeigen und zu verwalten. Im Jahr 2017 haben wir die strategische Entscheidung getroffen, unser neues Produkt ZENKO als Multi-Cloud-Datenmanagement-Lösung auf den Markt zu bringen. In den letzten Jahren hat sich unsere ZENKO-Technologie zu einem zentralen Element für die Ermöglichung von Hybrid-Cloud Use Cases in unseren eigenen Speicherprodukten RING und ARTESCA sowie in Cloud-Services und Speicherangeboten von Drittanbietern entwickelt.

Was nun hat das mit unserer Entwicklung hin zu Kubernetes zu tun? Unser ursprüngliches Produkt RING wurde 2010 auf den Markt gebracht. Jahrelang haben wir auf traditionelle Methoden zur Bereitstellung von Linux-Softwarepaketen (etwa RPM) gesetzt und mit Frameworks wie SaltStack automatisiert. Im Laufe der Zeit stiegen der generelle Aufwand sowie die zeitliche Investition zur Unterhaltung dieser Art von Paketen drastisch an: neue Funktionen gingen mit Abhängigkeiten einher, veraltete Betriebssystem-Distributionen (etwa RHEL 6) und gelegentliche Konflikte mit von Kunden installierten Paketen auf denselben Servern sorgten für zusätzliche Herausforderungen.

Wichtige neue Funktionen in RING wurden im Laufe der Jahre rasch eingeführt, so dass wir begannen, die agile Entwicklung unter Verwendung neuer Umgebungen wie NodeJS zu übernehmen. Dies führte natürlich zu mehr Abhängigkeiten bei den traditionellen Softwarepaketierungs-Methoden. Wir beschlossen daher, einen entscheidenden Schritt nach vorn zu machen: wir setzten Container im Stil von Docker ein, um diese Paketierungsprobleme für neue Dienste in RING zu lösen. In den ersten Tagen experimentierten wir mit Container-Orchestrierungslösungen wie Docker Swarm und Mesosphere, aber letztendlich konzentrierten wir uns auf Kubernetes.

Ein weiterer wichtiger Vorteil von Kubernetes, den wir vorausgesehen haben, ist in den letzten zwei Jahren noch relevanter geworden: die Portabilität. ZENKO wurde ursprünglich mit dem Ziel der portablen Bereitstellung in lokalen und öffentlichen Clouds eingeführt. Dies war unser erster Vorstoß in "Cloud-native" Angebote, die im Wesentlichen auf physischer Hardware oder in der/den Cloud(s) laufen können. Zu Beginn der Jahre 2019 und 2020 stieg der Bedarf an Portabilität sogar noch weiter an, da wir eine neue Nachfrage speziell nach Edge-basierten Speicher-Implementierungen für eine neue Reihe von datenzentrierten Services an entfernten Standorten erlebten. Dies führte zum Bedarf einer völlig neuen Kategorie leichtgewichtiger Speicher.

Vor diesem Hintergrund wurde ZENKO als eine Reihe von Diensten entwickelt, die als Docker-Container auf Kubernetes bereitgestellt wurden. Wir erkannten, dass diese Art von Architektur wirklich die Zukunft der Software verkörpert, und wir setzten sie bei der Entwicklung neuer Produkte konkret ein. Die Vorteile dieses Ansatzes lagen in der Einfachheit der Paketierung sowie der Flexibilität bei der Bereitstellung, z. B. bei der Skalierung von Diensten, um größere Arbeitslasten zu bewältigen. Letztendlich steuerten wir auf eine neue Ära von Cloud-nativen Design- und Implementierungsprinzipien für alle unsere Produkte zu, indem wir containerisierte Dienste mit Bereitstellung auf Kubernetes einführten.

Anfang 2021 wurde unser neues Produkt ARTESCA als eine der weltweit ersten leichtgewichtigen, Cloud-nativen Objektspeicherlösungen angekündigt. Es wurde entwickelt, um Speicherfunktionalität und Speicherzuverlässigkeit auf Enterprise-Niveau zu bieten. ARTESCA selbst wurde auf einem vollständig cloud-nativen Software-Stack (containerisierte Dienste) entwickelt, der auf Kubernetes bereitgestellt und orchestriert wird.  Das Design von ARTESCA ermöglicht die Portabilität zwischen Kern-Rechenzentren, Cloud sowie Edge – je nach Bedarf, um Daten dort zu speichern und zu verwalten, wo sie erstellt und verbraucht werden.

Nach all diesen Jahren haben viele von uns in der Tech-Branche von Kubernetes gehört und verstehen seine Funktion und Rolle im Software-Ökosystem.  Letztendlich verwaltet und plant Kubernetes Container für die Ausführung auf physischen Servern, führt sie aber auf einer Container-Laufzeit-Engine wie Docker, containerd, cri-o (um nur einige zu nennen) aus. Insgesamt sind wir der Meinung, dass Kubernetes über eine solide und zuverlässige Architektur verfügt und eine hochwertige Implementierung darstellt. Wie bei jeder Software gibt es Unzulänglichkeiten und Probleme, die behoben werden müssen, aber Kubernetes hat eine wirklich starke Community-Unterstützung, mit der wir zusammenarbeiten, um Herausforderungen anzugehen, Probleme zu lösen, Code beizusteuern und es für unsere Bedürfnisse zu optimieren.

Mit einem Container-Orchestrierungssystem können wir die Automatisierung der Abläufe weiter erhöhen. Bis vor kurzem konzentrierten sich viele Produkte auf die Automatisierung der Installation und des Upgrades von Software-Versionen (was in einer verteilten Umgebung nicht trivial sein kann). Kubernetes (und, noch wichtiger, das Operator-Muster) ermöglichen es uns, Verfahren weiter zu kodifizieren, die in der Vergangenheit oft manuell dokumentiert waren, und nicht automatisiert erfolgten. Beispiele hierfür sind Rekonfiguration oder Fehlerbehebung.

Durch die Implementierung von Operatoren für alle unsere Software-Lösungen können wir auf einfache Weise die Bereitstellung, Aktualisierung sowie Neukonfiguration der Software automatisieren (und testen): alles im Einklang mit den Kubernetes-Standardpraktiken für Infrastructure-as-Code, sowie verschiedene Laufzeitereignisse erkennen und behandeln, z. B. wenn ein Clusterknoten unerreichbar wird.

Wir haben es uns zur Aufgabe gemacht, unternehmenstauglichen Speicher vor Ort bereitzustellen, und das haben wir mit zwei Produkten konkret umgesetzt: RING und ARTESCA. Wir wissen zwar, dass Kubernetes ursprünglich für Cloud-orientierte Bereitstellungen wie AWS oder Google entwickelt wurde, bei denen alle zugehörigen Ressourcen "als Service" zur Verfügung stehen, aber wir haben es jetzt auch gezielt für lokale Speicherbereitstellungen (On-Premises, Edge) eingesetzt. Wir befinden uns im Jahr 2021 immer noch an einem Punkt, an dem der "einfache" Kubernetes-Cluster für Entwicklerzwecke ausreicht, aber noch nicht ganz bereit ist für den Einsatz in der Produktion, und nur mit Mühe auf dieses Niveau gebracht werden kann.

Für den produktiven Einsatz benötigen wir Dinge wie Überwachungsfunktionen, Protokoll-Verwaltung, Benutzer-Authentifizierung und weitere Sicherheitsbelange, dazu Lastausgleich sowie eine Reihe an Diensten, die nicht zum Kern von Kubernetes gehören. Wir müssen abgekoppelte "Dark Site"-Umgebungen adressieren, und wir müssen uns in das kundenspezifische Netzwerk, die Benutzerverzeichnisdienste und vieles mehr integrieren – was von bestehenden Kubernetes-Distributionen oft nicht unterstützt wird.
Daher haben wir uns entschieden, MetalK8s als Open-Source-Projekt anzubieten – eine eigenständige Kubernetes-Distribution mit Fokus auf langfristigen On-Premises-Implementierungen. Auf unserem Weg in die Cloud-Native-Welt bietet MetalK8s eine solide Grundlage. Kommerzielle Kubernetes-Distributionen werden immer ausgereifter und bieten diese Funktionen, so dass wir die Unterstützung auch für On-Premises-Implementierungen ausweiten können. Dazu gehören neue Angebote wie VMware Tanzu, Redhat OpenShift, HPE Ezmeral und Rancher OS.

Wir sehen auch, dass die Anforderungen neuer "Cloud Native"-Anwendungen die Situation für die Datenspeicherung erheblich verändern, da diese Anwendungen bevorzugt API-basierten Zugriff auf Speicherdienste erhalten. Aus diesem Grund werden Objekt-APIs wie etwa AWS S3 weiter an Popularität gewinnen. Darüber hinaus gibt es Cloud-native Optionen, Speicherschnittstellen und Automatisierungen über Kubernetes bereitzustellen, einschließlich einer neu entstehenden Objektspeicher-Management-API namens COSI (Container Object Storage Interface), die voraussichtlich 2022 als implementierbare Spezifikation veröffentlicht wird.