Docker Compose vs Kubernetes: Wann wechseln?

Sie haben gerade den fünften oder sechsten Dienst zu Ihrer docker-compose.yml hinzugefügt, jemand in einem Forum hat Ihnen gesagt, "so macht man das in Produktion nicht", und jetzt starren Sie auf ein Kubernetes-Tutorial und fragen sich, ob Ihr Homelab irgendwie falsch aufgebaut ist. Ist es nicht. Ein Team betreibt 500.000 Logeinträge pro Tag auf reinem Docker Compose; ein anderes wechselte zu Kubernetes, spürte den Schmerz und kehrte zurück — und sparte dabei 60 Stunden pro Monat. Die eigentliche Frage ist nicht "welches Tool ist professioneller". Sie ist, ob die operativen Kosten, Kubernetes nicht zu haben, inzwischen die Kosten seines Betriebs übersteigen.

TL;DR

Docker Compose betreibt einen einzelnen Host sehr gut. Es kann nicht über mehrere Maschinen hinweg planen, hat kein Cross-Node-Self-Healing und ein schwaches Secrets-Handling — aber die meisten Homelabs stoßen nie an diese Grenzen.
Die echten Graduierungssignale sind numerisch: etwa 20–30 Container auf einer Box, der Bedarf, 2+ Hosts als ein System zu planen, oder Uptime-Garantien, die niemand mehr manuell nachstellt.
K3s — eine einzelne Binärdatei unter 100 MB — ist der Mittelschritt, den fast jeder Vergleichsartikel auslässt, und dort sollten die meisten Homelabber landen, bevor (oder statt) sie auf vollständiges Kubernetes wechseln.
Ein Umzug ist kein Suchen-und-Ersetzen: Compose-Dateien übersetzen sich nicht 1:1 in Kubernetes-Manifeste, und man erbt neue Fehlermodi (CrashLoopBackOff, unbound PVCs) zusammen mit den neuen Funktionen.
Mein eigenes Homelab läuft weiterhin zu 100 % auf Compose, und die Checkliste unten ist die tatsächliche Trigger-Liste, die ich beobachte, bevor sich das ändert.

Was Docker Compose tatsächlich bietet

Docker Compose spricht mit einem einzelnen Docker-Daemon und liest eine YAML-Datei, die jeden Dienst, jedes Netzwerk und jedes Volume Ihres Stacks definiert. docker compose up -d ausführen, und es läuft — keine Control-Plane, kein Cluster zum Hochfahren, nichts weiter zu lernen. Diese Einfachheit ist das gesamte Feature, keine Einschränkung, für die man sich entschuldigen müsste.

Es ist zudem deutlich leistungsfähiger als der Stereotyp vermuten lässt. Wie in unserem Leitfaden zu Docker Compose für Self-Hosting beschrieben, decken Restart-Policies, Health-Checks und benannte Volumes das meiste ab, was ein Single-Host-Homelab oder ein kleiner Produktionsdienst im Alltag tatsächlich braucht.

Hinweis

Compose kann einen abgestürzten Container weiterhin automatisch neu starten (restart: unless-stopped) — was es nicht kann, ist zu bemerken, dass der gesamte Host gestorben ist, und den Container anderswo neu zu planen. Dieser Unterschied ist der ganze Vergleich in einem Satz.

Was Kubernetes tatsächlich hinzufügt

Kubernetes plant Container über eine Flotte von Maschinen statt über eine einzige. Stirbt ein Node, werden die betroffenen Pods automatisch auf einen gesunden Node umgeplant — Self-Healing auf Maschinen-Ebene, nicht nur auf Container-Ebene. Es bietet außerdem Rolling Updates mit echten Health-Gates, native Secrets-Verwaltung und horizontales Autoscaling, ausgelöst durch tatsächliche Last.

Nichts davon ist kostenlos. Sie betreiben (und patchen) jetzt eine Control-Plane, lernen eine deutlich größere API-Oberfläche und pflegen YAML, das tendenziell über viele kleine Dateien verstreut ist statt in einem lesbaren Compose-Block.

	Docker Compose	Kubernetes
Orchestrierungsumfang	Einzelner Host	Mehrere Nodes als ein Cluster
Self-Healing	Startet abgestürzten Container auf demselben Host neu	Plant auf einen anderen gesunden Node um
Rolling Updates	Manuell oder um `up -d` herum skriptet	Nativ, mit konfigurierbaren Health-Checks
Secrets-Verwaltung	`.env`-Dateien / Docker Secrets (einfach)	Native Secrets-API, Integration externer Vaults
Autoscaling	Keines	Horizontal Pod Autoscaler
Lernkurve	Minuten	Tage bis Wochen für echte Kompetenz
Ressourcen-Overhead	Nahezu null	Eine Control-Plane, selbst auf einem einzelnen Node

Die echten Graduierungssignale (keine Feature-Liste)

