Erkan Yanar erlebt dies häufig in seinen Kubernetes-Trainings. Niemand zwingt Teams dazu, sagt er. Kubernetes hat keine technische Sperre gegen imperatives Arbeiten. Aber es lohnt sich, es anders zu machen.

Ein Beispiel: Ein Deployment läuft nicht. Der schnelle Weg ist kubectl exec, rein in den Container, das Problem beheben; das System läuft wieder. Schon beim nächsten Rollout taucht das Problem wieder auf, weil niemand die Änderung deklariert hat … Das ist kein Werkzeugproblem, denn Kubernetes tut nur das, was du beschreibst.

Kubernetes Training für Anfänger

Entdecke das Kubernetes Training für deinen Einstieg in containerbasierte Orchestrierung

Mehr erfahren

Warum Kubernetes oft imperativ statt deklarativ genutzt wird

Deklarativ bedeutet: ich beschreibe, was am Ende da sein soll. Nicht wie es passieren soll. Kubernetes nimmt diese Beschreibung und sorgt dafür, dass der Zustand eintritt. Und wenn er abweicht, stellt es ihn wieder her.

Erkan beschreibt das anhand seiner Trainings: Am Anfang greifen viele noch direkt ins System ein. Sie öffnen Container, ändern Konfigurationen, lösen Probleme situativ. Nach drei Tagen sieht das anders aus. Dann hat die Gruppe für jeden Bedarf ein Objekt: Reverse Proxy, Storage, Monitoring, Autoskalierung, DNS. Alles als Textdatei, alles in einem Verzeichnis. Genau so ist das System gedacht. „Wir haben nie diese Textdateien verlassen”, sagt er. Nichts läuft außerhalb dieser Logik.

Nicht auf die Menge der Objekte kommt es an – sondern deren Einheitlichkeit. Kubernetes unterscheidet nicht zwischen Infrastruktur und Anwendung. Beide beschreibst du. Beide stellt das System her. Beide folgen derselben Steuerungslogik.

Wer vorher Puppet, Ansible, Corosync genutzt hat – der hat für jede Aufgabe ein eigenes Toolset gelernt. Kubernetes ersetzt das nicht durch ein besseres Tool. Es ersetzt das durch ein einheitliches Modell.

Wie die Kubernetes-API Portabilität ermöglicht

Welche Container Runtime er nutzt, ist Erkan egal. Docker, CRI-O, Webassembly. Er geht an die API, sagt was er will – und wer das darunter umsetzt, ist eine Implementierungsentscheidung, keine Designentscheidung. Dasselbe gilt für Storage, für Netzwerk, für Monitoring. Die Schnittstelle bleibt stabil. Was dahinter liegt, ist austauschbar.

Das macht Portabilität möglich. Wer gegen die Vanilla Kubernetes API entwickelt, kann das System verschieben. Wer OpenShift-spezifische Objekte nutzt, AWS-spezifische Netzwerkfeatures einbaut, sich auf Cloudwatch verlässt – der hat Kubernetes zwar auf dem Label, aber beim Konzept verlassen. Wer migriert, muss nicht die Umgebung wechseln – er muss Objekte umschreiben. Das wird teuer.

Vanilla Kubernetes ist für Erkan der sichere Hafen. Was darüber hinausgeht, sollte eine bewusste Entscheidung sein – keine Bequemlichkeit im laufenden Betrieb.

Kubernetes Training für Fortgeschrittene

DevOps Prozesse automatisieren und komplexe Container-Orchestrierung-Probleme lösen

Mehr erfahren

Wie Kubernetes zur Grundlage interner Plattformen wird

Unternehmen können darauf ihre eigenen Plattformen bauen: Abstraktionsschichten für Entwickler, Selfservice-Oberflächen, domänenspezifische Objekte. Die Entwickler sehen dann kein Kubernetes-Objekt mehr, sondern eine Schnittstelle, die zu ihrer Aufgabe passt. Dahinter läuft Kubernetes. Die Komplexität ist nicht verschwunden, sondern verschoben.

Erkan nennt das „Plattform für Plattformen“. Gemeint ist: Das, was auf Kubernetes betrieben wird, folgt denselben Mustern wie Kubernetes selbst. Deklarativ, API-basiert, mit derselben Steuerungslogik. Von außen sieht man nicht, was Kubernetes-Core ist und was Erweiterung – weil es technisch keinen Bruch gibt. Es ist dasselbe Konzept, nur eine Ebene höher angewendet.

