Container und Orchestrierung mit Kubernetes

Images, Layer und Registrys

Kapitel 0 hat Container als isolierte Prozesse eingeführt, die sich den Kernel des Hosts teilen und als Images aus einem Dockerfile gebaut werden (Server und die Cloud). Ein Architekt braucht etwas mehr Detail, denn das Image-Design beeinflusst Build-Geschwindigkeit, Sicherheit und wie zuverlässig dieselbe Software jede Umgebung erreicht.

Ein Container-Image ist ein Stapel schreibgeschützter Layer, jeder eine komprimierte Menge von Dateiänderungen, plus ein kleines Konfigurationsdokument (der auszuführende Befehl, Umgebungsvariablen, der Benutzer) und ein Manifest, das sie auflistet. Jeder Layer und jedes Manifest wird durch einen Digest identifiziert, einen SHA-256-Hash seines Inhalts. Identische Layer werden nur einmal gespeichert und heruntergeladen, sodass hundert Images auf derselben Basis deren Layer teilen. Weil jede Anweisung in einem Dockerfile einen Layer erzeugt und Builder zwischengespeicherte Layer wiederverwenden, bis sich etwas ändert, ordnet man die Anweisungen von selten zu häufig geändert: Basis-Image, dann Abhängigkeiten, dann Anwendungscode. Multi-Stage-Builds kompilieren in einer Stufe und kopieren nur das Ergebnis in ein kleines finales Image; Compiler und Build-Werkzeuge bleiben zurück.

Images liegen in einer Registry: Docker Hub, GitHub Container Registry, Amazon ECR, Azure Container Registry, Google Artifact Registry oder eine selbst betriebene wie Harbor. Ein Tag wie orders:2.4.1 ist ein verschiebbares Etikett; wer Push-Rechte hat, kann es morgen auf ein anderes Image zeigen lassen. Ein Digest wie orders@sha256:3f1c... kann seine Bedeutung nie ändern. Produktions-Deployments sollten Tags deshalb in Digests auflösen, damit genau das läuft, was getestet wurde, und nie latest verwenden.

Kleine Images sind schneller heruntergeladen und haben weniger Komponenten, die gepatcht werden müssen. Übliche Praxis ist eine minimale Basis (eine schlanke Distribution oder ein Distroless-Image, das nur die Laufzeitumgebung enthält), die Ausführung als Nicht-Root-Benutzer, regelmäßiges Neubauen, um Sicherheitskorrekturen aufzunehmen, und das Scannen der Images auf bekannte Schwachstellen in der Pipeline. Das Signieren von Images und das Anhängen einer Software-Stückliste (SBOM) gehören zur Sicherheit der Software-Lieferkette, die Kapitel 8 behandelt (Sicherheit der Software-Lieferkette).

Die OCI-Standards

Docker machte Container ab 2013 populär, und 2015 gründeten Docker und andere unter dem Dach der Linux Foundation die Open Container Initiative (OCI), um eine Zersplitterung des Formats zu verhindern. Die OCI pflegt drei Spezifikationen. Die Runtime-Spezifikation legt fest, wie ein entpackter Container ausgeführt wird (Namespaces, Control Groups, Mounts, der zu startende Prozess); runc ist ihre Referenzimplementierung. Die Image-Spezifikation definiert Layer, Manifeste und Konfiguration. Die Distribution-Spezifikation definiert die HTTP-API, die Registrys für Push und Pull bereitstellen. Version 1.1 der Image- und der Distribution-Spezifikation (2024) brachte Standardwege, andere Artefakte in Registrys abzulegen und mit einem Image zu verknüpfen; so reisen Signaturen und Software-Stücklisten heute neben den Images, die sie beschreiben.

Das praktische Ergebnis ist Austauschbarkeit. Ein mit Docker, Podman, Buildah oder einem Cloud-Build-Dienst gebautes Image kann in jeder konformen Registry gespeichert und von jeder konformen Runtime ausgeführt werden: containerd und CRI-O auf einem Kubernetes-Node, eine Serverless-Container-Plattform oder der Laptop eines Entwicklers. Deshalb wurden Container, anders als die meisten Paketformate davor, zu einer gemeinsamen Sprache zwischen Entwicklung, Betrieb und jeder großen Cloud.

