Container-Orchestrierung: "Wozu denn jetzt noch das Kubernetes-Monster???"
Kubernetes ist schon seit längerem ein heiß und teils kontrovers diskutiertes Thema. Für die einen ist es die moderne und alternativlose Art, (die eigene) Software zu betreiben. Für die anderen ist es nur der nächste Hype um eine Technologie, die man eigentlich nicht braucht. Auf die Frage, welche Position korrekt ist, gibt es keine eindeutige Antwort; es hängt von der Ausgangslage ab.
Kubernetes ist nicht für jedes Unternehmen die uneingeschränkt optimale Lösung - Ratschläge sind schwierig und können fehlgeleitet sein, wenn im Vorfeld die spezifischen Bedürfnisse nicht tiefer analysiert wurden. Das von Google entwickelte Open-Source-System zur Verwaltung von Container-Anwendungen bietet aber - wenn man sich darauf einlässt - grandiose Möglichkeiten. Inspirationen für Denkansätze und die Entscheidungsfindung geben wir anhand eines exemplarischen Gesprächs zwischen einer Entwicklerin und einem Entwickler, die hier auf sehr verschiedenen Seiten stehen.
Es war einmal an der Kaffeemaschine …
Stellen wir uns eine junge, dynamische Firma in Berlin vor, die für B2B-Kunden cloudbasierte Softwarelösungen entwickelt und betreibt. Früh am Morgen herrscht bereits reges Treiben rund um die Kaffeemaschine. Die Entwicklerin Laura trifft auf ihren früheren Mentor Felix und hat Infos im Gepäck. Eine kontroverse Diskussion entspinnt sich.
Laura: Hi Felix! Hast du schon gehört? Die Entscheidung ist getroffen: Wir führen Kubernetes als zentrale Betriebsplattform für unsere Software ein.
Felix: Hallo Laura, nee, wusste ich noch nicht. Ich hatte gehofft, sie entscheiden sich anders. Aber naja. Ich bedaure die armen Admins, die das jetzt auch noch an der Backe haben.
Laura: Die musst du gar nicht bedauern. Wir kaufen Kubernetes als Managed Service ein. Eine eigene Kubernetes-Installation können wir - wie du korrekt erkannt hast - nicht wirklich stemmen. Außerdem sind durch das Auslagern die Kosten viel transparenter und vorhersehbarer.
Felix: Aha. Wo geht's denn hin? AWS, Azure oder Google Cloud? Wird bestimmt nicht einfach, unseren Kunden beizubringen, dass nun die großen Ami-Konzerne ihre Daten abgreifen ...
Laura: Ach Felix. Wieso nur so negativ? Nicht nur die Hyperscaler (g+) bieten Kubernetes as a Service an. Man kann Kubernetes auch bei hiesigen Hostern wie Hetzner, Cancom oder unserem Provider bekommen. Und das mit Rechenzentren komplett in Deutschland.
Wozu das Kubernetes-Monster?
Felix: Verstehe. Trotzdem leuchtet mir nicht ein, wozu wir Kubernetes brauchen. Das ist doch eigentlich nur eine zusätzliche Abstraktion auf der Abstraktion. Mit unseren VMs sind wir von der unterliegenden Hardware schon unabhängig. Die VMs können wir mit Terraform(öffnet im neuen Fenster) und Ansible(öffnet im neuen Fenster) wunderbar automatisiert provisionieren.
Und selbst containerisierte Apps lassen sich mit docker compose (öffnet im neuen Fenster) in diesen VMs problemlos betreiben. Und das tun wir ja auch schon. Wir profitieren also schon von den Vorteilen containerisierter Apps. Wozu dann noch dieses Kubernetes-Monster einführen?
Laura: Ich denke, Kubernetes hebt die von dir angesprochenen Dinge wie automatische Provisionierung und containerisierten Betrieb auf ein neues Level. Zum Beispiel ist die Ressourcennutzung viel effizienter. Der "Totraum" bezüglich CPU und RAM auf den einzelnen VMs fällt weg. Unterm Strich brauchst du dadurch weniger Compute-Ressourcen für die gleiche Leistung.
Felix: Hhhmm. Ich weiß nicht. Die VMs lassen sich ja auch optimieren.
Laura: Klar, aber bei VMs mit jeweils unterschiedlichen Inhalten musst du gegebenenfalls sehr spezifisches Wissen haben, um da zu optimieren. Und du optimierst pro VM oder pro Applikation in der VM. In Kubernetes sind VM-Grenzen egal.
Du konzentrierst dich nur auf das Optimieren der Applikation und musst keine Rücksicht darauf nehmen, was sonst noch in der VM läuft. Das bedeutet weniger ungewollte Seiteneffekte und keine Betriebssystem- und Service-Upates auf der VM; die Verwaltung und Wartung von Kubernetes macht ja der Anbieter für dich. Ich finde, dadurch gewinnt man mehr Fokus auf die eigentlichen Apps - und um die geht's ja letztendlich.
Felix: Durch die VMs hast du aber eine Art natürliche Abgrenzung voneinander.
Laura: Für solche Abgrenzungen hat Kubernetes verschiedene Konzepte in petto; teilweise über Erweiterungen. Auch RBAC(öffnet im neuen Fenster) lässt sich mit Kubernetes abbilden.
Felix: OK. Aber bisher hast Du nichts Neues erzählt. Kubernetes kann genau das, was wir jetzt auch schon können. Nur neuer und cooler. Und dafür nehmen wir den ganzen Migrationsaufwand in Kauf? Kann ich nicht verstehen ...
YAML for the win!
Laura: Wenn du es so ausdrückst, hast du Recht. Allerdings lässt diese Sichtweise ein entscheidendes Puzzleteil außer Acht: Die Kubernetes-YAML-Manifeste. Alles, was du in Kubernetes definierst, definierst du über YAML. Natürlich gibt es Alternativen, aber wir haben uns für YAML entschieden da die sich sehr gut in Git tracken lassen und so auch den Gitops-Ansatz super unterstützen.
Diese YAML-Manifeste enthalten alles, was die jeweilige Komponente braucht. Dabei ist es egal, ob du einen Cronjob, einen Service oder eine Ingress-Regel definieren möchtest. Der grundsätzliche Aufbau ist ähnlich; aber jeder Typ enthält natürlich seine spezifischen Informationen. Und das alles in YAML. JSON ginge übrigens auch, aber wer würde das schon wollen.
Zusätzlich gibt es die Möglichkeit, komplette Anwendungen über sogenannte Helm(öffnet im neuen Fenster) -Charts als Paket zu installieren. Mit ein paar Zeilen Konfig kannst du so auch größere Anwendungen wie einen Secret-Store oder eine Container-Registry einfach installieren und konfigurieren.
Felix: Das heißt noch eine Abstraktion für Dinge, die wir schon haben?
Laura: Du siehst das zu negativ. Der große Vorteil ist, dass so auch Entwickler Dinge verwalten können, für die bisher oft Spezialwissen und -software nötig war. Du reduzierst also die Kopplung an eine bestimmte Softwarekomponente und an personenbezogenes Know-how.
Nimm' als Beispiel mal NGINX(öffnet im neuen Fenster) . Welcher Entwickler mag dessen Konfiguration? Ich kenne niemanden und auch mir ist das zu speziell. Aber eine Ingress-Ressource in Kubernetes schreibe ich dir in zwei Minuten. Und falls ich spezielle Konfigurationen brauche, sind die meist nur einen YAML-Key entfernt.
Zwar ist es möglich, dass ich mich dadurch wieder an die konkrete Implementierung kopple, aber manchmal geht das nicht anders. Trotzdem arbeite ich mit YAML und nicht mit einem spezifischen Konfig-System, das von Applikation zu Applikation unterschiedlich sein kann.
Und: Die YAMLs lassen sich sehr gut templatisieren, so dass je nach Anforderung eine entsprechend hohe Wiederverwendbarkeit gegeben ist.
Felix: ...
Laura: Felix?
Felix: Was? Ja, Sorry. Interessant. So habe ich das noch nie gesehen. Dieses ganzheitliche Verwalten des Softwarebetriebs durch Entwickler macht die Admins also überflüssig?
Laura: Nun, so weit würde ich nicht gehen. Aber die klassische Abhängigkeit vom IT-Operations-Team ( "Ich brauche noch 'ne Dev-VM" ) wird schon drastisch reduziert, so dass Entwicklung und Betrieb mehr zusammenwachsen, Schnittstellen verschwinden und der Übergang effizienter wird. Aber natürlich werden die Admins nicht überflüssig. Es gibt ja immer noch Dinge, um die sich gekümmert werden muss.
Felix: So? Um was denn?
Laura: Ich sehe Themen wie das Verwalten von zentralem Logging, Monitoring, Distributed Tracing, Passwortverwaltung und mehr. Natürlich nutzen die Entwickler all diese Dinge. Aber die entsprechenden Tools müssen installiert und deren Konfiguration gepflegt werden. Außerdem braucht es Abstimmung mit der Entwicklung, damit diese Tools auch effizient eingesetzt werden können.
Felix: Wir schaffen also auf der einen Seite Schnittstellen ab, um auf der anderen Seite neue zu schaffen?
Laura: Findest du diese Sichtweise nicht etwas konstruiert? Nimm beispielsweise das zentrale Logging: Die Konsolenausgabe eines jeden Services in Kubernetes wird automatisch zu einem zentralen Log-Aggregator weitergeleitet. Dort sind dann alle Logs abrufbar, man kann Alerts definieren und sogar mit KI-Systemen eventuelle Unregelmäßigkeiten aufspüren.
Natürlich lassen sich auch VMs oder Anwendungen an diesen zentralen Log-Aggregator anschließen, aber eben nicht automatisch, sondern mit zusätzlichem Aufwand und/oder Abhängigkeiten.
Skalierende Container
Felix: Aber um in Kubernetes zu laufen, muss jede Anwendung erstmal containerisiert werden, richtig?
Laura: Ja. Und um deinen nächsten Einwand vorwegzunehmen: Das ist Aufwand, der einmal gemacht werden muss und für viele oder gar die meisten Anwendungen wohl recht gering ist.
Microservice, Monolith, Self-contained System: Alles lässt sich in Kubernetes betreiben. Natürlich spielt Kubernetes seine Stärke bei Microservices aus, aber das (Heraus-)Schneiden von Microservices fällt leichter, wenn der Monolith schon im Kubernetes-Cluster läuft und man nicht noch über Cluster-Grenzen hinweg kommunizieren muss.
Und einen zentralen Punkt haben wir noch gar nicht angesprochen.
Felix: So? Welchen denn?
Laura: Skalierung.
Felix: Skalierung? Du meinst diese automatische Skalierung, von der alle sprechen? Ich habe dieses Argument schon oft gehört, aber konkret tun das doch nur die wenigsten. Schließlich ist das äußerst komplex, wenn man das zuverlässig implementieren will, oder?
Laura: Ja und nein. Vollautomatische Skalierung inklusive Vergrößerung und Verkleinerung des Clusters ist in der Tat sehr komplex. Aber schon manuell verwaltete Skalierung ist in Kubernetes so viel einfacher als auf VMs. Wir haben ja schon über den "Totraum" gesprochen.
Andererseits kannst du mit sehr, sehr wenig Aufwand sowohl vertikal (genau wie in der VM) als auch horizontal skalieren. Die horizontale Skalierung in Kubernetes ist allerdings unabhängig von konkreten VM-Größen. Dedizierte VM-Neustarts aufgrund von Ressourcenänderung fallen also weg. Wird es eng im Cluster, werden einfach neue Nodes hinzugefügt. Und schon können wieder beliebig viele Pods (= Container-Gruppen aller Art) gestartet werden.
Das ultimative Betriebssystem
Die Kaffeetassen von Laura und Felix sind längst ausgetrunken. Da kommt Dominik zur Kaffeemaschine, bemerkt die beiden und klingt sich in das Gespräch ein:
Dominik: Nanu, habe ich euch beide nicht eben schon hier gesehen? Was gibt's denn bei euch so Spannendes?
Felix: Nichts weniger als das neue allumfassende IT-Betriebssystem!
Laura: Deinen sarkastischen Unterton kannst du dir sparen, Felix!
Aber eigentlich hast du Recht. Kubernetes ist nicht nur Container-Orchestrierung, sondern bietet auch Dinge wie Netzwerk-Routing, strikte Isolation von Komponenten/Systemen, die Installation vorgefertigter Softwarepakete und einiges mehr. Dabei bleibt die Verwaltung stets übersichtlich und beherrschbar.
Ich würde also in der Tat sagen: Kubernetes ist das neue ultimative IT-Betriebssystem. Es lässt sich quasi jede Anwendung in Kubernetes betreiben - und das ohne die Grenzen und Nachteile von dedizierten VMs.
Jochen R. Meyer arbeitet seit über 15 Jahren in der Softwareentwicklung; zuletzt mit dem Schwerpunkt Devops. In seiner aktuellen Rolle als Head of Devops & ITops arbeitet er mit seinem Team an effizienter Provisionierung von (virtueller) Infrastruktur und darauf aufbauender Developer Experience. Unter dem Team-Motto "We deploy on Fridays!" steht dabei Qualität, Zuverlässigkeit und Nachhaltigkeit an erster Stelle.