© alphaspirit / 123RF.com

Welche Erfahrungen machen Kubernetes-Anwender beim Einführen dieser Technik? Was können sie auf der Habenseite verbuchen, welche Stolperstellen waren zu umgehen? Das Linux-Magazin hat sich bei Unternehmen und Behörden umgehört, die erfolgreich auf Kubernetes umgestellt haben.

Was kann man mit Kubernetes erreichen, was ist vielleicht Illusion? Welche Fehler lassen sich beim Einführen der Technologie vermeiden? Wie viel Zeit und Ressourcen gilt es einzuplanen, und welche Veränderungen neben der technischen Umstellung sind in Angriff zu nehmen? Fragen, die sich beantworten lassen, wenn man sich an den Erfahrungen von Anwendern orientiert, die den Weg zu einer Container-basierten Architektur ihrer IT bereits erfolgreich beschritten haben. Das Linux-Magazin hat verschiedene Unternehmen und Behörden dazu befragt.

Agiler Autobauer

Je schneller sich neue Ideen in konkreten Produkten niederschlagen, desto besser die Aussicht auf einen Geschäftserfolg. Neudeutsch spricht man von der Time to Market, die es zu verkürzen gilt. Auch und gerade in der Autoindustrie sichert das schnelle Entwickeln und Bereitstellen von Anwendungen die Wettbewerbsfähigkeit. Eine technische Voraussetzung dafür schaffen Containerisierung und Cloud Computing, die sich vielerorts durchsetzen und die man allgemein als Treiber für IT-Innovationen sieht.

Auch Porsche Informatik [1] ist diesen Weg gegangen. Das Unternehmen liefert IT-Services für die Porsche Holding Salzburg und den Volkswagen-Konzern. Millionen von Nutzern in Autohäusern, Werkstätten, bei Importeuren, Logistikunternehmen, Finanzdienstleistern sowie Endanwender im Internet nutzen die Systeme von Porsche Informatik. Die Organisation liefert und verwaltet 180 Lösungen in 32 Ländern auf vier Kontinenten. Dazu beschäftigt Porsche Informatik mehr als 800 Spezialisten, die Lösungen für die weitere digitale Transformation des Automobilhandels entwickeln und bereitstellen.

Dabei geht es etwa um Business-Software für Vertragshändler, After Sales Service, Ersatzteilevertrieb oder Finanzdienstleistungen. Ein konkretes Beispiel ist der Car Configurator, mit dem sich der Neuwageninteressent im Internet in wenigen Schritten sein Wunschfahrzeug zusammenstellen kann. Sowohl die Bilder des Fahrzeugs als auch die Preiskalkulation werden mit jeder gewählten Ausstattung – Lackierung, Innenbezüge, Felgen und so weiter – immer sofort angepasst. Ist das Wunschauto fertig konfiguriert, lässt es sich noch um Kredit-, Leasing- und Versicherungsangebote ergänzen. Der Car Configurator ist auf den Internet-Seiten der Volkswagen-Konzernmarken und der Autohäuser integriert.

Ein weiteres Beispiel für die Lösungen, die Porsche Informatik verantwortet, bietet das Gebrauchtwagenportal “Das WeltAuto” [2], das via Internet ein breites Angebot geprüfter, gewarteter und reparierter Gebrauchtwagen bereitstellt. Teilnehmende Händler, aber auch Privatverkäufer präsentieren hier online ihre gebrauchten Fahrzeuge.

Die Basis der Anwendungsinfrastruktur für die Lösungen und Services der Porsche Informatik bildet die Enterprise-Kubernetes-Plattform Red Hat OpenShift [3], die das Unternehmen in einer Private-Cloud-Umgebung betreibt. Durch die Migration der ehemaligen Legacy-Infrastruktur auf die Container-basierte, Cloud-native Plattform konnte Porsche Informatik die Entwicklungszeiten von Wochen auf Stunden reduzieren. Im Durchschnitt lassen sich Anwendungen und Services in rund 90 Prozent kürzerer Zeit erstellen, testen und bereitstellen als in der Vergangenheit. Ein erster Prototyp ist mit Red Hat OpenShift bereits innerhalb von Stunden verfügbar.