Warum Orchestrierung nötig ist

Einen Container zu starten, ist ein einziger Befehl. Die Essenslieferplattform zu betreiben, ist es nicht: vierzig Services mit je drei bis dreißig Kopien, verteilt über Dutzende Maschinen in drei Availability Zones, und stündlich geht irgendwo eine neue Version hinaus. Jemand muss entscheiden, auf welcher Maschine jede Kopie läuft, abgestürzte Kopien neu starten, ausgefallene Maschinen ersetzen, für den Abendansturm Kopien hinzufügen und danach wieder entfernen, neue Versionen ausrollen, ohne Anfragen zu verlieren, Services einander finden lassen, während Kopien kommen und gehen, ihnen Konfiguration und Secrets übergeben und den wenigen, die es brauchen, Speicher anhängen.

Container-Orchestrierung ist Software, die all das anhand einer Deklaration dessen erledigt, was laufen soll. Google betrieb dafür mehr als ein Jahrzehnt lang ein internes System namens Borg; 2014 kündigte es Kubernetes an, ein Open-Source-System, das auf dieser Erfahrung aufbaut, veröffentlichte im Juli 2015 Version 1.0 und übergab es der neu gegründeten Cloud Native Computing Foundation, wo es 2018 als erstes Projekt den Status „graduated“ erreichte. Es gibt Alternativen (HashiCorp Nomad, Amazon ECS, Serverless-Container-Plattformen), aber Kubernetes ist heute die gemeinsame Grundlage, die jeder große Anbieter und die meisten On-Premises-Plattformen anbieten.

Wie Kubernetes funktioniert: Control Plane und Nodes

Ein Kubernetes-Cluster hat eine Control Plane, die Entscheidungen trifft, und Worker Nodes, die die Arbeitslasten ausführen. Der API-Server ist die Eingangstür: Jeder Client, vom kubectl eines Entwicklers bis zu den clustereigenen Komponenten, liest und schreibt Objekte über seine REST-API, und er authentifiziert den Aufrufer, prüft die Autorisierung und führt Admission-Kontrollen aus, die jede Anfrage validieren oder verändern können (etwa Container ablehnen, die als Root laufen). Er ist die einzige Komponente, die mit etcd spricht, einem stark konsistenten Key-Value-Store, der den Cluster-Zustand mit dem Konsensprotokoll Raft über typischerweise drei oder fünf Mitglieder repliziert, sodass beim Verlust von einem oder zwei eine Mehrheit überlebt (Konsistenzmodelle, CAP und PACELC).

Der Scheduler beobachtet neue Pods ohne zugewiesenen Node, filtert Nodes aus, die sie nicht ausführen können (zu wenig unreservierte CPU oder zu wenig Speicher, falsche Zone, fehlende Hardware, Taints, die der Pod nicht toleriert), bewertet die übrigen (Kopien über Zonen verteilen, effizient packen) und hält seine Wahl über den API-Server fest. Der Controller Manager führt Dutzende Controller aus, jeder zuständig für eine Art von Objekt: Der ReplicaSet-Controller hält die richtige Zahl von Pods, der Node-Controller bemerkt Nodes, die sich nicht mehr melden, der Job-Controller führt Aufgaben bis zum Abschluss aus. In einer Cloud legt zusätzlich ein Cloud Controller Manager über die API des Anbieters Load Balancer an und hängt Datenträger an.

Auf jedem Worker Node läuft ein kubelet, ein Agent, der den API-Server auf Pods beobachtet, die seinem Node zugewiesen sind, die Container-Runtime (meist containerd oder CRI-O, über das Container Runtime Interface; der eingebaute Shim für Docker Engine wurde 2022 mit Version 1.24 entfernt) bittet, sie zu starten, ihre Health Probes ausführt und den Status zurückmeldet. kube-proxy programmiert die Paketweiterleitungsregeln des Nodes, sodass Verkehr an die virtuelle Adresse eines Service einen seiner Pods erreicht; manche Netzwerk-Plug-ins wie Cilium ersetzen es durch eine eBPF-Datenebene. Ein Netzwerk-Plug-in gibt jedem Pod eine eigene IP-Adresse, und ein Cluster-DNS-Dienst (meist CoreDNS) lässt Pods Services über ihren Namen finden.

