Container-Orchestrierung

Aus Zweites Gehirn, dem persönlichen Wiki
Container-Orchestrierung
TypKonzept
QuellenQuelle - Docker Bootcamp
Quelle - Recherche - Docker heute 2026
Erstellt2026-09-27
Aktualisiert2026-09-27
Tagsdocker, container, cluster, devops, cloud

Container-Orchestrierung verteilt, startet, überwacht und skaliert Container auf einem Cluster aus vielen Rechnern. Man beschreibt nur den gewünschten Zielzustand, etwa „drei Kopien dieses Webservers“, und das System stellt ihn her und hält ihn aufrecht. Die bekanntesten Werkzeuge sind Docker Swarm und Kubernetes.

Wozu

In der Praxis bestehen Anwendungen aus Hunderten bis Tausenden Containern auf vielen physischen Servern (Quelle - Docker Bootcamp, Folie 230). Ein Orchestrierungswerkzeug liefert (Folie 231):

  • Verfügbarkeit: keine Ausfallzeit, ausgefallene Container werden ersetzt.
  • Skalierbarkeit: mehr Kopien bei mehr Last, weitere Server lassen sich nachträglich hinzufügen.
  • Absicherung gegen Infrastrukturschäden.

Beide Werkzeuge arbeiten deklarativ: Man legt den Zielzustand fest, das System versucht ihn zu erreichen (Folie 237). Das passt vor allem zu zustandslosen Microservices.

Docker Swarm

Swarm ist in Docker eingebaut, im Prinzip „Docker Compose auf mehreren Hosts“: ein Cluster aus Docker Engines (Folie 230).

  • Nodes: Alle Server heissen Nodes. Manager Nodes verteilen die Arbeit, einer davon ist der Leader (Primary Manager). Worker Nodes führen die Aufgaben aus und melden ihren Zustand (Folien 233–234).
  • Service = Beschreibung des Zielzustands (z.B. Anzahl Replicas), Task = die Arbeit, ihn herzustellen. Ein Container ist eine Instanz eines Tasks (Folie 237).
  • Routing-Mesh: Jeder Node nimmt Anfragen auf dem veröffentlichten Port an und leitet sie an irgendeine Kopie im Cluster weiter, auch wenn auf ihm selbst keine läuft. Das kostet internen Netzwerkverkehr. Mit --mode global öffnet man den Port direkt auf den Servern, muss dann aber selbst für die Lastverteilung sorgen (Folie 242).
  • Secrets: Passwörter, die viele Dienste kennen müssen, werden verschlüsselt auf dem Manager gespeichert und im Container als Datei unter /run/secrets/ bereitgestellt, im Arbeitsspeicher (RAM-Disk) (Folien 246–249).
  • Configs: Konfigurationsdateien für den Cluster, bis 500 KB, unverschlüsselt. Mit --template-driver golang können Platzhalter wie {{ .Service.Name }} oder {{ env "HALLO" }} ersetzt werden (Folien 249–251).
docker swarm init                      # Swarm mit einem Manager starten
docker node ls                         # Nodes anzeigen
docker service create --replicas 3 -p 8080:80 nginx
docker service ls | ps | update | rm
printf "geheim" | docker secret create top_secret -
docker service create --secret top_secret php:8.1-apache
docker swarm leave --force

Ein echtes Cluster: Der Autor baut eines aus drei Raspberry Pi. Wichtig: alle Rechner unter Linux, im selben Netzwerk, mit Zugriff auf dieselben Images, möglichst stabile Verbindung (Ethernet), feste IP-Adressen für die Manager (Folien 254–255).

Kubernetes

Der mächtigere Standard, beschrieben in Kubernetes: Pods, Deployments, Services, Control Plane.

Docker Swarm Kubernetes
Bedienung in die Docker-CLI integriert eigenes Werkzeug kubectl
Oberfläche Zusatzwerkzeug nötig (z.B. Portainer) Dashboard integriert
Lastverteilung automatisch vieles manuell konfigurierbar
Auto-Scaling nur manuell ja
Einrichtung einfach aufwendig, meist vom Cloud-Anbieter bereitgestellt
Verbreitung klein Standard, grössere Gemeinschaft

(Folien 270–271)

Stand 2026

Swarm wird weiterhin mit jeder Docker Engine ausgeliefert und gepflegt, wächst aber kaum noch. Mirantis sichert Unterstützung „mindestens bis 2030“ zu (Juli 2025). Laut einem Fachblog wurde das später vorsichtiger formuliert, das späteste dokumentierte Support-Ende einer Swarm-fähigen Mirantis-Version ist März 2028 (Quelle - Recherche - Docker heute 2026).

Einordnung (Claude)

Orchestrierung setzt Grundsätze aus dem Business Continuity Planning technisch um: Redundanz (mehrere Kopien, mehrere Manager), automatischer Wiederanlauf und Verteilung auf mehrere Standorte. Secrets sind die Antwort auf das Problem, dass Passwörter in Umgebungsvariablen und Images sichtbar bleiben (siehe Dockerfile, Zugriffskontrolle). Für kleine Umgebungen, etwa zu Hause, ist Swarm oft genug, Kubernetes lohnt sich erst mit vielen Diensten.

Verwandt