Docker und Kubernetes: Wann was einsetzen?

Die Kubernetes-Falle

Es gibt einen verbreiteten Fehler in der DACH-Startup-Szene: Teams migrieren zu Kubernetes, bevor sie es brauchen. Ein Drei-Personen-Team, das seine NestJS-API und PostgreSQL-Datenbank auf einem einzelnen Server betreibt, braucht keinen Kubernetes-Cluster. Was es braucht, ist Docker Compose und ein solides Deployment-Script.

Kubernetes löst reale Probleme — aber erst ab einer bestimmten Größe. Davor verursacht es mehr Komplexität als es beseitigt.

Docker Compose: Die unterschätzte Lösung

Docker Compose orchestriert Container auf einem einzelnen Host. Das klingt limitiert, reicht aber für erstaunlich viele Anwendungen.

Was Docker Compose kann:

• Mehrere Services definieren (API, Datenbank, Redis, Worker)
• Netzwerk-Isolation zwischen Services
• Volume-Management für persistente Daten
• Health Checks und Restart Policies
• Environment-Variablen und Secrets

Was Docker Compose nicht kann:

• Automatisches Failover auf andere Hosts
• Horizontale Skalierung über mehrere Server
• Rolling Deployments ohne Downtime (nur mit Tricks)
• Service Discovery über Cluster-Grenzen

Wann Docker Compose reicht

• Team < 10 Entwickler
• Weniger als 50.000 aktive Nutzer
• Ein bis drei Backend-Services
• Traffic-Spitzen sind vorhersehbar
• Downtime von 30 Sekunden beim Deployment akzeptabel

Der Mittelweg: Coolify und Dokku

Zwischen Docker Compose und Kubernetes gibt es eine Kategorie, die oft übersehen wird: Self-Hosted PaaS.

Coolify

Open-Source Alternative zu Vercel/Netlify/Heroku. Installiert auf Ihrem eigenen Server.

Features:

• Git-Push Deployments (wie Heroku)
• Automatische SSL-Zertifikate
• Datenbank-Provisioning (PostgreSQL, MySQL, Redis)
• Docker Compose Support
• Multi-Server Management
• Monitoring und Log-Ansicht

Ideal für: Teams, die Heroku-Komfort wollen, aber auf eigenem Server (Hetzner) bleiben möchten. DSGVO-konform, da alles Self-Hosted.

Dokku

Minimales PaaS, inspiriert von Heroku. Läuft auf einem einzelnen Server.

Features:

• Git-Push Deployments (Buildpacks oder Dockerfile)
• Plugin-System (PostgreSQL, Redis, Let's Encrypt)
• Zero-Downtime Deployments
• Einfaches Scaling (Prozesse pro Dyno-Typ)

Ideal für: Entwickler, die Heroku kennen und eine schlanke Alternative suchen.

Wann wird Kubernetes nötig?

Kubernetes wird relevant, wenn Docker Compose an seine Grenzen stößt:

• Mehr als ein Server nötig — Traffic oder Rechenleistung übersteigt einen einzelnen Host
• Zero-Downtime Deployments sind geschäftskritisch — z.B. bei Finanz- oder Gesundheits-SaaS
• Microservices-Architektur — mehr als 5-8 unabhängige Services
• Auto-Scaling bei unvorhersehbaren Lastspitzen — z.B. Event-getriebene Plattformen
• Enterprise-Kunden verlangen es — Compliance-Anforderungen, SLAs > 99,99%

Managed Kubernetes im Vergleich

Anbieter	Min. Kosten/Mo	Region	Besonderheiten
Hetzner K3s	~€30 (3 Nodes)	DE	Günstigste Option, K3s statt K8s
DigitalOcean DOKS	~€36 (3 Nodes)	Frankfurt	Einfachstes Setup, Free Control Plane
AWS EKS	~€150+	Frankfurt	Enterprise-Grade, teurer
GKE (Google)	~€100+	EU	Bestes K8s-Erlebnis, Autopilot-Modus
Azure AKS	~€100+	West Europe	Gut für Microsoft-Ökosystem

Deployment-Strategien

Rolling Deployment

Alte Pods werden schrittweise durch neue ersetzt. Standard in Kubernetes. Pro: Einfach, kein zusätzlicher Ressourcenbedarf. Contra: Kurze Phase mit zwei Versionen gleichzeitig.

Blue-Green Deployment

Zwei identische Umgebungen. Traffic wird von Blue (alt) auf Green (neu) umgeschaltet. Pro: Sofortiges Rollback möglich. Contra: Doppelte Infrastrukturkosten während des Deployments.

Canary Deployment

Neue Version bekommt zunächst nur einen kleinen Prozentsatz des Traffics (z.B. 5%). Pro: Risiko minimiert, Probleme früh erkennbar. Contra: Komplexeres Setup, braucht Traffic-Splitting.

Empfehlung: Rolling Deployment für die meisten Teams. Canary nur, wenn Sie > 100.000 aktive Nutzer haben und ein Release wirklich nicht schiefgehen darf.

Der Wachstumspfad

Die meisten DACH-SaaS-Unternehmen durchlaufen diese Phasen:

Team-Größe und Infrastruktur

Die Infrastrukturkomplexität sollte zur Teamgröße passen:

• 1-3 Entwickler: Docker Compose, allenfalls Coolify. Kein K8s.
• 4-8 Entwickler: Coolify/Dokku oder K3s, wenn Multi-Server nötig.
• 8-15 Entwickler: Managed K8s sinnvoll, dedizierter DevOps-Engineer.
• 15+ Entwickler: Full K8s mit GitOps (ArgoCD/Flux), Platform Team.

Wer die DevOps-Kapazität nicht intern aufbauen will, kann das als Teil eines Subscription-Development-Modells lösen: ein externes Team, das die Infrastruktur von Docker Compose bis Kubernetes mitentwickelt und bei Bedarf skaliert.

Häufige Fehler

1. K8s zu früh einführen — Der häufigste Fehler. Verbrennt 3-6 Monate Entwicklungszeit.
2. Kein Health Check — Ohne Health Checks kann Docker/K8s keine Container neustarten.
3. Stateful Workloads in K8s — Datenbanken gehören auf Managed Services oder dedizierte Server, nicht in Pods.
4. Keine Resource Limits — Ein Container ohne Memory-Limit kann den ganzen Node crashen.
5. Secrets in Docker Images — Secrets gehören in Environment-Variablen oder Secret-Manager, nie ins Image.

Fazit: Pragmatisch bleiben

Docker Compose ist kein Anfänger-Tool. Es ist die richtige Lösung für die meisten SaaS-Anwendungen bis zu einer signifikanten Nutzerbasis. Kubernetes ist kein Upgrade — es ist ein anderes Tool für andere Probleme.

Die Faustregel: Wenn Sie sich fragen, ob Sie Kubernetes brauchen, brauchen Sie es wahrscheinlich noch nicht. Wenn Sie es brauchen, werden Sie es wissen — weil Docker Compose an einer konkreten, spürbaren Grenze stößt.

Starten Sie mit Docker Compose auf Hetzner. Wenn der Moment kommt, migrieren Sie zu K3s. Und wenn Enterprise-Anforderungen es verlangen, steigen Sie auf Managed K8s um. Jede Phase hat ihre Berechtigung.

---

Verwandte Themen

• CI/CD Pipeline für SaaS-Startups
• Hosting DE: Hetzner vs AWS vs Vercel
• Monitoring und Observability für SaaS
• Infrastructure as Code
• Cloud & DevOps als Subscription