Beachten Sie die Richtung der Pfeile. Die Control Plane meldet sich nie auf einem Node an, um einen Befehl auszuführen; die Nodes beobachten den Zustand, in dem sie sein sollen, und nähern sich ihm an. Dieses Pull-basierte Beobachten und Annähern macht Kubernetes robust: Ein Node, der zehn Minuten getrennt war, holt einfach auf, wenn er zurückkommt. Bei Managed Kubernetes (Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine und andere) betreibt und aktualisiert der Anbieter die Control Plane; der Kunde wählt weiterhin die Node-Typen, aktualisiert die Node-Pools und ist für alles verantwortlich, was in den Cluster deployt wird.

Deklarativer gewünschter Zustand und Reconciliation Loops

Die zentrale Idee von Kubernetes ist deklarative Konfiguration. Sie sagen dem Cluster nicht, er solle drei Container starten; Sie speichern ein Objekt, das besagt, dass drei Kopien eines bestimmten Images existieren sollen: den gewünschten Zustand. Controller führen dann Reconciliation Loops aus: den tatsächlichen Zustand beobachten, ihn mit dem gewünschten vergleichen und handeln, um die Differenz zu beseitigen, ohne Ende.

Verfolgen Sie, was geschieht, wenn während des Abendansturms ein Node in Zone B ausfällt. Der Node-Controller empfängt keine Heartbeats mehr und markiert den Node als nicht bereit; nach einem Timeout werden seine Pods zur Verdrängung (Eviction) vorgemerkt. Der ReplicaSet-Controller des Bestellservice beobachtet zwei laufende Pods, wo drei gewünscht sind, und legt ein neues Pod-Objekt an. Der Scheduler sieht einen nicht eingeplanten Pod und weist ihn einem gesunden Node zu, je nach Verteilungsregeln bevorzugt einem verbliebenen Node in Zone B oder einer anderen Zone. Das kubelet dieses Nodes sieht die Zuweisung, lädt das Image und startet den Container. Sobald seine Readiness Probe besteht, werden die Endpoints hinter dem Service orders aktualisiert, und Verkehr fließt zu ihm. Keine Komponente hat einer anderen gesagt, was zu tun ist; jede hat auf den Zustand reagiert, den sie beobachtet hat.

Weil Controller pegelgesteuert sind (sie reagieren auf die aktuelle Differenz) statt flankengesteuert (auf einzelne Ereignisse reagierend), kommt ein Controller, der abstürzt, eine Benachrichtigung verpasst oder doppelt läuft, trotzdem zum richtigen Ergebnis. Das Muster lässt sich erweitern: Custom Resource Definitions fügen neue Objekttypen hinzu, und das Operator-Muster, 2016 von CoreOS eingeführt, verpackt einen Controller, der Betriebswissen kodiert, etwa um einen PostgreSQL-Cluster aus einem einzigen deklarierten Objekt anzulegen, zu sichern und per Failover umzuschalten. Abschnitt 10.4 zeigt dieselbe Schleife, angewandt auf ganze Umgebungen durch GitOps.

Deklarative Steuerung hat ihren Preis: Sie müssen in Endzuständen denken und die genaue Abfolge loslassen. Wollen zwei Controller für dasselbe Feld unterschiedliche gewünschte Zustände, kämpfen sie gegeneinander. Ein klassisches Beispiel ist ein Deployment-Manifest in Git mit replicas: 3, während ein Autoscaler den Wert auf neun setzt; jede GitOps-Synchronisierung skaliert den Service mitten im Ansturm wieder herunter. Die Lösung ist, jedes Feld genau einem Eigentümer zu überlassen, hier durch das Entfernen von replicas aus dem Manifest.

Ein Deployment und ein Service in YAML