“Kubernetes ist eindeutig der De-facto-Standard für die Entwicklung von Linux-Containern. Eine Kubernetes-Infrastruktur selbst aufzubauen, ist aber unserer Meinung nach kein sinnvoller Weg, wenn auch kommerzielle Produkte und Standardlösungen wie Red Hat OpenShift zur Verfügung stehen, die bereits viele wichtige Leistungsmerkmale wie Autorisierung, Authentifizierung, Logging oder Metriken beinhalten. Eines sollte aber auch klar sein: Ohne jegliches Kubernetes-Know-how auf Infrastruktur- und Entwicklungsseite geht es auch nicht”, erklärt Michael Karnutsch, Infrastructure Architect bei Porsche Informatik.

Basierend auf Kubernetes, dem Standardprodukt zur Container-Orchestrierung, bietet Red Hat OpenShift eine stabile Container-Plattformumgebung für Anwendungen und unterstützt die Entwicklungsteams beim Betrieb ihrer CI/CD-Pipeline. Konkret können Nutzer mit Red Hat OpenShift Container-basierte Applikationen konzipieren, automatisieren, skalieren und verwalten. Die Enterprise-Kubernetes-Plattform enthält alle erforderlichen Funktionen und Services, um eine Container-Managementlösung für unternehmenskritische Anwendungen auf unterschiedlichen Infrastrukturen zertifiziert zu betreiben. Dazu gehören etwa Aspekte wie SLAs, mehrere Sicherheitsebenen, die Automatisierung oder das Cluster-Management.

Red Hat OpenShift fungiert bei Porsche Informatik als Runtime-Umgebung. Die Plattform hostet derzeit Entwicklungsprozesse in 11 Clustern mit Tausenden von Containern auf weit mehr als 100 Knoten und wird regelmäßig von rund 500 Entwicklern verwendet. Die Cluster teilen sich dabei thematisch in Test- und Produktivumgebungen auf. Die Infrastruktur bietet die Möglichkeit, einen neuen Cluster innerhalb weniger Stunden bereitzustellen.

Administratoren können mithilfe der einheitlichen Managementkonsole von Red Hat OpenShift Sicherheits- und andere Richtlinien einfach Team- und Cluster-übergreifend implementieren und durchsetzen. Darüber hinaus nutzt Porsche Informatik das Red Hat Advanced Cluster Management for Kubernetes sowie Argo CD für die Infrastrukturverwaltung. Das stellt sicher, dass die Lösungen von Red Hat immer auf dem neuesten Stand bleiben, vor Schwachstellen geschützt sind und diverse Standards einhalten.

Einer der zentralen Vorteile der neuen Container-basierten, Cloud-nativen Umgebung liegt in den Self-Service-Funktionen für die Entwicklerteams von Porsche Informatik. Sie können jetzt unabhängig vom Infrastrukturteam des Unternehmens Services und Infrastruktur provisionieren. Der Anforderungsprozess für Ressourcen ist dabei denkbar einfach und vor allem schnell. In der Vergangenheit war etwa die Bereitstellung eines Apache Tomcat sehr aufwendig, von der Anforderung des Webservers über das Ausrollen einer VM und die Einbindung in die Netzwerkinfrastruktur bis hin zum Einrichten der Zertifikate.

Aus technischer Sicht zeigt sich der Nutzen der neuen Infrastruktur auch in den größeren Freiräumen für die Entwicklerteams. Sie können neue Technologien grundsätzlich leichter einführen und betreiben oder völlig eigenständig Applikationen aufsetzen, ohne die darunter liegende Infrastruktur beachten zu müssen. Beispiele dafür wären Node.js oder ein Datenbankmanagementsystem wie MongoDB, um etwaige neue Anwendungsfälle abzudecken.

Vor allem im Hinblick auf die Sicherheit nutzt Porsche Informatik ergänzende Lösungen zur Laufzeitumgebung. Das betrifft etwa die Anmeldeverfahren, das Container Image Scanning oder auch CI und CD. In den Build- und Deployment-Umgebungen werden in der Entwicklung Jenkins, eine Gitlab-Umgebung und im Infrastrukturbereich Argo CD eingesetzt.

Dank der Einführung eines agilen, kollaborativen DevOps-Ansatzes, der von Red Hat OpenShift unterstützt wird, können Entwickler, Architekten, Infrastrukturexperten und Plattformteams bei Porsche Informatik wesentlich effektiver bei der Konzeption und Aktualisierung innovativer Anwendungen und Services zusammenarbeiten. Auf diese Weise werden redundante Arbeiten vermieden.

Allerdings erfordern die Nutzung einer Enterprise-Kubernetes-Plattform und die Einführung agiler, iterative Prozesse auch einen kulturellen Wandel im Unternehmen. Dieser Aspekt betrifft vor allem Operations und weniger die Entwicklung, die bereits eher mit DevOps-Prozessen vertraut ist. Auf Operationsseite ist ein neues Mindset mit einer Aufhebung der klassischen Trennung etwa von Linux-, Netzwerk- oder Storage-Teams notwendig, wenn auch der Betrieb einem As-Code-Ansatz folgt.