Das ist kein abstraktes Ideal, sondern die Folge konsequenter Nutzung. Wer einmal verstanden hat, wie das Modell funktioniert, baut automatisch in diesem Modell – auch eine Ebene höher. Der Workflow bleibt derselbe, die Werkzeuge bleiben dieselben. Die Leute müssen nichts Neues lernen, um eine Ebene höher zu arbeiten.

„Von außen sieht das alles gleich aus”, sagt Erkan. „Du würdest nicht sehen, was Kubernetes ist und was nicht.”

Bild: Erkan Yanar, freiberuflicher Consultant und DevOps-Experte sowie Trainer der DevOpsCon Camps

Warum Kubernetes auch bei falscher Nutzung funktioniert

Niemand zwingt dich, deklarativ zu arbeiten, erklärt Erkan. Du kannst alles machen – Container manuell konfigurieren, imperativ eingreifen, proprietäre Erweiterungen bauen. Kubernetes stoppt dich nicht. Es liefert das Modell. Was du daraus machst, ist deine Entscheidung.

Ein Beispiel: Es gibt Toolhersteller, die machen aggressiv Werbung für Live-Migration in Kubernetes-Umgebungen. Das klingt natürlich praktisch. Aber Erkan fragt: „Was willst du denn migrieren? Du hast ja keinen State.” Wenn der Container wegfällt, baut Kubernetes ihn einfach neu. Live-Migration ist ein Konzept aus der alten Rechenzentrumslogik – damals, als Server heilig waren und Ausfälle um jeden Preis verhindert werden mussten. In Kubernetes ist das ein Antipattern. Wer es trotzdem einbaut, schleppt das alte Denken in ein System, das davon befreien sollte.

Nicht Kubernetes versagt. Sondern das Modell wird nicht genutzt. Ein direkter Eingriff hier, eine Cloud-spezifische Lösung dort, ein Monitoring-System, das tief in die Plattform eingebaut wird – jede dieser Entscheidungen funktioniert kurzfristig. Jede davon untergräbt aber das, was Kubernetes zur Plattform macht.

Wann Kubernetes sinnvoll ist – und wann nicht

Lohnt sich der ganze Aufwand überhaupt? Diese Frage wird Erkan in fast jedem Training gestellt. Seine Antwort ist kein Architektur-Argument, sondern ein ökonomisches: „Frei nach dem Ökonomen David Ricardo: Die Kosten eines Objekts liegen nicht im Erfinden, sondern im Erstellen.“ Auf Kubernetes übertragen: Ein Deployment ist das Werkstück. Je öfter du deployst, desto günstiger wird jedes einzelne. Die Plattform lohnt sich, wenn Wiederholung die Regel ist.

Die Antwort hängt nicht von der Größe des Systems ab, sondern von seiner Dynamik. Viele Deployments, hohe Veränderungsrate, wachsendes Ökosystem – dann ja. Wenige Deployments, stabiler Betrieb, kein Skalierungsdruck – dann ist der Aufwand größer als der Gewinn.

Erkan erzählt von einem Kunden, den er früher betreut hat. Alles nette Leute, sagt er; die Arbeitsweise: Manufaktur. Alles individuell, wenig automatisiert, aber stabil. Es hat funktioniert. Sein Schluss: Wer keinen Schmerz hat, braucht keine Plattform. Kubernetes ist kein Selbstzweck, sondern eine Antwort auf ein Problem. Wer das Problem nicht hat, braucht die Lösung nicht.

Was sich ändert, wenn man Kubernetes als Plattform nutzt

Das Grundprinzip von Kubernetes ist über die Jahre dasselbe geblieben. Was sich geändert hat – und weiter ändert – ist, wie konsequent das deklarative Modell durchgezogen werden kann. Kubernetes wird immer deklarativer. 

Das eigentliche Problem dabei ist das Denken, das Leute aus einer anderen, alten Welt mitbringen. Wer gelernt hat, Server zu stabilisieren, Systeme zu pflegen, Probleme direkt zu beheben – der denkt in Kontrolle. Modernes Kubernetes denkt in Beschreibungen. Ein Container verschwindet. Das System baut ihn neu. Das ist keine Fehlfunktion, sondern die gewollte Mechanik. „Dein Container hat keinen State in sich. Das ist die ganze Magie.”

Erkan arbeitet in seinen DevOpsCon Camps genau an diesem Punkt – nicht an neuen Tools, sondern am Modell, mit dem man die vorhandenen benutzt. Hands-on, am eigenen System, drei Tage lang.

Wer nach diesem Text seinen eigenen Stack mental durchgegangen ist und nachdenklich wurde: Das ist der Ausgangspunkt des DevOpsCon Camps mit Erkan Yanar.