Die folgenden Manifeste deklarieren den Bestellservice: Konfiguration aus einem Secret, Resource Requests und Probes, ein stabiler Service davor und ein Autoscaler, der zwischen drei und zwölf Replikas hält. Das Deployment hat bewusst kein Feld replicas, damit der Autoscaler der einzige Eigentümer der Anzahl ist. Angewendet werden sie mit kubectl apply oder, besser, durch eine Pipeline oder einen GitOps-Agenten aus einem Repository.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  # no replicas field: the autoscaler below owns the count
  selector:
    matchLabels: {app: orders}
  template:
    metadata:
      labels: {app: orders}
    spec:
      containers:
      - name: orders
        image: registry.example.com/orders:2.4.1
        ports: [{containerPort: 8080}]
        env:
        - name: DATABASE_URL
          valueFrom: {secretKeyRef: {name: orders-db, key: url}}
        resources:
          requests: {cpu: 500m, memory: 512Mi}
          limits: {memory: 512Mi}  # no CPU limit: may burst
        readinessProbe:
          httpGet: {path: /ready, port: 8080}
          periodSeconds: 5
        livenessProbe:
          httpGet: {path: /live, port: 8080}
          periodSeconds: 10
          failureThreshold: 3

apiVersion: v1
kind: Service
metadata:
  name: orders
spec:
  selector: {app: orders}
  ports: [{port: 80, targetPort: 8080}]
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: orders
spec:
  scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: orders}
  minReplicas: 3
  maxReplicas: 12
  metrics:
  - type: Resource
    resource:
      name: cpu
      target: {type: Utilization, averageUtilization: 60}

Resource Requests, Limits und Quality of Service

Requests und Limits sind die folgenreichsten Zeilen eines Manifests. Ein Request ist das, was der Scheduler reserviert: Ein Pod, der 500 Millicores (eine halbe CPU) und 512 MiB Speicher anfordert, wird nur auf einem Node mit so viel unreservierter Kapazität platziert, und dieser Anteil ist ihm bei Konkurrenz garantiert. Ein Limit ist eine vom Kernel durchgesetzte Obergrenze: Ein Container, der sein CPU-Limit überschreitet, wird gedrosselt (verlangsamt), und einer, der sein Speicherlimit überschreitet, wird beendet und neu gestartet, der bekannte Status OOMKilled. Kubernetes leitet aus diesen Einstellungen eine Quality-of-Service-Klasse ab: Guaranteed (Requests gleich Limits für jede Ressource), Burstable (Requests gesetzt, Limits höher oder nicht vorhanden) und BestEffort (nichts gesetzt, als Erstes verdrängt, wenn einem Node die Ressourcen ausgehen).

Bei CPU-Limits sind sich Fachleute uneinig. Das eine Lager setzt sie überall, um Vorhersehbarkeit und Fairness zwischen Teams zu erreichen; das andere setzt genaue CPU-Requests und keine CPU-Limits, weil Drosselung Latenzspitzen verursacht, selbst wenn der Node freie CPU hat, und Requests jedem Pod seinen Anteil ohnehin garantieren. Beim Speicher gibt es wenig Streit: Setzen Sie das Limit gleich dem Request, denn Speicher lässt sich einem Prozess nicht entziehen, ohne ihn zu beenden, und ein Pod, der mehr nutzt, als er angefordert hat, ist der erste Kandidat für die Verdrängung. So oder so müssen Requests auf Messungen beruhen; überhöhte Requests verschwenden Geld (der Node ist reserviert, aber untätig), und zu niedrige verursachen Noisy-Neighbour-Probleme und irreführendes Autoscaling.

Der HorizontalPodAutoscaler berechnet gewünschte Replikas = Aufrunden(aktuelle Replikas × aktuelle Metrik ÷ Zielwert) und misst die CPU-Nutzung als Prozentsatz des Requests. Er skaliert schnell hoch, wartet aber vor dem Herunterskalieren standardmäßig ein Stabilisierungsfenster von fünf Minuten ab, um ein Hin- und Herpendeln zu vermeiden. Passen neue Pods nicht auf bestehende Nodes, bleiben sie im Status Pending, und ein Node-Autoscaler (der Cluster Autoscaler oder bei manchen Anbietern Karpenter) fügt Maschinen hinzu, was Minuten statt Sekunden dauert. Pod-Autoscaling und Node-Autoscaling sind getrennte Schleifen mit getrennten Verzögerungen, und beide müssen für den Ansturm eingeplant werden.