Der Einstieg in die Kubernetes-Welt ist zwar kein Hexenwerk, Unternehmen sollten aber doch einiges beachten. Aus Sicht und den Erfahrungswerten von Porsche Informatik erscheinen dabei folgende Best Practices hilfreich:

• Das Ausprobieren und intensive Testen einer Kubernetes-Umgebung sollte an erster Stelle stehen.
• Auf jeden Fall ist die Nutzung einer Standard-Plattform empfehlenswert, sie nimmt einem Unternehmen viel Arbeit ab.
• Prinzipiell sollte ein Nutzer immer am Kubernetes-Standard festhalten.
• Eine Registry- und Basis-Image-Struktur muss aufgebaut und für die Entwickler bereitgestellt werden.
• Neue Entwickler sollten eine Starthilfe erhalten, vor allem in Form einer Dokumentation mit einer detaillierten Prozessbeschreibung etwa für das Deployment von Applikationen.

Das Ergebnis eines solchen Verfahrens ist eine Infrastruktur, die sich gut skalieren, warten sowie patchen lässt und das Unternehmen zukunftssicher für künftige Herausforderungen aufstellt.

Die Entwicklung bei Porsche Informatik bleibt nicht stehen. Mittelfristig soll Red Hat OpenShift in einer Public Cloud eingesetzt werden. Das Ziel von Porsche Informatik ist die Bereitstellung aller Anwendungen für Mitarbeiter und Endbenutzer in allen Ländern über Microsoft Azure Red Hat OpenShift. Auch Managed Services von Microsoft sollen so für Entwickler künftig “as code” aus einer Pipeline heraus nutzbar sein.

Agilere Behörde

Um mehr Agilität ging es auch in einer großen deutschen Bundesbehörde. Zwar setzte man bei der Neuentwicklung von Software schon seit rund drei Jahren auf agile Verfahren, für ältere Software im Kernbestand (J2EE-Anwendungen, SOA-Services, Oracle Fusion Middleware) galt aber noch das Wasserfallmodell: Eine Entwicklungsabteilung aktualisierte ungefähr drei Mal pro Jahr die Programme, die andere Geschäftsbereiche dann betrieben. Neue Software, die nach dem DevSecOps-Ansatz entsteht und vom selben Team auch betrieben wird, arbeitet dagegen bereits mit 14-tägigen Zyklen.

Schon vor Kubernetes hatte man mit Virtualisierung und Containern zu tun und nutzte dafür Apache Mesos, das alle Ressourcen eines Rechenzentrums oder einer Cloud zentral und plattformunabhängig verwaltet und auch Docker-Container nativ unterstützt. Allerdings wurde es immer schwieriger, Mitarbeiter mit Mesos-Know-how zu finden. Als dann auch noch der bisher eingesetzte Container-Orchestrator DC/OS abgekündigt wurde, entschloss man sich zu einem Wechsel zum marktführenden Kubernetes.

Dabei waren eine Reihe von Schwierigkeiten zu meistern, etwa die schnelle Migration aller alten DC/OS-Verfahren mitsamt ihrer Daten in die Kubernetes-Welt oder die Einführung eines Service-Mesh (Istio [4]), das es zuvor nicht gab. Auch die Fehlersuche über mehrere Virtualisierungsschichten hinweg erwies sich als sehr komplex. Obendrein galt es, die strengen Compliance-Vorgaben des öffentlichen Diensts einzuhalten. Die Bereitschaft, sich auf Neues einzustellen und Althergebrachtem den Rücken zu kehren, war dabei nicht in allen Abteilungen gleich gut ausgeprägt.

Am Ende stehen aber vorzeigbare Errungenschaften auf der Habenseite: Man hat für die nächsten Jahre eine topaktuelle und innovative Technologie etabliert, die sich ständig weiterentwickelt. Sie bildet die Grundlage für die Entwicklung agiler Software, die sich im Container-Format zudem leicht in hybride Clouds portieren lässt. Auch das klassische Operating profitiert vom sehr hohen Automatisierungsgrad, der viele manuelle Arbeitsschritte überflüssig macht. Außerdem ist es nun leichter, neue Mitarbeiter zu rekrutieren.

