Eine containerisierte Anwendung braucht eine passende Betriebsform. Docker Compose kann für einen überschaubaren produktiven Dienst ausreichen. Kubernetes wird interessant, wenn Anwendungen über mehrere Rechner verteilt und ihre Bereitstellung systematisch gesteuert werden sollen. Die Entscheidung beginnt bei den Anforderungen an die Anwendung.
Ein Unternehmen betreibt ein internes Portal mit Weboberfläche, Datenbank und Hintergrundverarbeitung. Es gibt ein Wartungsfenster, überschaubare Last und einen verantwortlichen Administrator. Ein anderes Unternehmen stellt mehrmals wöchentlich neue Versionen verschiedener Dienste bereit und muss auch während geplanter Wartungen erreichbar bleiben. Beide verwenden Container. Trotzdem können unterschiedliche Betriebsformen sinnvoll sein.
Docker, Compose und Kubernetes erfüllen verschiedene Aufgaben
Eine Container-Laufzeit führt die Container aus. Docker Engine stellt dafür eine verbreitete Plattform bereit. Docker Compose beschreibt die zusammengehörigen Dienste einer Anwendung in einer YAML-Datei. Darin lassen sich beispielsweise Images, Netzwerke, dauerhafte Volumes und Konfigurationen zusammenführen. Die Compose-Werkzeuge erstellen und verwalten diese Anwendung auf dem angesprochenen Docker-Host.
Kubernetes verwaltet dagegen einen gewünschten Zustand für Workloads in einem Cluster. Es plant Pods auf geeigneten Nodes ein und kann verwaltete Instanzen ersetzen oder schrittweise aktualisieren. Auch dort wird auf jedem Node eine geeignete Container-Laufzeit benötigt. Compose-Datei und Kubernetes-Ressourcen sind unterschiedliche Bereitstellungsbeschreibungen; ein Wechsel ist deshalb mehr als das Umbenennen einer Datei.
Die Größe eines Unternehmens entscheidet darüber wenig. Eine kleine Softwareeinheit mit häufigen Releases kann von Orchestrierung profitieren. Ein deutlich größeres Unternehmen kann für einen einzelnen unterstützten Fachanwendungsdienst mit einem gut betreuten Host auskommen.
Docker Compose ist auch für produktiven Betrieb vorgesehen
Docker dokumentiert den produktiven Einsatz von Compose ausdrücklich, insbesondere auf einem einzelnen Server. Konfigurationen für Entwicklung und Produktion können getrennt beziehungsweise gezielt ergänzt werden. Restart-Regeln, veröffentlichte Ports, Protokollierung und der Ablauf eines Updates müssen zur produktiven Umgebung passen.
Für ein internes Dokumentenportal kann das ein gut nachvollziehbarer Aufbau sein: überschaubare Dienste, dokumentierte Versionen, gesicherte Daten und ein getesteter Wiederanlauf. Der Ausfall des Hosts bleibt dabei eine gesonderte Aufgabe. Eine Neustart-Regel verschiebt die Anwendung nicht auf einen anderen Rechner. Redundanz einer darunterliegenden Virtualisierung und die Sicherung der Anwendung sind wiederum eigene Ebenen.
Entscheidend ist auch, welche Installationsform der Softwarehersteller unterstützt. Eine offiziell gepflegte Compose-Bereitstellung kann für den Betrieb wertvoller sein als eine selbst entwickelte Cluster-Installation ohne verlässlichen Updatepfad.
Die Entscheidungsmatrix für den Betrieb
| Frage | Docker Compose auf einem Host | Kubernetes |
|---|---|---|
| Wie umfangreich ist die Umgebung? | Einzelne Anwendungen mit überschaubaren Diensten sind gut abbildbar. | Mehrere Workloads und Nodes lassen sich über gemeinsame Plattformregeln verwalten. |
| Was passiert beim Host-Ausfall? | Wiederanlauf oder Infrastruktur-Redundanz wird außerhalb von Compose organisiert. | Ersatz auf anderen Nodes ist möglich, wenn Anwendung, Kapazität, Steuerung und Datenzugriff dafür vorbereitet sind. |
| Wie laufen Releases? | Ein dokumentierter, gegebenenfalls automatisierter Austausch der betroffenen Dienste. | Deployment-Regeln ermöglichen kontrollierte Rollouts. Datenänderungen und fachliche Tests bleiben gesondert zu planen. |
| Wo liegen Geschäftsdaten? | Volumes oder externe Dienste mit eigenem Sicherungs- und Restoreverfahren. | Persistente Speicher oder externe Dienste; deren Ausfallsicherheit und Sicherung bleiben zu prüfen. |
| Wer pflegt die Plattform? | Verantwortung für Host, Laufzeit, Images und Anwendung. | Zusätzlich Verantwortung für Cluster, Netzwerkintegration, Speicheranbindung und deren Lebenszyklen. |
| Wie wird der Zustand beurteilt? | Host, Dienste und Geschäftsabläufe werden überwacht. | Zusätzlich Clusterzustand und Zusammenspiel der Plattformkomponenten; ein laufender Pod allein genügt nicht. |
| Was wird vom Anbieter unterstützt? | Die freigegebene Installationsform und deren Updatepfad sind maßgeblich. | Eine betreibbare Kubernetes-Bereitstellung und passende Herstellerunterstützung müssen vorhanden sein. |
Wann Kubernetes einen konkreten Nutzen bringt
Ein tragfähiger Grund kann sein, viele ähnliche Bereitstellungen konsistent zu verwalten oder verfügbare Rechenkapazität auf mehrere Dienste zu verteilen. Auch häufige Updates mit klaren Rollout-Regeln und getrennte Verantwortungen verschiedener Anwendungsbereiche können dafür sprechen. Voraussetzung ist, dass die Anwendung mehrere Instanzen verträgt und der zusätzliche Plattformbetrieb beherrscht wird.
Vor der Auswahl muss geklärt werden, ob der Anbieter eine Steuerungsebene verwaltet, welche Komponenten selbst gepflegt werden und welche Aufgaben bei Ausfällen verbleiben. Ein verwalteter Cluster reduziert bestimmte Plattformaufgaben. Verantwortung für Anwendung, Berechtigungen, Daten und Kosten verschwindet dadurch nicht.
Ein typischer Stolperstein sind Annahmen über gemeinsam genutzte Daten: Kann die Fachanwendung mit mehreren aktiven Instanzen arbeiten? Wohin schreibt sie Dateien? Wo liegen Sitzungen? Darf ein Hintergrundauftrag erneut ausgeführt werden? Diese Fragen werden vor dem Umzug beantwortet. Ein technisch erreichbarer Container belegt noch keine funktionierende Auftragsverarbeitung.
Der Aufwand steckt im gesamten Lebenszyklus
Für einen Vergleich reichen Server- oder Cloudkosten allein nicht aus. Dazu kommen Einführung, Dokumentation, Updates, Überwachung, Sicherung und die Zeit für Störungen. Bei Kubernetes werden außerdem Plattformkenntnisse und die Abstimmung von Cluster-, Netzwerk- und Speicherkomponenten benötigt. Ein standardisierter Betrieb kann wiederkehrende Arbeit verringern; zuerst muss dieser Standard jedoch aufgebaut und gepflegt werden.
Für die Kalkulation sind drei Szenarien sinnvoll: bestehende Anwendung sauber weiterbetreiben, auf Compose vereinheitlichen oder eine Kubernetes-Plattform einführen. In jedem Szenario werden dieselben Geschäftsanforderungen angesetzt. Sonst wird leicht ein einfacher Einzelserver mit einem wesentlich höheren Verfügbarkeitsziel verglichen, ohne den Unterschied zu benennen.
So entsteht eine belastbare Entscheidung
- Betriebsziel festlegen: zulässige Unterbrechung, Wartungsfenster, Datenverlust und erwartete Änderungen beschreiben.
- Anwendung prüfen: unterstützte Installation, Mehrinstanzbetrieb, Dateien, Sitzungen und externe Schnittstellen erfassen.
- Verantwortung zuordnen: Pflege, Meldungen, Wiederherstellung und Vertretung benennen.
- Mit einem Dienst testen: Update, Ausfall und Restore im vorgesehenen Aufbau durchspielen und Aufwand dokumentieren.
- Erst danach ausweiten: weitere Anwendungen anhand derselben Kriterien übernehmen.
DAXS verbindet die Bewertung der Anwendung und ihrer Schnittstellen mit der Infrastrukturplanung und einem passenden Betriebsmodell. Für eine erste Einordnung reichen ein konkreter Dienst, seine Abhängigkeiten und die gewünschten Betriebsziele. Das persönliche Gespräch setzt dort an.
Quellen: Docker: Anwendungsmodell von Compose · Docker Compose im produktiven Betrieb · Kubernetes: Komponenten und Verantwortungsbereiche · Kubernetes: Deployments und Rollouts · Planung einer produktiven Kubernetes-Umgebung