Liveness, Readiness und Startup Probes

Probes sind die Art, wie Kubernetes etwas über die Gesundheit erfährt. Eine Readiness Probe beantwortet, ob dieser Pod jetzt Verkehr erhalten soll; solange sie fehlschlägt, wird der Pod aus den Endpoints seines Service entfernt, läuft aber weiter. Eine Liveness Probe beantwortet, ob der Prozess unrettbar hängt; schlägt sie wiederholt fehl, startet das kubelet den Container neu. Eine Startup Probe hält die beiden anderen zurück, bis eine langsam startende Anwendung ihre Initialisierung abgeschlossen hat.

Der folgenschwerste Fehler ist eine Liveness Probe, die Abhängigkeiten prüft. Fragt der Liveness-Endpoint des Bestellservice die Datenbank ab, lässt ein dreißigsekündiges Datenbank-Failover jeden Pod des Bestellservice gleichzeitig an der Liveness scheitern, Kubernetes startet alle neu, sie verbinden sich alle im selben Moment erneut, und aus einer kurzen Störung wird ein Ausfall. Liveness sollte nur prüfen, ob der Prozess selbst antworten kann; Readiness darf berücksichtigen, ob der Pod nützliche Arbeit leisten kann, doch selbst dort vermeiden es viele Teams, wegen einer geteilten Abhängigkeit alle Pods als nicht bereit zu markieren, und lassen Anfragen lieber mit einem Circuit Breaker schnell fehlschlagen (siehe Resilienzmuster).

Probes arbeiten mit dem kontrollierten Herunterfahren zusammen. Wird ein Pod während eines Rollouts oder beim Herunterskalieren gelöscht, entfernt Kubernetes ihn aus den Endpoints und sendet dem Prozess SIGTERM; der Prozess sollte keine neue Arbeit mehr annehmen, laufende Anfragen abschließen und sich innerhalb der Schonfrist (standardmäßig 30 Sekunden) beenden, bevor er abgebrochen wird. Weil sich das Entfernen aus den Endpoints asynchron ausbreitet, verhindert eine kurze preStop-Verzögerung, dass Anfragen an einen Pod gehen, der bereits zu stoppen begonnen hat. Abschnitt 10.3 greift das als Twelve-Factor-Prinzip der Disposability wieder auf.

Wann Kubernetes überdimensioniert ist

Kubernetes ist eine Allzweckplattform zum Bauen von Plattformen, und für diese Allgemeinheit verlangt es seinen Preis. Jemand muss Netzwerk, Ingress, Identität, Secrets, Policies, Observability und Mandantenfähigkeit entwerfen; mit drei Minor Releases pro Jahr Schritt halten, die jeweils etwa vierzehn Monate unterstützt werden, dazu mit den Add-ons, die davon abhängen; und neben den Anwendungen auch für den Cluster Rufbereitschaft leisten. Verwaltete Control Planes nehmen einen Teil dieser Arbeit ab, nicht den größten.

Für ein kleines Team mit einer Handvoll zustandsloser Webservices bietet ein PaaS oder eine Serverless-Container-Plattform (Google Cloud Run, Azure Container Apps, Amazon ECS mit Fargate und Ähnliche) die meisten Vorteile (Container, Autoscaling, Rolling Deployments, verwaltetes TLS) bei einem Bruchteil der Betriebslast. Kubernetes beginnt sich zu lohnen, wenn es viele Services und mehrere Teams gibt, ein Plattformteam, das es betreibt, Arbeitslasten mit ungewöhnlichen Anforderungen (zustandsbehaftete Systeme, GPUs, Batch-Jobs, eigene Controller), die Anforderung, dieselbe Plattform vor Ort und in mehreren Clouds zu betreiben, oder ein Ökosystem von Werkzeugen, das die Organisation nutzen will. Viele Organisationen haben es eingeführt, weil es in Mode war, und dann Jahre damit verbracht, darauf im Grunde ein schlechteres PaaS zu bauen. Abschnitt 10.7 bespricht, wie Plattformteams diesem Schicksal entgehen (Platform Engineering).