Als besonders wichtig auf dem Weg hin zu Kubernetes erwiesen sich gut eingespielte Teams, die sich regelmäßig und vertrauensvoll austauschen und gemeinsame Werte pflegen, beispielsweise eine offene Fehlerkultur. Technisch machte man gute Erfahrungen mit mehreren kleineren Clustern anstelle eines einzigen sehr großen, mit dem Einsatz einer speziell zugeschnittenen Kubernetes-Distribution – in diesem Fall stammt sie von Suse – und mit der konsequenten Ausrichtung an der Devise “Infrastructure as Code”, die für Nachvollziehbarkeit und Wiederholbarkeit sorgt.

Agile Medien

Nicht nur in der Industrie oder bei Behörden ist Kubernetes ein Thema, auch in den Medien – so etwa beim führenden spanischen Medienhaus Atresmedia [5], das Radio, Fernsehen und Streaming-Dienste unter einem Dach versammelt. Dort erkannte man, das sich die Erwartungen heutiger Medienkonsumenten nur schlecht mit alten, monolithischen Applikationen bedienen lassen. Außerdem stiegen die Kosten der Softwarewartung, beispielsweise für das Content Management System, in schwindelerregende Höhen. Zugleich war die Umgebung langsam und nur begrenzt skalierbar. Skalierbarkeit war jedoch ein sehr wichtiges Kriterium, wenn beispielsweise im Zuge der Wahlberichterstattung für kurze Zeit extreme Datenmengen anfielen.

Deshalb entschloss man sich, mit der alten Architektur zu brechen und einen neuen Ansatz auf Basis von Microservices anzustreben. Die Grundlage sollte das Produkt Charmed Kubernetes [6] von Canonical sein, das bereits einen hohen Grad an Automation und Skalierbarkeit mitbringt. Den Hersteller kannte man bereits, weil man schon lange beim En- und Transcoding von Videos auf Ubuntu setzte. Durch die Containerisierung versprachen die Microservices die Flexibilität, Ausfallsicherheit und einfache Verwaltung, die Atresmedia suchte. Von allen Microservice-orientierten Projekten, die das Unternehmen testete, schnitt Kubernetes am besten ab und bot den zusätzlichen Vorteil einer großen Community.

Durch den Einsatz von Juju, dem Operator-Lifecycle-Management-Tool für Charmed, half Canonical Atresmedia, die Bereitstellung, den Betrieb und die Skalierung des neuen Charmed-Kubernetes-Clusters zu automatisieren. Das hatte eine nahtlose Implementierung und drastische Vereinfachung des laufenden Anwendungsmanagements zur Folge. Darüber hinaus erleichterte Juju Atresmedia die Bereitstellung Cloud-nativer Anwendungen sowohl vor Ort als auch in der Cloud – eine wichtige Anforderung angesichts der Hybrid- und Multi-Cloud-Strategie des Unternehmens.

Anfangs verließ sich Atresmedia für den täglichen Betrieb auf den Support von Canonical. Doch seit der Implementierung hat das hauseigene IT-Team Fachwissen aufgebaut und pflegt nun den Cluster eigenständig. Canonical steht weiterhin zur Verfügung, um alle größeren Probleme zu lösen, aber in vier Jahren gab es noch keinen einzigen nennenswerten Vorfall. Óscar Martínez, Leiter der Architektur und Backend-Entwicklung bei Atresmedia, kommentiert: “Wir streben immer nach Autonomie. Daher war es gut zu wissen, dass wir nicht an einen Beratungsdienst gebunden sind. Und jetzt, wo wir das interne Wissen haben, ist Juju von unschätzbarem Wert. Es hat uns ermöglicht, sehr flexibel zu agieren, wenn wir den Cluster weiterentwickeln oder modifizieren müssen.”

Mit der neuen Lösung auf Kubernetes-Grundlage gehören Skalierungsprobleme der Vergangenheit an. Sobald der Streaming-Dienst ATRESplayer erhöhten Traffic verzeichnet, skaliert das System seine Ressourcen automatisch hoch, um dem Verkehr gewachsen zu sein. Seine Feuertaufe bestand es während der Präsidentschaftswahl 2019, wo es Hunderttausenden Spaniern aktuellste Wahlergebnisse in Echtzeit präsentierte. “Wären wir nicht in der Lage gewesen, den Datenverkehr zu bewältigen und aktuelle Daten zu liefern, wäre das ein schwerer Schlag für unsere Wettbewerbsfähigkeit gewesen”, sagt Miguel Rodríguez. “Aber Charmed Kubernetes hat unsere Erwartungen erfüllt. Die Skalierung funktionierte problemlos.” (jlu)