Warum überhaupt Kubernetes?
Neben der Orchestrierung und dem Scheduling von Containern bietet Kubernetes einige essentielle Mechanismen. Dazu gehören unter anderem Load-Balancing, HTTP-basiertes Routing, Service-Discovery und verschiedene Deployment-Strategien. Zusätzlich bietet es eine Reihe nützlicher Ressourcen an, die für typische Enterprise-Anwendung nützlich sind. So gibt es Ressourcen für Konfigurationen, Secrets aber auch hilfreiche Abstraktionen für den Zugriff auf Datenspeicher. Viele dieser Funktionalitäten sind speziell für Microservice-basierte Architekturen gut geeignet.
Der wohl größte Vorteil von Kubernetes jedoch ist die Erweiterbarkeit durch eigene Ressourcentypen und dazugehörige Operatoren. Auf Basis vorhandener und neuer Ressourcentypen ist Kubernetes für viele Infrastrukturkomponenten damit zu einer Art Zielplattform geworden. So lässt sich z.B. eine verteilte Datenbank auf einfache Weise im Cluster betreiben, da mithilfe der Kubernetes-Abstraktionen sichergestellt werden kann, dass auf jedem Knoten eine Instanz der Datenbank läuft. Etwas, was bei eigens verwalteten Maschinen möglich, aber oft mit deutlich mehr Aufwand verbunden ist. Durch die von Kubernetes bereitgestellten Ressourcentypen, lässt sich die Datenbank somit auf beliebigen Kubernetes-Clustern installieren; egal ob im eigenen Rechenzentrum oder eben in der Cloud.
Das gilt natürlich nicht nur für Infrastrukturkomponenten. Auch die eigene Anwendung kann von diesen Mechanismen profitieren. Dank der einheitlichen Schnittstelle ist Kubernetes damit weitestgehend vendor-neutral und cloud-agonistisch und dementsprechend auch eine beliebte Wahl, um Anwendungen aller Art zu betreiben.
Das Problem an Kubernetes
Wenn Kubernetes so viel an Funktionalität anbietet und inzwischen quasi eine Art Standard für Infrastrukturkomponenten geworden ist, wieso fällt die Wahl nicht immer auf Kubernetes? – Es gibt durchaus auch Gründe, die gegen die Verwendung von Kubernetes sprechen.
Ein Grund ist die durchaus vorhandene Komplexität. Eine typische Kubernetes-Installation besteht aus einer Vielzahl von ineinander greifenden Komponenten, die es im produktiven Einsatz zu meistern gilt. Viele Cloud-Anbieter ermöglichen es, Kubernetes-Cluster in einer verwalteten Variante zu betreiben. So bietet Azure mit AKS, Amazon Web Services (AWS) mit EKS und Google mit GKE verwaltete Kubernetes-Cluster an. Selbst in der verwalteten Variante wird jedoch immer noch eine Menge Know-How benötigt, um einen Cluster betreiben zu können. Im Notfall ist die Fehlersuche mitunter erschwert, da die Cloud-Anbieter durchaus unterschiedliche Vorstellungen bei der Einrichtung eines Clusters haben.
Zusätzlich ist der Deployment-Prozess in der Praxis häufig aufwändiger als notwendig – die Schuld dafür liegt nicht zwangsläufig direkt bei Kubernetes. Oft werden jedoch Kenntnisse in weiteren Technologien wie etwa kustomize, Helm oder gar GitOps-Tools wie Flux oder Argo benötigt. Selten bleibt es bei einem einfach kubectl apply, um die Anwendung in den Cluster zu bringen. Auch wenn solche Indirektionen ihre Daseinsberechtigung haben, kommen sie oft zum Einsatz, selbst wenn die Komplexität damit in keinem Verhältnis zur bereitgestellten Anwendung steht.
Ab wann ist Kubernetes die richtige Wahl?
Kubernetes ist passend für viele Microservice-basierte Anwendungen. Gerade bei kleineren – möglicherweise monolithischen – Anwendungen wird jedoch ein Großteil der Funktionalität von Kubernetes nicht benötigt. Die Nachteile durch die erhöhte Komplexität sind dann meist zahlreicher als mögliche Vorteile. Gerade wenn die Anwendung gewissermaßen nur aus einem Service besteht, genügen oft die deutlich simpleren Compute-Angebote der Cloud-Anbieter. So reicht in Amazon Web Services (AWS) zu Beginn sicher eine Handvoll virtueller Maschinen auf EC2-Basis gepaart mit einem Load-Balancer. Falls Container zum Einsatz kommen sollen, stehen Services wie Fargate oder gar AppRunner bereit. Selbst wenn die Anwendung irgendwann erweitert wird und sich weitere Services dazu gesellen, bieten die Anbieter inzwischen Cloud-Services an, die ähnliche Funktionalitäten wie Kubernetes mitbringen. So muss etwa auf Service-Discovery aber auch auf erweiterte Mechanismen wie Service-Meshes nicht unbedingt verzichtet werden. Zwar wirken diese Cloud-Services im Vergleich zu ihrem Kubernetes-Pendant oft weniger mächtig, dafür fügen sie sich meist gut in das Ökosystem des Anbieters ein. Für kleinere bis mittelgroße Anwendungen reichen diese meist völlig aus. Erst wenn die Anzahl der Services stark wächst, geraten diese im Compute-Bereich angesiedelten Cloud-Services an ihre Grenzen.
Natürlich bleiben viele kleine Anwendungen nicht ewig klein und entwickeln sich häufig zu größeren Anwendungen. Ob sie sich jedoch so entwickeln, dass sie von den Kubernetes-Funktionalitäten profitieren können, ist nicht immer absehbar. Dennoch gibt es sicher einige Aspekte, die bereits bei kleinen Anwendung für die Verwendung von Kubernetes sprechen.
Ist absehbar, dass die Anwendung auf komplexere Infrastrukturkomponenten angewiesen ist, für die es keine dedizierte Unterstützung beim Cloud-Anbieter gibt, kann Kubernetes bereits sinnvoll sein. Zumindest dann, wenn besagte Infrastrukturkomponenten als Zielplattform offiziell Kubernetes unterstützen. So lässt sich der betriebliche Aufwand meist enorm reduzieren.
Auch wenn ein vermeintlicher Vendor-Lock-In vermieden werden soll und der Wechsel zu einem anderen Cloud-Anbieter prinzipiell auf einfachem Wege möglich sein soll, ist Kubernetes eine gute Wahl.
Warum nicht immer Kubernetes?
Wenn sich viele kleine Anwendungen oft in Richtung Microservices bewegen, warum sollte Kubernetes dann nicht von Beginn an zum Einsatz kommen? – Schließlich sind mit Kubernetes alle wichtigen Bausteine bereits vorhanden. Neue Services können so schnell in die Anwendung integriert werden. Auch ein großer Teil des benötigten Know-Hows wurde so bereits frühzeitig gesammelt. Eine Neuausrichtung auf Microservices kann so deutlich einfacher und schneller erfolgen.
Das gilt jedoch nur dann, wenn es auch wirklich dazu kommt. Selbst wenn sich die monolithische Anwendung zu einer verteilten Anwendung entwickelt, muss die Architektur noch längst nicht passgenau auf die Vorteile von Kubernetes zugeschnitten sein. Eine Event-getriebe Architektur etwa genießt im Kubernetes-Umfeld deutlich weniger Vorteile als es Services, die synchron via HTTP miteinander kommunizieren, tun. Wenn Kubernetes bereits frühzeitig in Stein gemeißelt wurde, wird dazu tendiert, die Kubernetes-Welt nicht mehr zu verlassen. Sollen Services etwa asynchron kommunizieren, fällt die Wahl oft auf Lösungen wie Kafka statt auf einfachere Messaging-Lösungen wie etwa SQS bei AWS. Durch passende Kafka-Operatoren lässt sich schließlich auf vermeintlich einfache Weise ein produktionstaugliche Kafka-Installation einrichten – der Aufwand für die langfristige Wartung des Kafka-Clusters wird jedoch gern außer Acht gelassen.
Auch andere Compute-Modelle wie etwa Serverless sind nicht unbedingt die passendste Wahl im Kubernetes-Umfeld. Daher werden diese im Zweifel auch gar in Betracht gezogen. Es stellt sich eine gewisse Betriebsblindheit ein, bei der vorhandene Cloud-Services komplett vom Radar verschwinden, da diese eben nicht den Kubernetes-Weg verfolgen. Natürlich gibt es mit Technologien wie knative auch Serverless-Lösungen für Kubernetes, aber letztlich besitzen diese nicht alle der so sehr begehrten Eigenschaften, die etwa AWS Lambda mit sich bringt. Die nahezu grenzenlose Skalierung von AWS Lambda lässt sich zwar prinzipiell auch mit Kubernetes umsetzen, in der Praxis ist dies jedoch aufgrund des hohen Aufwands eher selten der Fall. Sollte sich die Weiterentwicklung der Anwendung also eher in Richtung Serverless bewegen, wäre Kubernetes möglicherweise die falsche Grundlage gewesen.
Wenn anfänglich eher auf die Cloud-Services des Anbieters gesetzt wird, kann natürlich bereits eine Menge Erfahrung mit den Eigenarten des Anbieters gesammelt werden. Eigenarten, vor denen Kubernetes einen weitestgehend schützen kann. Die Erfahrung kann jedoch Gold wert sein, wenn es darum geht, gerade spezialisierte Services wie AWS Lambda oder Ähnliche zu nutzen. Nicht selten sind diese Services ja der Grund, warum Cloud Mehrwerte gegenüber dem eigenen Rechenzentrum hat. Mit Kubernetes dient die Cloud weitestgehend nur als Anbieter von virtuellen Maschinen. Das ist durchaus legitim, aber möglicherweise können so besagte Mehrwerte nur schwer realisiert werden. Sollte die Wahl bereits zu Beginn auf Kubernetes fallen, ist es sinnvoll, dies nicht zum Ausschlusskriterium für andere Cloud-Services zu machen. Gerade die Kombination aus Kubernetes und passenden Cloud-Services bringt eine Menge Vorteile mit sich, auch wenn sich die Integration zwischen den beiden Welten mitunter schwieriger gestaltet. So ist es sicher ratsam, statt der eigenen SQL-Datenbank im Cluster auf entsprechende verwaltete Angebote des Cloud-Anbieters zu setzen.
Fazit
Bei Bestandsprojekten, die schon etwas älter sind und grundlegende architekturelle Änderungen eher unwahrscheinlich sind, ist die Entscheidung, ob Kubernetes zum Einsatz kommen sollte, deutlich einfacher zu bewerten. Bei Projekten auf der grünen Wiese oder eben Bestandsprojekten die durchaus im Wandel sind, ist die Wahl schwieriger. Meist gilt jedoch: je einfacher, desto besser. Da Kubernetes selten einfach ist, scheint die Wahl anderer Cloud-Services daher durchaus passender, zumal es inzwischen Services gibt, die ebenfalls grundlegende Eigenschaften von Kubernetes besitzen. Container bereitzustellen, ist sicher kein Alleinstellungsmerkmal von Kubernetes mehr, wenn es heutzutage Lösungen wie App Engine bei Google oder AppRunnner bei AWS gibt. Cloud besitzt bereits eine gewisse Komplexität und ein weitere Indirektion durch Kubernetes wird für einfache Anwendung eher zu Frust führen, auch wenn die Entscheidung auf Basis eines gut gemeinten Blicks in die Zukunft getroffen wurde.
Eine allgemeine Empfehlung abzugeben, womit es zu starten gilt, ist aber dennoch schwer. Wichtig ist jedoch, sich vorher Gedanken zu machen. Allein darüber nachzudenken, was es bedeutet, mit Kubernetes oder eben Cloud-Services aus dem Compute-Bereich zu starten, macht einem die verschiedenen Kompromisse, die eingegangen werden, bewusst. Ein Umbau weg von Kubernetes kann gerade bei gereiften Anwendungen eine Menge Aufwand bedeuten – andersrum gilt es jedoch genauso! Sich langfristig etwas zu verbauen, geschieht in der Regel jedoch nicht, zumindest dann, wenn Denkweisen wie etwa Cloud-Native oder 12-Factor-App beherzigt werden. Solange tunlichst vermieden wird, bereits zu Beginn ein allzu komplexes Setup aufzubauen, das einen zu sehr an die getroffene Entscheidung kettet, sind beide Wege selten ein Problem.
Möchtest du mehr darüber erfahren?
Wir freuen uns auf den Austausch und/oder einen gemeinsamen Workshop.