Jeder Vergleichsartikel hört bei dieser Tabelle auf. Sie ist richtig und trotzdem nutzlos für eine Entscheidung, weil sie nie sagt, wann diese Funktionen für Ihr konkretes Setup relevant werden. Hier die Checkliste, die ich tatsächlich verwende:

Signal	Docker Compose reicht noch	Zeit für Kubernetes / K3s
Container-Zahl, ein Host	Unter ~20–30	Konstant darüber auf einer einzelnen Box
Host-/Node-Zahl	1	2+, und Sie SSHen zwischen ihnen, um zu deployen
Uptime-Anforderung	Privatprojekt, "neu starten, wenn ich es merke"	Jemand anderes hängt wirklich davon ab, dass es läuft
Team-Größe	Allein oder eine weitere Person	Eine dedizierte Ops-Funktion, auch Teilzeit
Deploy-Frequenz über Hosts	Selten, manuell ist okay	So häufig, dass manuelle Koordination fehleranfällig wird

Manche Praxisberichte setzen die "das brauchst du wirklich"-Grenze noch höher: 10+ Dienste, die wirklich unabhängige Skalierung brauchen, 500K+ täglich aktive Nutzer und ein dediziertes Zwei-Ingenieure-Ops-Team, bevor sich der Overhead von Kubernetes in einem Business-Kontext überhaupt rechnet. Ein Homelab wird diese Schwelle fast nie erreichen — aber die Form der Entscheidung (Node-Zahl und wer Bereitschaftsdienst hat) ist auf jeder Skala identisch.

Warnung

Der häufigste Fehler ist, allein aus Lebenslauf-Gründen umzuziehen. Kubernetes auf einem einzelnen Node bringt Control-Plane-Overhead und eine steilere Fehlermodus-Lernkurve mit keinem der Multi-Node-Vorteile, die das rechtfertigen würden. Haben Sie eine Box, ist Compose (oder K3s im Single-Node-Modus, siehe unten) die bessere Wahl — unabhängig davon, was in einer Stellenanzeige steht.

Der Mittelschritt, den fast jeder Guide auslässt: K3s

Fast jeder Compose-vs-Kubernetes-Artikel stellt das als binäre Wahl dar. In der Praxis springen die meisten Homelabber, die Compose hinter sich lassen, nicht direkt zum vollständigen Upstream-Kubernetes — sie gehen zu K3s, einer CNCF-zertifizierten Kubernetes-Distribution, die als einzelne Binärdatei unter 100 MB ausgeliefert wird und komfortabel auf einem 1-GB-RAM-Node läuft, wobei SQLite bei kleinen Clustern für etcd einspringt.

K3s gibt Ihnen echte Kubernetes-APIs — dieselben kubectl-Befehle, dieselben Manifeste, übertragbare Skills — ohne zuerst einen vollständigen Multi-Node-etcd-Cluster aufsetzen zu müssen. Sie können K3s auf einem einzelnen Node starten (durchaus vergleichbar mit dem Betrieb von Compose) und später Nodes hinzufügen, ohne irgendetwas neu zu architektieren. Community-Berichte von Homelabbern, die diesen Schritt gegangen sind, landen konsequent bei K3s statt bei Stock-Kubernetes als praktischem Einstiegspunkt — und es lohnt sich auch, K3s mit Docker Swarm zu vergleichen, da Swarm eine leichtere — wenn auch weniger aktiv weiterentwickelte — dritte Option für Multi-Host-Compose-ähnliche Deployments ist.

Tipp

Wechseln Sie vor allem, um Kubernetes zu lernen, und nicht, um ein echtes Multi-Node-Problem zu lösen, starten Sie K3s auf einer einzelnen Ersatzmaschine (sogar einem Raspberry Pi), bevor Sie Ihren Produktionsstack anfassen. Sie bekommen die echten APIs ohne jedes Migrationsrisiko.

Mein eigenes Homelab: warum ich bei Compose bleibe

Meine Proxmox-Box betreibt etwa ein Dutzend containerisierte Dienste — Jellyfin, ein paar *arr-Apps, Tailscale, einen Reverse-Proxy — alles über Compose-Dateien, organisiert so, wie ich es im Compose-Leitfaden für Self-Hosting beschreibe. Das liegt komfortabel unter der ~20–30-Container-Grenze von oben, auf einem Host, und niemand außer mir hängt von der Uptime ab.

KEY-STAT: 12 — Container, die aktuell auf meinem Homelab-Docker-Compose-Stack laufen, deutlich unter der ~20–30er-Grenze, ab der Compose unübersichtlich wird (eigenes Homelab)

Der Trigger, der mich tatsächlich zum Wechsel bewegen würde, ist kein fehlendes Feature — es ist das Hinzufügen einer zweiten physischen Box für Redundanz. In dem Moment, in dem ich zwei Maschinen als ein System behandeln möchte, hört docker compose up auf jeder von ihnen separat auf, eine Abkürzung zu sein, und wird zu einem Risiko — und das ist der Punkt, an dem K3s auf die Liste kommt. Bis dahin würde ein Umzug ein System, das ich vollständig verstehe, gegen eines eintauschen, das ich unter Druck erst lernen müsste — ein schlechter Tausch für ein Homelab, bei dem mich nachts niemand anpiept.

