Die Zukunft von Kubernetes – Erkenntnisse aus dem Kamingespräch auf der DEVOPS Conference

Von der Container-Orchestrierung zur Control Plane

Viele von uns sehen Kubernetes als Plattform für die Container-Orchestrierung. Ihr gebt an, dass ihr drei Instanzen, eine bestimmte Menge Speicher und CPU benötigt. Und schon startet ihr mit glänzenden neuen Containern durch.

Doch Kubernetes hat sich gemeinsam mit dem Web zu etwas viel Größerem entwickelt. Denkt daran, wie sich das Web verändert hat: Nicht jeder, der einen Webserver betreibt, braucht eine Website. Dennoch können wir das zugrunde liegende HTTP-Protokoll nutzen, um Informationen auszutauschen – etwa über eine REST API.

Wenn man darüber nachdenkt, unterscheidet Kubernetes von früheren Tools wie Puppet, Chef oder Ansible vor allem das Konzept des State Managements. Es baut auf der Promise Theory auf: Ihr formuliert, was passieren soll, und veröffentlicht dies als Daten. Das unterscheidet sich vom Scripting, bei dem ihr etwas in Ruby, Python oder Bash schreibt und es auf einem Rechner ausführen lasst.

Ihr beschreibt also eine Datenbank und übergebt sie dem API-Server. Dessen Aufgabe ist es, einen Controller zu starten, der die Daten überwacht, versteht und euch eine Datenbank bereitstellt. Die Control Loop und Control Plane, die bisher den Status prüften und abglichen – entscheidend für die Container-Orchestrierung –, werden heute viel breiter eingesetzt. Das ist zur Superkraft von Kubernetes geworden.

Dadurch erweitern sich die Einsatzmöglichkeiten von Kubernetes um eine Vielzahl neuer und spannender Anwendungsfälle. Tools und Lösungen wie Crossplane nutzen die Funktionen der Control Plane umfassend. Container werden dabei fast zur Nebensache.

Zeichen der Reife: Das Distro-Fieber

Mit dieser Transformation wird Kubernetes reifer – ganz so, wie Linux in den guten alten Zeiten gereift ist.

Wenn ihr Kubernetes von Grund auf installiert, so wie ihr früher eure eigenen OS-Distributionen erstellt habt, haben wir eine Neuigkeit für euch: Es gibt einen besseren Weg. So wie es viele vorkonfigurierte Linux-Varianten wie Red Hat, CentOS, Debian und SUSE gibt, stehen heute vorkonfigurierte Kubernetes-Angebote bereit, etwa GKE von Google Cloud, EKS von AWS und AKS von Azure. Oder OpenShift, wenn ihr etwas unabhängiger bleiben möchtet.

Ihr müsst keine Zeit und Mühe mehr investieren, um eure Distribution von Grund auf zu erstellen: Mit den fertigen „Distributionen“ könnt ihr direkt loslegen und eure Plattform deutlich schneller entwickeln.

Silos mit einer API überwinden

Seien wir ehrlich: Die Welt war schon immer von Silos geprägt. Meist lief es so: „Gebt uns euren Code, dann führen wir eine Reihe von Skripten und Logik aus, und irgendwie landet alles in der Box.“ Und wenn etwas kaputtging, kam man zusammen, um den Fehler zu beheben – und wiederholte das immer wieder über lange Zeit.

Ihr müsst Silos aufbrechen, richtig? Nun ja, Silos sind nur dann problematisch, wenn sie nicht miteinander kommunizieren können. Mit einer API fühlt es sich nicht mehr so isoliert an, selbst wenn ihr in einem Silo arbeitet.

Vieles funktioniert noch genauso wie vor 15 Jahren. Ihr schreibt Code, führt Tests aus, erstellt Artefakte und lasst dann andere beschreiben, welche Zonen sie benötigen. Was Kubernetes wirklich verändert, ist die letzte Meile. Das bedeutet: Ihr müsst nicht allen Entwicklern Docker, Vagrant, Puppet oder Ansible beibringen. Diese Tools sind lediglich Mittel zum Zweck.

Die Idee ist, dass jemand deklarieren kann, was er von euch benötigt, und ihr diese Informationen im Hintergrund in den gewünschten Zustand überführt. Kubernetes macht das einfach. So verlieren Silos deutlich an Bedeutung.

