Was ist Container-Orchestrierung?

Der Soll-Zustand wird beschrieben, nicht gestartet

Statt einzelne Startbefehle abzusetzen, legst du in einer Datei fest, was gelten soll: drei Kopien dieses Dienstes, dieses Image, so viel Arbeitsspeicher, erreichbar unter diesem Namen. Die Steuerungsebene vergleicht diesen Wunschzustand laufend mit der Wirklichkeit und gleicht Abweichungen selbst aus. Löscht jemand versehentlich eine Instanz, ist sie Sekunden später wieder da.

Dieses ständige Nachregeln ist der eigentliche Unterschied zu einem Skript, das Container startet. Ein Skript läuft einmal, eine Orchestrierung läuft immer. Deshalb reicht es auch nicht, eine Anwendung einmal auszurollen: Sie muss selbst melden können, ob sie betriebsbereit ist, sonst weiß die Plattform nicht, was sie reparieren soll.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels: {app: shop}
  template:
    metadata:
      labels: {app: shop}
    spec:
      containers:
      - name: shop
        image: registry.example.com/shop:1.4.2
        resources:
          requests: {cpu: 250m, memory: 256Mi}
          limits: {memory: 512Mi}
        readinessProbe:
          httpGet: {path: /health, port: 8080}

So sieht ein Soll-Zustand in Kubernetes aus. Die Datei sagt nicht, auf welchem Rechner die drei Kopien laufen, sondern nur, dass es drei sein sollen, mit welchem Image, wie viel Ressourcen jede braucht und woran die Plattform erkennt, dass eine Kopie Anfragen annehmen kann. Den Rest erledigt der Cluster.

Die Bausteine am Beispiel Kubernetes

Kubernetes ist der verbreitetste Orchestrator und hat die Begriffe geprägt, die auch andere Plattformen verwenden. Wer diese fünf kennt, kann fast jede Architekturskizze lesen.

• Control Plane

  Die Steuerungsebene mit API-Server, Scheduler und der Datenbank etcd, in der der gewünschte Zustand des ganzen Clusters liegt.

• Node

  Ein Arbeitsrechner, physisch oder virtuell, auf dem der Agent kubelet die zugewiesenen Container über eine Container-Laufzeit wie containerd startet.

• Pod

  Die kleinste Einheit, die Kubernetes verteilt: ein oder mehrere Container, die sich Netzwerkadresse und Speicher teilen.

• Deployment

  Beschreibt, wie viele Kopien eines Pods laufen sollen und in welcher Version, und sorgt bei Updates für den schrittweisen Austausch.

• Service

  Ein fester interner Name mit stabiler Adresse, hinter dem sich die wechselnden Pods verbergen, samt einfacher Lastverteilung.

Verteilung, Selbstheilung und Skalierung im Betrieb

Der Scheduler sucht für jeden neuen Pod einen Knoten, der genug freie Ressourcen hat und die geforderten Bedingungen erfüllt, etwa eine bestimmte Region oder einen Knoten mit Grafikkarte. Fällt ein Knoten aus, verteilt die Plattform die betroffenen Instanzen auf die übrigen. Bei Lastspitzen kommen zusätzliche Kopien hinzu und verschwinden wieder, wenn die Last sinkt.

Neue Versionen rollen schrittweise aus: Erst wird eine Instanz getauscht und geprüft, dann die nächste. Meldet die neue Version sich nicht als bereit, stoppt der Vorgang, statt die ganze Anwendung mitzureißen, und die alte Version läuft weiter.

Kubernetes und die Alternativen

Kubernetes ist Open Source und wird von der Cloud Native Computing Foundation betreut. In Unternehmen läuft es selten pur, sondern als Distribution mit zusätzlicher Verwaltung, etwa Red Hat OpenShift oder Rancher, oder als verwalteter Dienst der großen Cloud-Anbieter wie Amazon EKS, Azure Kubernetes Service und Google Kubernetes Engine. Dort betreibt der Anbieter die Steuerungsebene, du kümmerst dich um die Knoten und die Anwendungen.

Daneben gibt es schlankere Orchestratoren. Docker Swarm ist in Docker eingebaut und für kleine Umgebungen schnell eingerichtet, HashiCorp Nomad verteilt neben Containern auch gewöhnliche Programme. Für einen einzelnen Rechner ist Docker Compose oder Podman mit systemd oft genug, auch wenn das streng genommen keine Orchestrierung über mehrere Knoten ist.