Was ein Umzug tatsächlich kostet

Compose-Dateien übersetzen sich nicht eins zu eins in Kubernetes-Manifeste. Ein docker-compose.yml-Dienst wird zu einem Deployment, einem Service und oft einem ConfigMap oder Secret — mehr Dateien, mehr Indirektion und Netzwerk-Annahmen, die sich nicht nahtlos übertragen (die automatische Service-Name-DNS von Compose ist nicht identisch mit der Service-Discovery von Kubernetes). Ingress ersetzt, was auch immer Ihr Reverse-Proxy-Setup war — von der VM-/Container-Auswahlseite her beschrieben in unserem Vergleich Docker vs. virtuelle Maschinen.

Sie erben außerdem neue Fehlermodi, die es in Compose überhaupt nicht gibt — ein Pod, der in CrashLoopBackOff feststeckt, eine PersistentVolumeClaim, die nie bindet, ein Service ohne passende Endpoints. Keiner davon ist schwierig, sobald man ihn einmal gesehen hat, aber planen Sie beim ersten Mal jeweils einen Abend ein, nicht fünfzehn Minuten. Wenn Sie grundsätzlich noch zwischen Containern und vollen VMs für einen bestimmten Dienst entscheiden, deckt unser Vergleich Proxmox vs. Docker diese frühere Weggabelung im Entscheidungsbaum ab.

Häufig gestellte Fragen

Ist Kubernetes für ein Homelab übertrieben?

Für einen einzelnen Host: ja, fast immer. Der Kernwert von Kubernetes liegt im Scheduling und Self-Healing über mehrere Maschinen hinweg — auf einem Node zahlen Sie den Control-Plane-Overhead ohne den Multi-Node-Nutzen. K3s im Single-Node-Modus ist eine vernünftige Ausnahme, wenn Sie bewusst die APIs lernen wollen.

Kann Docker Compose in Produktion laufen?

Ja. Teams betreiben Compose in Produktion mit zehntausenden Nutzern und hunderttausenden Logzeilen pro Tag. Es ist eine legitime Produktionswahl für Single-Host-Workloads, nicht nur ein lokales Entwickler-Tool.

Was ist der Unterschied zwischen Docker Compose und Kubernetes?

Compose orchestriert Container auf einem einzigen Docker-Host anhand einer YAML-Datei. Kubernetes orchestriert Container über einen Cluster von Maschinen hinweg und bietet Cross-Node-Self-Healing, native Secrets, Rolling Updates mit Health-Gates und Autoscaling — zum Preis einer Control-Plane und einer deutlich größeren Lernkurve.

Sollte man zuerst Kubernetes oder Docker Compose lernen?

Compose zuerst. Es vermittelt die Kernkonzepte von Containern (Images, Netzwerke, Volumes) mit fast keinem Ballast. Die zusätzlichen Konzepte von Kubernetes — Pods, Services, Deployments, Ingress — ergeben weit mehr Sinn, wenn man bereits versteht, was Compose darunter eigentlich tut.

Was ist K3s und wie unterscheidet es sich von Kubernetes?

K3s ist eine CNCF-zertifizierte, leichtgewichtige Kubernetes-Distribution: dieselben APIs und Manifeste wie Upstream-Kubernetes, verpackt in eine einzelne Binärdatei unter 100 MB, wobei SQLite etcd für kleine Cluster ersetzt. Es ist speziell für Edge-, IoT- und Homelab-Hardware gebaut.

Wie viele Container kann Docker Compose verwalten?

Es gibt keine feste Obergrenze, aber die praktische Grenze für einen Host liegt bei etwa 20–30 Containern, bevor die Verwaltung (und die Ressourcen des Hosts selbst) unübersichtlich werden — die Zahl hängt weit mehr davon ab, was jeder Container tut, als von Compose selbst.

Fazit

Compose ist kein Zwischenschritt, für den man sich schämen müsste — es ist das richtige Werkzeug für einen Host, und es bleibt richtig weit über den Punkt hinaus, an dem die meisten Homelabs jemals wachsen. Beobachten Sie die tatsächlichen Signale (Container-Zahl, Node-Zahl, wer von der Uptime abhängt) statt einer Feature-Checkliste, und wenn der Tag kommt, landen Sie bei K3s, bevor Sie annehmen, den vollen Kubernetes-Stack zu brauchen. Es sind dieselben APIs, ein Bruchteil des Overheads und — gemäß dem Compose-Pillar-Guide und seinem Begleitartikel down vs. stop vs. kill — ein deutlich kleinerer Schritt von dort, wo Sie bereits stehen, als ein direkter Sprung zum Upstream-Kubernetes es wäre.