Das ist wie ein Vertrag für die Anforderung von Services oder Systemen, der implizit festlegt, wie die Interaktion funktioniert und was zu erwarten ist. Eine solche Definition vermittelt das Gefühl eines Versprechens oder Vertrags mit einem SLA – und macht vieles deutlich einfacher.

Der Vergleich mit einem Ansatz wie Terraform macht es vielleicht leichter verständlich. Bei Terraform schreibt ihr – stark vereinfacht gesagt, wir wissen – Terraform-Code in eine Datei auf eurem Laptop, und er wird nur ausgeführt, wenn ihr ihn startet. Wenn euer Laptop oder der zentrale Server, auf dem ihr Terraform aufgerufen habt, ausgeschaltet ist, passiert nichts. Terraform kann nichts tun, bis es erneut aufgerufen wird.

Kubernetes verfolgt einen anderen Ansatz. Es gibt immer einen Controller, der rund um die Uhr euren gewünschten Zustand beobachtet und versucht, ihn mit der Realität abzugleichen. Das System wirkt selbstheilend, weil es davon ausgeht, dass der deklarierte Zustand jederzeit erfüllt sein soll.

Kubernetes liebt Pipelines – und umgekehrt

Eine der großen Stärken von Kubernetes ist, dass ihr von Infrastructure as Code (IaC) zu Infrastructure as Data (IaD) wechseln könnt.

Der Unterschied klingt vielleicht nicht groß, bringt aber erhebliche Vorteile mit sich – etwa die Möglichkeit, eine Pipeline aufzubauen.

Mit Code lassen sich Pipelines nur schwer aufbauen, weil ein Tool die Syntax und Skriptsprache eines zuvor verwendeten Tools nicht verstehen kann. Wenn ihr Infrastruktur jedoch in Daten überführt, könnt ihr sehr nützliche Dinge tun, zum Beispiel Policies hinzufügen. Das ist ein großer Fortschritt für die effektive und sichere Verwaltung von Ressourcen.

Stateful oder nicht stateful – ist das hier die Frage?

Manche möchten alles in Kubernetes bündeln. Und tatsächlich können auch stateful Services in Kubernetes laufen, doch Kubernetes kann euch dabei nur bis zu einem gewissen Punkt unterstützen.

Die meisten SQL-Datenbanken wie Postgres und MySQL bevorzugen Stabilität. Sie sind nicht dafür ausgelegt, wechselnde IPs und zufällige Maschinenausfälle zu tolerieren. Wenn ihr solche Datenbanken in Kubernetes betreiben möchtet, braucht ihr Unterstützung durch einen Operator wie Vitess, ein Datenbank-Clustering-System zur horizontalen Skalierung von MySQL.

Die andere Möglichkeit besteht – sofern verfügbar – darin, Managed Services für Datenbanken zu nutzen und eure Anwendungen in Kubernetes entsprechend zu konfigurieren. Wenn ihr Datenbanken als Managed Service nutzt, sinkt auch der Aufwand für den Betrieb mehrerer Datenbanken. Das hilft euch, den Blast Radius klein zu halten und die Auswirkungen zu minimieren, falls etwas schiefgeht.

Denkt daran: Kubernetes ist nur so gut wie die Infrastruktur, auf der es läuft

Eine Frage, die wir manchmal hören: Lässt sich Kubernetes On-Premises betreiben? Die Antwort lautet: Ja, irgendwie. Die eigentliche Frage ist: Solltet ihr es tun?

Das hängt ganz von euren Anforderungen und eurer Infrastruktur ab. Kubernetes ist nur so gut wie die Infrastruktur, auf der es läuft. On-Premises-Kubernetes kann nur so gut sein wie die zugrunde liegende Compute-Plattform, auf der es installiert ist. Wenn ihr Kubernetes On-Premises betreiben möchtet, solltet ihr euch fragen, ob ihr Services auf demselben Niveau wie Cloud-Anbieter bereitstellen könnt. Kubernetes setzt darunter eine IaaS-Schicht voraus, die Maschinenautomatisierung sowie Zugriff auf Storage und Netzwerk bereitstellt. Vernachlässigt also nicht die grundlegenden Dinge.

