In der IT-Welt gibt es immer wieder Technologien, die als universelle Lösung für alle Probleme angepriesen werden. Kubernetes (K8s) ist eine davon. Als mächtiges Tool für Container-Orchestrierung hat es seinen Platz – aber wie bei jedem Werkzeug gilt: Man sollte wissen, wann es sinnvoll ist, es einzusetzen – und wann nicht, insbesondere im Kontext von Cloud Workloads und modernen Anwendungen.
„Kubernetes ist eine Open-Source-Plattform für die Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen. Es ermöglicht die automatische Skalierung von Anwendungen, die Hochverfügbarkeit und die automatische Rollout-Funktionen.“
Soweit so gut und korrekt, aber das ist nicht die ganze Wahrheit, denn Aspekte wie Storage, Security, Services, APIs und das Management der zugrunde liegenden Infrastruktur spielen ebenfalls eine wichtige Rolle.
Das heißt, dass ähnliche Probleme wie bei einer VMWare, einem Hyper-V oder einem Proxmox-Server auftreten können und zu lösen sind – nur komplexer, da zusätzlich Container Orchestrierung, Services, Pods und Anwendungen im Verbund betrachtet werden müssen.
Dementsprechend muss man weit vorher planen und überlegen, wie man seinen Kubernetes-Cluster aufbauen und skalieren will. Das geht innerhalb von Teils Minuten, spätestens wenige Stunden, wenn man erstmal die Tutorials dazu zu Rate zieht und sich mit Themen wie Storage Klassen, Service Typen, Ingress, API Server und Security Policies beschäftigt.
Diese Cluster wirken dann auch schon robust und bereit, den Andrang an Pods zu übernehmen.
Und hier liegt die Falle: Was, wenn sich die Bedingungen ändern?
Die oft übersehenen Fragen bei der K8s-Planung:
Bevor Sie in die Kubernetes-Welt eintauchen, sollten Sie folgende Fragen beantworten können. Unabhängig davon, ob Sie auf Google Cloud, AWS, Azure oder On-Premises Kubernetes Cluster betreiben:
Ist der Storage in der Lage, die Anforderungen zu erfüllen?
Bei großen Clustern fallen schnell viele Daten an, die ggfs. auch schnell geschrieben werden müssen, etwa die Lidar Rohdaten die aufgenommen werden um selbstfahrende Autos zu trainieren.
Ist das Netzwerk robust?
Vor allem im Bezug auf Storage, wenn die einzelnen Pods Speicher haben wollen, ist ein stabiles Netzwerk sehr wichtig, damit Services zuverlässig erreichbar sind und Container-basierte Applications performant laufen können.
Ist der Cluster auch sauber abgeschirmt gegen Angriffe?
Nur weil wir uns in Containern befinden heißt es nicht, dass wir jetzt Narrenfrei sind. Ja, die Abstraktion ist inherent schonmal etwas sicherer als auf Bare Metal, aber vor allem Zero-Day Exploits sind ein großes Risiko. Sicherheitsupdates müssen regelmäßig angewendet werden , inklusive Patches für Kubernetes selbst, Container Images, APIs und genutzte Services.
Wie updatete ich ein Cluster ohne, dass meine Anwendungen ausfallen?
Stichwort: Rolling Updates und Ephemeral Pods
Ist die Anwendung in der Lage mit spontanen Neustarts zu umgehen?
Wichtig, da Pods im Fall von Fehlern oder Updates neugestartet werden. Das ist gewolltes Verhalten und die Anwendung muss dementsprechend in der Lage sein damit umzugehen.
Man muss hier dazusagen, dass das im Optimalfall immer gegeben ist, da Anwendungen auch auf Bare Metal Maschinen abstürzen können.
Sind die Cluster Manager und Worker aufgeteilt, falls ein Rechenzentrum ausfällt?
Vor allem wichtig bei HA-Clustern, um die Verfügbarkeit zu gewährleisten, insbesondere wenn geschäftskritische Services und APIs dort laufen.
Ist die Storagelösung in der Lage Persistente Volumes bereitzustellen? Ist das überhaupt notwendig?
Das ist entscheidend für die Persistenz von Daten und die Verfügbarkeit der Anwendung.
Was wenn plötzlich doch Windows-Worker benötigt werden?
Normalerweise fängt man mit Linux-Worker an, für Windows muss man drauf achten, dass das richtige Cluster Network Interface (CNI) gewählt wird. Das geht nur beim Erstellen eines neuen Clusters und betrifft auch das Management von Windows Containern und gemischten Workloads.
Natürlich ist der Cluster selbst nicht das einzige Problem hier, denn die Manager- und Workernodes müssen auch noch irgendwo laufen! Das heißt, dass die Infrastruktur unter dem Kubernetes Cluster auch noch aufgesetzt werden muss.
Diese Entscheidung hat erhebliche Auswirkungen auf Kosten, Komplexität und Wartbarkeit.
Auch ganz wichtig: Ist Personal vorhanden, das mit Kubernetes vertraut ist und die Cluster betreuen kann? Muss man hier ggfs. extra einen Dienstleister einstellen, der Management, Support und Betrieb der Kubernetes Services übernimmt?
Die meisten Cloud Provider bieten direkt managed Kubernetes an, aber ist es das wert?
Die Datenhoheit verliert man, da man die Infrastruktur nicht selbst kontrolliert, insbesondere bei vollständig gemanagten Services wie Google Kubernetes Engine oder ähnlichen Angeboten in der Cloud.
Dazu kommen die Kosten, die meistens erstmal gering anfangen aber schnell steigen können.
Wenn man dann seine Daten wieder umziehen will, muss man oft horrende Summen zahlen, um seine Daten vom Cloud Provider zurück zu kriegen.
Stichwort: Vendor Lock-In
Ist das Personal vorhanden, um die Infrastruktur aufzusetzen und zu betreuen?
Damit ist hier die Infrastruktur gemeint, auf der das/die Kubernetes Cluster aufgesetzt werden, inklusive Storage, Netzwerk, Security und Monitoring der Nodes, Pods und Services.
Sind mehr Rechenzentren vorhanden um die Infrastruktur zu verteilen?
Sehr wichtig für die Verfügbarkeit, insbesondere wenn kritische Applications und Workloads über mehrere Standorte laufen sollen.
Vorteile:
Nachteile:
Komplexität erhöht sich, da man zwei verschiedene Infrastrukturen verwalten muss.
Wenn man aktuell schaut, so sieht man, dass RAM und GPUs aktuell sehr teuer sind. Wenn das Timing nicht passt, kann es entsprechend teuer werden.
Looking at you Cloudflare.
Eine Webseite High Available machen? Muss man dafür dringend Kubernetes verwenden, oder reicht ein klassischer Webserver mit Load Balancing Services und etwas Automatisierung?
Eine Anwendung die vom Hersteller containerisiert ausgeliefert wird, muss man dafür ein ganzes Team an Kubernetes-Experten haben?
Oder tut es hier ein paar VMs mit Regeln in verschiedenen Rechenzentren zu halten und die Anwendung mit z. B. Ansible zu verteilen?
Wenn man nur ein kleines Projekt hat, die Anwendung sogar containerisiert ist, muss man jetzt extra dafür ein großes Cluster hochziehen?
Ich denke nicht. Es ist effizienter und kostengünstiger, eine schlanke Automatisierung mit Hilfe von Tools wie Terraform, Ansible oder Puppet zu implementieren, anstatt einen kompletten Kubernetes-Stack aufzubauen.
Wir als Dienstleister sind darauf bedacht, den Kunden zu unterstützen, eine passende Lösung zu finden und unterstützen dann natürlich auch bei der Umsetzung. Dabei achten wir darauf, nicht ein Produkt über ein Problem zu stülpen, sondern arbeiten zusammen einen Weg aus, die gegebenen Ziele zu erreichen, egal ob es um klassische VMs, Container, Kubernetes Services oder Cloud Workloads geht.
Kubernetes ist ein mächtiges Werkzeug, aber wie bei jedem Werkzeug gilt:
Nicht jedes Problem ist ein Nagel, und nicht jede Lösung sollte ein Vorschlaghammer sein.
„*“ zeigt erforderliche Felder an
