In den meisten Fällen ist vom Einsatz von Kubernetes abzuraten, da die Komplexität der Infrastruktur unnötig erhöht wird. Stärken spielt Kubernetes aus, sobald ein einheitliches Schema für das Deployment von Anwendungen genutzt werden kann.

Im Jahr 2014 veröffentlichte Google die erste Version von Kubernetes auf GitHub. Bereits damals zeichnete sich ab, dass die Software nicht nur exklusiv für Google und einige, hoch-spezialisierte Technologie-Unternehmen relevant sein würde. Andere Global Player wie Microsoft, RedHat, IBM und Huawei traten der Kubernetes-Community in 2014 bzw. 2015 bei.

In den folgenden Jahren tauchten mehr und mehr Software-Produkte auf, die auf Basis von Kubernetes betrieben worden sind. Besonders hervorzuheben ist die Case Study zu Pokémon GO aus dem Jahr 2016. Der massive Bedarf an Rechenleistung für Pokémon GO konnte nur befriedigt werden, da Kubernetes die benötigten Ressourcen dafür skalieren konnte.

Mittlerweile ist Kubernetes nicht länger nur ein Hype-Thema. Auch in produktiven Umgebungen abseits der klassischen Software-Entwicklungsunternehmen ist die Plattform angekommen. Durch die Transformierung der Geschäftsmodelle im Mittelstand hin zu digitalen Produkten und Dienstleistungen wird durch IT-Dienstleister zunehmends Kubernetes als Betriebsplattform angeboten.

CTOs und CIOs stehen nun gemeinsam vor den Fragen

  • in wie weit Kubernetes überhaupt notwendig ist,
  • wie Kubernetes zu der strategischen (IT-)Ausrichtung ihres Unternehmens passen
  • und welche Änderungen und Kosten auf sie zu kommen.

Was kann auf der Kubernetes-Plattform laufen?

Theoretisch können alle Anwendungen in Kubernetes laufen, die auch innerhalb eines Docker-Containers laufen können. Klassischerweise sind dies Web- oder Netzwerk-Anwendungen auf Basis von Linux. Dies beginnt bei der web-basierten Arbeitszeiterfassung und endet bei einem Datenbankmanagementsystem. Durch die Open Source-Initiative von Microsoft ist damit jedoch nicht Schluss. Mittlerweile können auch spezifische .NET-Anwendungen und der Microsoft SQL-Server in einem Docker-Container, und damit auch in Kubernetes, betrieben werden.

Klassische Windows-Anwendungen können nicht innerhalb von Kubernetes laufen. Software wie z. B. Lexware, aber auch Steuerungssoftware für die Telefonanlagen oder Schlösser, greifen oft auf native Funktionen des Windows-Betriebssystems zurück.

Kubernetes für interne Software-Produkte

In den allermeisten Fällen ist vom Einsatz von Kubernetes für die interne IT und Software-Lösungen abzuraten. Bei der Entscheidung für oder gegen den Einsatz können die folgenden Fragen helfen:

  • Ist genug Zeit vorhanden, sich mit Kubernetes zu beschäftigen?

    Sowohl konzeptuell als auch technisch nimmt die Komplexität der IT-Landschaft zu. Die Administratoren müssen sich ausgiebig mit den Auswirkungen und notwendigen Änderungen beschäftigen.

  • Sollen Datenbankmanagementsysteme in Kubernetes betrieben werden?

    Theoretisch können MySQL, Microsoft SQL Server, PostgreSQL und Oracle in Kubernetes betrieben werden. Gründe gegen den Betrieb in Kubernetes sind unter anderem:

    • Speicherintensive und performance-kritische SQL-Abfragen benötigen durch zunehmende Komplexität unter Umständen deutlich länger.
    • Die Datensicherung der unterliegenden Dateien kann komplexer oder nicht mehr in die zentralen Backup-Mechanismen integriert werden.
    • Ggf. entstehen durch die geänderte oder virtualisierte Hardware neue Lizenzkosten. Dies betrifft vor allem Oracle.

  • Existieren viele Anwendungen, die als Container laufen können?

    Ohne eine große Anzahl von containerisierbaren Anwendungen ergibt eine Kubernetes-Lösung wenig Sinn. Der Aufwand für Betrieb und die Umstellung der bisherigen Update- und Upgrade-Prozesse rentiert sich in den meisten Fällen nicht.

  • Welche Anwendungen müssen weiterhin auf physikalischer oder virtualisierter Hardware laufen?

    Anwendungen wie z. B. Exchange Server oder SharePoint, sowie Windows Serverrollen wie Active Directory oder Zertifikatsdienste müssen weiterhin auf den bestehenden Systemen außerhalb des Kubernetes-Cluster laufen.

  • Ist ggf. Wissen im Bereich der Software-Entwicklung vorhanden?

    Kubernetes stellt eine API bereit, mit der Arbeitsabläufe automatisiert werden können.

Anhand der genannten Fragen lässt sich bereits ableiten, dass klassische Infrastrukturdienste (Domänenbetrieb, Mail, Storage und Datenbanken) nicht in Kubernetes laufen können oder sollten. Bei den Geschäftsanwendungen ist abzuwägen, ob der Aufwand dem Nutzen gerecht wird.