Kubernetes erweitern

Viele wünschen sich Ergänzungen und Verbesserungen für Kubernetes – sie möchten quasi alles auf einmal haben.

Eine häufige Anforderung ist ein vielseitigerer Netzwerk-Stack. Kubernetes verfolgt hier einen klaren Ansatz: Beispielsweise bevorzugt es eine dedizierte IP-Adresse pro Pod. Erst seit Kurzem ist es möglich, Dual-IP-Stacks für IPv4 und IPv6 zu verwenden.

Kubernetes ist außerdem nicht als Plattform gedacht, sondern als Möglichkeit, Plattformen zu bauen. Pods und RBAC sind solide, ausgereifte Kernkonzepte. Die zusätzlichen Komponenten, etwa Admission Controller, erweiterte Netzwerk-Controller und weitere, entwickeln sich noch weiter, während wir dazulernen.

Das unglaubliche Buffet der CNCF Landscape

Wenn wir schon über Erweiterungen für Kubernetes sprechen, solltet ihr die CNCF Landscape der CNCF (Cloud Native Computing Foundation) nicht vergessen. Sie ist eine äußerst umfassende Ressource – was wohl die Untertreibung des Jahres ist – und bietet jede Menge großartige Projekte.

Denkt aber daran: Sie ist lediglich eine riesige Buffetkarte, keine Liste empfohlener oder unbedingt erforderlicher Komponenten. Kubernetes besteht aus einer Reihe von Entscheidungen darüber, wie Dinge umgesetzt werden. Die CNCF bietet mehrere Optionen für ähnliche Aufgaben, von denen viele noch entwickelt werden und reifen.

Mit Kubernetes können Nutzer über Operatoren neue Workload-Typen definieren, etwa hochverfügbare Redis-Cluster. Leider entwickeln viele Operatoren mit einer festen Abhängigkeit von Kubernetes. Stattdessen sollten Operatoren unabhängig von Kubernetes konzipiert sein: Die Logik zum Beispiel für das Erstellen eines Redis-Clusters sollte portabel und über eine API verfügbar sein. Diese kann dann mithilfe von CRDs in Kubernetes integriert werden. So bleibt alles flexibler.

Was ist also cool an der CNCF?

Am Ende des Gesprächs wollten wir Kelseys zum Meme gewordene Dope-Bewertungsskala mit dope, pretty dope, extra dope und super dope auf die Probe stellen und baten Kelsey, einige interessante CNCF-Projekte zu bewerten. Hier sind einige seiner Favoriten (für mehr guten Stoff schaut euch das Video an …):

Vault (Secrets Management): super dope

ArgoCD (deklaratives GitOps): super dope

Keda (eventgesteuertes Autoscaling mit einer Vielzahl von Plugins): extra dope

Das superdopeste Projekt überhaupt – abgesehen von Kubernetes selbst – ist Open Policy Agent (OPA). Es erhält nicht genug Anerkennung für das, was es leistet. Zusammen mit Infrastructure as Data ermöglicht uns OPA, Richtlinien anzuwenden, bevor Dinge eingecheckt und umgesetzt werden.

Kurze Zusammenfassung

Im Fireside Chat haben wir viele Themen rund um Kubernetes und seinen Stand im Jahr 2022 besprochen. Wenn wir alles auf drei Kernpunkte reduzieren müssten, wären es etwa diese:

1. Denkt bei Kubernetes nicht mehr nur an eine Plattform zur Container-Orchestrierung. Es hat sich zu einer Control Plane entwickelt, die ihr viel breiter einsetzen könnt – und genau das ist die Superkraft von Kubernetes.

2. Kubernetes unterstützt euch beim Übergang von Infrastructure as Code zu Infrastructure as Data und dabei, die Leistungsfähigkeit von Pipelines wirklich auszuschöpfen.

3. Ihr könnt zwar auch zustandsbehaftete Services in Kubernetes betreiben, solltet aber zweimal überlegen, ob das sinnvoll ist. Managed Services können den Aufwand reduzieren und helfen, alles einfach zu halten.

Insgesamt begeistert uns, wie weit Kubernetes seit seiner Einführung 2014 gekommen ist. Und wir freuen uns darauf, wie weit es sich in den kommenden Jahren noch entwickeln kann!