3 Min. Lesezeit
Das Wichtigste in Kürze
- Kubernetes ist der Standard für Container-Orchestrierung – aber nicht immer die beste Wahl.
- Docker Swarm bietet 80% der Features bei 20% der Komplexität für kleine bis mittlere Teams.
- HashiCorp Nomad orchestriert Container, VMs und Batch-Jobs mit einer einzigen Plattform.
- AWS ECS und Google Cloud Run eliminieren Cluster-Management komplett als Managed Services.
- Die Wahl hängt von Team-Größe, Workload-Typ und Ops-Kapazität ab – nicht von Hype.
Kubernetes hat den Container-Orchestrierung-Markt gewonnen. Aber Marktdominanz bedeutet nicht, dass es für jeden Anwendungsfall die richtige Wahl ist. Für ein Team von fünf Entwicklern mit zehn Services ist Kubernetes oft Overkill – mit einer Lernkurve, die Wochen verschlingt, und einer operativen Komplexität, die ein halbes Ops-Team bindet. Es gibt Alternativen.
Das Kubernetes-Dilemma: Mächtig, aber komplex
Kubernetes kann praktisch alles: Rolling Deployments, Auto-Scaling, Service Discovery, Secret Management, Network Policies, Custom Resource Definitions. Diese Mächtigkeit hat ihren Preis: Ein produktionsreifer Kubernetes-Cluster erfordert Verständnis von Networking (CNI-Plugins, Ingress Controller), Storage (CSI, PersistentVolumes), Security (RBAC, NetworkPolicies, PodSecurityStandards) und Monitoring (Prometheus, Grafana, Alertmanager).
Für ein Platform-Team mit 3+ Kubernetes-erfahrenen Engineers ist das managbar. Für ein kleines Team, das nebenbei auch Features bauen muss, ist es ein Ressourcen-Killer. Die Frage sollte nicht „Können wir Kubernetes?“ sein, sondern „Brauchen wir Kubernetes?“
Docker Swarm: Die pragmatische Alternative
Docker Swarm ist in Docker integriert, braucht kein separates Tool und ist in 15 Minuten eingerichtet. Ein Swarm-Cluster unterstützt Rolling Updates, Service Discovery, Load Balancing und Secret Management – die Features, die 80% der Teams brauchen.
Die Grenzen: Kein Auto-Scaling (manuell oder per Script), kein Ingress-Controller (Traefik oder Nginx als Workaround), begrenzte Community und Ökosystem. Docker hat die Swarm-Entwicklung de facto eingestellt – es funktioniert, wird aber nicht mehr aktiv weiterentwickelt.
Für wen: Teams mit 3-20 Services, die Container-Orchestrierung brauchen, aber nicht die Kubernetes-Komplexität rechtfertigen können. Oft als Einstieg, bevor man perspektivisch auf Kubernetes migriert.
HashiCorp Nomad: Der Generalist
Nomad orchestriert nicht nur Container, sondern auch VMs, Java-Anwendungen und Batch-Jobs. Das macht es zur einzigen Alternative, die heterogene Workloads nativ unterstützt. Die Architektur ist einfacher als Kubernetes: Ein Nomad-Cluster besteht aus Servern und Clients – keine etcd-Cluster, keine API-Server-Konfiguration, keine CNI-Plugins.
Nomad integriert sich nahtlos mit dem HashiCorp-Ökosystem: Consul für Service Discovery, Vault für Secret Management, Terraform für Infrastruktur. Für Unternehmen, die bereits HashiCorp-Tools nutzen, ist Nomad die natürliche Wahl.
Die Einschränkung: Das Ökosystem ist kleiner als Kubernetes. Weniger Third-Party-Integrationen, weniger Community-Support, weniger Engineers mit Nomad-Erfahrung auf dem Arbeitsmarkt.
Managed Services: Kein Cluster, kein Problem
AWS ECS (Elastic Container Service) ist Amazons eigener Container-Orchestrator – voll integriert in das AWS-Ökosystem, einfacher als EKS (Kubernetes). Mit Fargate als Compute-Backend entfällt sogar das Cluster-Management komplett: Man definiert Tasks und Services, AWS kümmert sich um die Infrastruktur.
Google Cloud Run geht noch einen Schritt weiter: Container deployen per Knopfdruck, automatisches Scaling (inklusive auf null), Pay-per-Request. Für HTTP-basierte Workloads ohne komplexe Service-zu-Service-Kommunikation ist Cloud Run die einfachste Option am Markt.
Azure Container Apps positioniert sich ähnlich wie Cloud Run: Serverless Container mit KEDA-basiertem Auto-Scaling und Dapr-Integration für Microservices-Patterns.
Entscheidungsmatrix: Welches Tool für welchen Kontext
Kubernetes wenn: > 50 Services, Multi-Cloud-Requirement, großes Platform-Team, komplexes Networking, Custom Controllers nötig.
Docker Swarm wenn: Kleines Team (< 5 Devs), < 20 Services, schneller Einstieg, On-Premise, keine Kubernetes-Expertise.
Nomad wenn: Heterogene Workloads (Container + VMs + Batch), HashiCorp-Stack im Einsatz, Wunsch nach Einfachheit bei Enterprise-Anforderungen.
ECS/Cloud Run wenn: AWS/GCP-native, Team will sich auf Code fokussieren statt auf Infrastruktur, HTTP-basierte Services, kein Multi-Cloud.
Häufige Fragen
Ist Docker Swarm tot?
Nicht tot, aber im Wartungsmodus. Docker fokussiert auf Docker Desktop und Docker Hub. Swarm funktioniert stabil, erhält aber keine neuen Features. Für bestehende Setups ist das kein Problem. Für neue Projekte sollte man die langfristige Perspektive berücksichtigen.
Kann man von Docker Swarm zu Kubernetes migrieren?
Ja, und es ist einfacher als von VM-basierten Setups. Die Container-Images sind identisch. Docker-Compose-Files lassen sich mit kompose in Kubernetes-Manifeste konvertieren. Die Migration betrifft primär Networking, Storage und Deployment-Konfiguration.
Ist ECS günstiger als EKS?
ECS selbst ist kostenlos – man zahlt nur für die Compute-Ressourcen (EC2 oder Fargate). EKS hat eine Cluster-Gebühr von 0,10 USD/Stunde (~73 USD/Monat) plus Compute. Für kleine Setups ist ECS günstiger. Bei größeren Setups relativiert sich der Unterschied.
Warum nutzen nicht alle Google Cloud Run?
Cloud Run ist optimal für Request-basierte Workloads (APIs, Websites). Für Workloads mit persistenten Verbindungen (WebSockets, Streaming), komplexem Service Mesh oder spezifischen Networking-Anforderungen ist Kubernetes die bessere Wahl. Cloud Run abstrahiert zu viel für diese Use Cases.
Brauchen wir Container-Orchestrierung überhaupt?
Nicht unbedingt. Für eine Handvoll Services reicht oft ein einfacher Server mit Docker Compose und einem Reverse Proxy. Container-Orchestrierung wird relevant ab 10+ Services, wenn Rolling Deployments, Auto-Scaling und Service Discovery benötigt werden.
Quelle des Titelbildes: Pexels / Jan van der Wolf
Lesetipps der Redaktion
- Lenovo ThinkCentre M75q Tiny Gen 5: Enterprise-Mini-PC mit AMD PRO und 5 Watt Idle für Edge und Kiosk
- Serverless KI ist überbewertet – hier ist was stattdessen zählt
- QNAP TS-464: 4-Bay-NAS mit Docker, HDMI und PCIe-Slot – was Synology in dieser Klasse nicht bietet