Kubernetes für den Betrieb von Web-Plattformen

Seine Stärken spielt Kubernetes im Bereich der Web-Anwendungen aus. Administrative Infrastrukturaufgaben, wie z. B. die Einrichtung von kostenlosen X.509-Zertifikaten über Let’s Encrypt oder Amazon Certificate Manager für die verschlüsselte Übertragung per HTTPS, können sehr schnell realisiert werden. Weiterhin lassen sich beispielsweise Anforderungen an die Verschlüsselung über alle Applikationen direkt umsetzen. Dies ist besonders interessant, wenn durch eine notwendige Zertifizierung wie TISAX die Verschlüsselung von TLS 1.2-only gefordert wird, der Hoster aber zusätzlich noch TLS 1.0 und 1.1 anbietet.

Besonders bei größeren oder sich ändernden Lasten kann Kubernetes durch die Autoskalierung auf die ändernde Anzahl reagieren: Durch passende Maßnahmen können innerhalb kurzer Zeit mehr Ressourcen für die Verarbeitung der Anfragen bereitgestellt werden.

Oberhalb der Infrastrukturschicht ergibt der Einsatz von Kubernetes erst Sinn, wenn die Web-Anwendung kontinuierlich weiterentwickelt und öfter veröffentlicht wird.

Einfache Web-Anwendung

Bei einer einfachen Web-Anwendung (statische Website und/oder PWA) mit einigen hundert Seitenaufrufen pro Sekunde ist der Bedarf für ein Kubernetes-Cluster so gut wie nicht gegeben. Jeder große deutsche Web-Hoster stellt dafür die nötigen Ressourcen bereit.

!! Der Einsatz von Kubernetes ist für einfache Web-Anwendungen oder PHP-Scripte in den meisten Fällen unnötig.

Portale

Für Portale wie Online-Shops oder Foren mit hohem Traffic und einer relativ langen Verarbeitungszeit durch die zugrunde liegende Programmiersprache (z. B. PHP bei WooCommerce oder Magento) kann der Einsatz von Kubernetes interessant sein. Zu Zeiten mit hoher Last, wenn z. B. Marketingaktionen im Fernsehen geschaltet werden, können die Anfragen auf mehr Ressourcen verteilt werden. Hier ist allerdings immer zu evaluieren, ob eine Autoskalierung über den unterliegen Cloud-Provider einfacher zu realisieren ist: Die Komplexität der Infrastruktur durch Kubernetes steigt stark an.

Mindestens die folgenden Fragen sollten bei der Evaluierung von Kubernetes beantwortet werden:

  • Können Assets wie Bilder und andere Dateien zentral von der Anwendung gespeichert und angesprochen werden?
  • Kann die Anwendung mit verteilten Sessions umgehen oder wird eine so genannte Session-Stickyness benötigt?
  • Existiert bereits ein Entwicklungsablauf, der ein kontinuierliches Bauen und Ausrollen der Anwendung ermöglicht?

!!! Die Entscheidung für oder gegen Kubernetes bei einer Web-Portal erfolgt in aller Regel nach Analyse der bestehenden Anwendung und des existierenden Software-Entwicklungsprozesses.

SaaS

Es gibt drei grundlegende architekturelle Konzepte, wie eine SaaS-Software implementiert ist:

  • Multi-Instance
  • Multi-Host
  • Multi-Tenant

Multi-Instance bedeutet, dass für jeden Kunden ein eigener virtueller oder physikalischer Server eingerichtet ist. Der Vorteil dieser Lösung besteht darin, dass die Daten physikalisch bzw. logisch voneinander getrennt sind.

Multi-Host meint hingegen, dass auf dem selben physikalischen oder virtualisierten Server die Applikation in unterschiedlichen Verzeichnissen existiert. Die Kunden teilen sich somit die Ressourcen.

Bei Multi-Instance und Multi-Host steigt der Zeitbedarf für den Rollout von neuen Versionen ohne passenden CI/CD-Workflow linear mit Anzahl der Kunden an. Auf jedem Host muss die selbe Version ausgerollt werden.

Multi-Tenant bezeichnet eine Anwendung, die bereits von sich aus mehrere Kunden oder Mandanten verwalten kann. Effektiv kann die Software einmal installiert und für mehrere Kunden bereitgestellt werden. Vorteil dieser Herangehensweise ist, dass die Software theoretisch weniger Ressourcen benötigt, in ihrer Komplexität aber deutlich steigt.

!!!! Je nach Implementierung der SaaS-Lösung sind die selben Analysen wie bei einem Web-Portal durchzuführen. Spätestens bei der Verwaltung von mehreren Kunden (Multi-Instance, Multi-Host) wird der organisatorische Overhead drastisch reduziert. Für Multi-Tenant-Anwendungen spielt Kubernetes seinen Vorteil bei der Autoskalierung aus.

Fazit

Ob Kubernetes eingesetzt werden sollte oder nicht, ist individuell zu betrachten. Kubernetes ist definitiv nicht das Allheilmittel für bestehende IT-Probleme: In den meisten Fällen wird die Komplexität der bestehenden IT-Landschaft unnötig erhöht.