Das passende Training Kubernetes Einführung Training – 3 Tage Praxis mit Live-Cluster
Dein Docker-Compose-Wissen hilft dir bei Kubernetes nicht - teilweise schadet es sogar
Ganz ehrlich: Die meisten Artikel zum Thema machen dir Mut - “du kennst schon mehr von Kubernetes, als du denkst”. Aus meinen eigenen Kubernetes-Einführungstrainings sage ich das Gegenteil. Übertragbar ist nur eine einzige Ebene: dein Container-Image. Alles, was du in Docker Compose über Netzwerk, Volumes und “läuft doch”-Monitoring gelernt hast, musst du dir aktiv wieder abgewöhnen - sonst führt es dich in Kubernetes auf die falsche Fährte.
Übertragbar ist das Image - nicht mal mehr Docker selbst
In einem Training fragte mich neulich ein Teilnehmer, ob man für mehrere Container mit Hilfsaufgaben in einem Pod nicht im Grunde Docker Compose braucht. Verständliche Frage - dahinter stecken aber gleich zwei Missverständnisse auf einmal.
Erstens: Kubernetes braucht seit Version 1.24 nicht mal mehr Docker selbst. Der interne Übersetzer dafür, dockershim, ist laut Kubernetes-Doku seit genau dieser Version raus - Kubernetes startet Container heute direkt über containerd oder CRI-O. Was bleibt, ist dein Dockerfile und das OCI-Image, das dabei rauskommt. Das startet jede Kubernetes-Runtime genauso anstandslos, wie früher Docker selbst es tat.
Zweitens, und das ist der eigentliche Punkt: Selbst die Compose-Ebene oben drauf - Netzwerk, Volumes, depends_on - überträgt sich nicht einfach mit. Für “warte, bis der andere Container bereit ist” gibt’s mit Init-Containern zwar ein eigenes Kubernetes-Konzept, für eigene Projekt-Netze übernehmen Namespace, Service und Cluster-DNS die Rolle - aber keins davon ist eine Übersetzung deiner docker-compose.yml. Das sind eigenständige Konzepte, die du separat lernen musst, nicht wiedererkennst. Wie viele Container überhaupt in einen Pod gehören, ist nochmal eine eigene Geschichte - dazu habe ich einen eigenen Artikel geschrieben.
Das Netzwerk, von dem du glaubst, du kennst es
Besonders hartnäckig hält sich die Netzwerk-Vorstellung. Ein Teilnehmer mit Docker- und Podman-Hintergrund fragte mich gezielt nach Netzwerk-Adressierung und Routing - er war es gewohnt, dass jede Anwendung ihr eigenes, abgeschottetes Netz bekommt, so wie es Compose pro Projekt automatisch anlegt.
Kubernetes tickt anders. Die IP für einen Pod vergibt automatisch das Netzwerk-Plugin, sobald er startet - fertig, keine Extra-Abschottung. Jeder Pod darf mit jedem Pod reden, egal auf welchem Node, offene Tür überall. Wer das einschränken will, muss aktiv eine NetworkPolicy schreiben. Wie tief dieses Kaninchenloch geht - warum selbst eine Default-Deny-NetworkPolicy noch lange kein Zero-Trust-Netzwerk ist - habe ich in einem eigenen Artikel dazu auseinandergenommen. Der Punkt hier ist ein anderer: Wer aus Compose eine automatische Netzwerk-Isolation gewohnt ist, überträgt dieses Sicherheitsgefühl unbewusst auf Kubernetes - und liegt damit standardmäßig falsch.
“Monitoring für Arme” reicht in Kubernetes nicht weiter
Der dritte blinde Fleck sitzt beim Thema Gesundheit deiner Anwendung. Mit restart: always in der Compose-Datei und einem Blick auf docker ps fühlt sich das an, als hättest du die Lage im Griff. Selbst mit eingerichtetem Healthcheck zeigt dir docker ps dann brav “(unhealthy)” an - aber Docker tut von sich aus trotzdem nichts damit. Ich nenne das in Trainings “Monitoring für Arme”: Du siehst den Status, reagieren musst du selbst.
Kubernetes fasst beherzter zu, hat aber die gleiche Falle im Kleingedruckten. Ohne weiteres Zutun startet ein abstürzender Container einfach immer wieder neu - Standard-Restart-Policy, keine Diagnose, was eigentlich los war. “Selbstheilung für Arme” nenne ich das. Erst Liveness- und Readiness-Probes machen daraus einen echten Gesundheitscheck: Sie fragen aktiv nach, ob die Anwendung bereit ist, geben Traffic erst danach frei - und bei fehlgeschlagener Liveness-Probe gibt’s den gezielten Neustart. Ohne Probes hast du in Kubernetes nur die komfortablere Variante desselben Compose-Reflexes: mehr Beruhigung, nicht automatisch mehr Kontrolle.
Kurz nebeneinandergelegt, damit der Unterschied schwarz auf weiß steht:
| Frage | Docker Compose | Kubernetes |
|---|---|---|
| Netzwerk-Isolation | Eigenes Bridge-Netz pro Projekt, automatisch abgeschottet | Pod-IP kommt vom Netzwerk-Plugin, standardmäßig darf jeder Pod mit jedem sprechen - Einschränkung nur explizit über NetworkPolicy |
| “Läuft meine App wirklich?” | docker ps zeigt bestenfalls einen passiven Healthcheck-Status, reagiert aber nicht selbst | Liveness-/Readiness-Probes prüfen aktiv und steuern danach Neustart und Traffic-Routing |
| Reichweite | Ein Host | Mehrere Nodes im Cluster |
| Was übertragbar ist | Dockerfile und das daraus gebaute Container-Image | Direkt nutzbar - Netzwerk, Volumes und Monitoring darüber hinaus sind eigene Kubernetes-Konzepte |
Meine klare Ansage
Docker-Grundkenntnisse sind Gold wert für den Kubernetes-Einstieg - aber eben nur die Image-Ebene, nicht mal mehr Docker selbst als Laufzeitumgebung. Wer glaubt, mit Compose-Erfahrung schon einen Kopfstart für den Cluster-Teil zu haben, unterschätzt genau die Themen, an denen meine Teilnehmer in jedem Einführungstraining hängen bleiben: Netzwerk und Monitoring. Beides sind in Kubernetes eigene Baustellen mit eigenen Werkzeugen - nicht einfach eine größere Version dessen, was in der docker-compose.yml stand.
Wenn du diese Umstellung nicht allein im Selbststudium durchackern willst, genau dafür gibt’s mein Kubernetes-Einführungstraining - inklusive der Momente, in denen wir gemeinsam Compose-Reflexe live gegen die Wand fahren lassen, bevor sie das in Produktion tun.