Container-Orchestrierung

KAPITEL 08 · CLOUD & INFRASTRUKTUR

Container-Orchestrierung

Die Verwaltung und Skalierung von Containern in großen Umgebungen – von Kubernetes über Docker Swarm bis zu Nomad. Lernen Sie, wie moderne Anwendungen orchestriert und automatisiert werden.

Docker Swarm Kubernetes Architektur Skalierung

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Container-Orchestrierung:

  • Definition: Was ist Container-Orchestrierung und warum wird sie benötigt?
  • Orchestratoren: Kubernetes, Docker Swarm, Nomad, Mesos, ECS, OpenShift
  • Kubernetes-Architektur: Control Plane, Worker Nodes, Komponenten
  • Wichtige Konzepte: Pods, Services, Deployments, ConfigMaps
  • Vergleich: Welcher Orchestrator für welchen Einsatzzweck?
  • Best Practices: Skalierung, Resilienz, Sicherheit, Monitoring
  • FAQ: Häufige Fragen und Antworten

1. Was ist Container-Orchestrierung?

Definition

Container-Orchestrierung ist die automatische Verwaltung, Skalierung, Vernetzung und Verfügbarkeit von Containern in großen, verteilten Umgebungen. Während ein einzelner Container einfach mit docker run gestartet werden kann, benötigen hunderte oder tausende Container ein intelligentes System, das sie koordiniert.

Ein Container-Orchestrator entscheidet automatisch, auf welchem Server ein Container gestartet wird, wie er mit anderen Containern kommuniziert, wie er bei Ausfällen neu gestartet wird und wie die Last auf mehrere Instanzen verteilt wird.

Typische Aufgaben: Automatische Skalierung (Auto-Scaling), Lastverteilung (Load Balancing), Selbstheilung (Self-Healing), Rolling Updates, Service Discovery und Ressourcen-Management.

Warum Container-Orchestrierung?

  • Skalierung: Automatisch mehr Container starten, wenn die Last steigt
  • Hochverfügbarkeit: Container automatisch neu starten, wenn sie abstürzen
  • Lastverteilung: Traffic auf mehrere Container-Instanzen verteilen
  • Service Discovery: Container finden sich automatisch im Netzwerk
  • Rolling Updates: Anwendungen ohne Downtime aktualisieren
  • Ressourcen-Management: CPU und RAM intelligent zuweisen

2. Die wichtigsten Container-Orchestratoren

Es gibt verschiedene Container-Orchestratoren, die sich in Funktionsumfang, Komplexität und Einsatzzweck unterscheiden.

STANDARD

Kubernetes (K8s)

Der De-facto-Standard für Container-Orchestrierung

Entwickelt von Google, jetzt von der Cloud Native Computing Foundation (CNCF) verwaltet. Der meistgenutzte Orchestrator.

  • Sehr mächtig und flexibel
  • Große Community und Ökosystem
  • Auto-Scaling, Self-Healing
  • Declarative Konfiguration (YAML)
  • Unterstützt von allen Cloud-Providern
EINFACH

Docker Swarm

Integriert in Docker, einfach zu nutzen

Nativer Docker-Orchestrator, der direkt in Docker integriert ist. Ideal für kleinere Umgebungen.

  • Einfach zu lernen und einzurichten
  • Integriert in Docker CLI
  • Geringere Komplexität als K8s
  • Gut für kleine bis mittlere Setups
  • Weniger Features als Kubernetes
FLEXIBEL

HashiCorp Nomad

Workload-Orchestrator für Container und mehr

Von HashiCorp entwickelt. Kann nicht nur Docker-Container, sondern auch VMs, JARs und Binaries orchestrieren.

  • Multi-Workload (Docker, VMs, Binaries)
  • Einfache Architektur (Single Binary)
  • Gut integriert mit Consul, Vault
  • Edge- und Hybrid-Cloud-Szenarien
  • Kleinere Community als K8s
ENTERPRISE

Apache Mesos

Cluster-Management für große Umgebungen

Entwickelt von der UC Berkeley, jetzt Apache-Projekt. Verwaltet ganze Datacenter als einen Pool von Ressourcen.

  • Sehr skalierbar (10.000+ Nodes)
  • Marathon als Framework für Container
  • Multi-Tenancy und Isolation
  • Hohe Komplexität
  • Weniger aktiv entwickelt
AWS

Amazon ECS

AWS-eigener Container-Orchestrator

Elastic Container Service – der native Container-Orchestrator von AWS. Einfach in AWS-Infrastruktur integriert.

  • Tiefe AWS-Integration
  • Einfach zu nutzen in AWS
  • Fargate für serverless Container
  • Geringere Komplexität als EKS
  • Nur in AWS verfügbar
ENTERPRISE

Red Hat OpenShift

Enterprise Kubernetes-Plattform

Enterprise Kubernetes-Distribution von Red Hat mit zusätzlichen Features für Sicherheit und Developer Experience.

  • Basiert auf Kubernetes
  • Integrierte CI/CD-Pipeline
  • Enterprise-Support von Red Hat
  • Entwicklerfreundliche Tools
  • Kommerzielle Lizenz

3. Kubernetes-Architektur

Kubernetes besteht aus zwei Hauptkomponenten: der Control Plane (Master) und den Worker Nodes.

Architektur-Übersicht

Control Plane (Master)

  • API Server: Zentrale Schnittstelle
  • etcd: Key-Value-Store für Cluster-Zustand
  • Scheduler: Entscheidet, wo Pods laufen
  • Controller Manager: Überwacht Cluster-Zustand
  • Cloud Controller: Cloud-Provider-Integration
Worker Node 1
  • kubelet: Agent auf jedem Node
  • kube-proxy: Netzwerk-Routing
  • Container Runtime: Docker/containerd
  • Pods: Laufende Container
Worker Node 2
  • kubelet: Agent auf jedem Node
  • kube-proxy: Netzwerk-Routing
  • Container Runtime: Docker/containerd
  • Pods: Laufende Container

Wichtige Komponenten erklärt

  • API Server: Die zentrale Schnittstelle für alle Kubernetes-Operationen. Alle Befehle (kubectl) gehen hier ein.
  • etcd: Ein verteilter Key-Value-Store, der den gesamten Cluster-Zustand speichert. Das "Gehirn" von Kubernetes.
  • Scheduler: Entscheidet, auf welchem Worker Node ein neuer Pod gestartet wird (basierend auf Ressourcen, Affinität, etc.).
  • Controller Manager: Überwacht den gewünschten Zustand (z.B. "3 Replicas") und korrigiert Abweichungen.
  • kubelet: Der Agent auf jedem Worker Node, der sicherstellt, dass Container laufen und gesund sind.
  • kube-proxy: Verwaltet Netzwerk-Regeln und ermöglicht Service Discovery und Load Balancing.

4. Wichtige Kubernetes-Konzepte

Kubernetes verwendet verschiedene Ressourcen-Typen, um Anwendungen zu definieren und zu verwalten.

Pod

Kleinste Einheit

Ein Pod ist die kleinste deploybare Einheit in Kubernetes. Er enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen.

apiVersion: v1 kind: Pod metadata: name: my-app spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80

Service

Netzwerk-Abstraktion

Ein Service stellt eine stabile Netzwerk-Adresse für Pods bereit, auch wenn sich die Pod-IPs ändern (z.B. bei Neustarts).

apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - port: 80 targetPort: 8080 type: ClusterIP

Deployment

Skalierung & Updates

Ein Deployment verwaltet mehrere Pod-Replicas und ermöglicht Rolling Updates und Rollbacks ohne Downtime.

apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment spec: replicas: 3 selector: matchLabels: app: my-app template: spec: containers: - name: nginx image: nginx:1.21

ConfigMap

Konfigurationsdaten

Speichert Konfigurationsdaten (z.B. Umgebungsvariablen, Config-Files) getrennt vom Container-Image.

apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_ENV: production LOG_LEVEL: info config.yaml: | database: host: db.example.com port: 5432

Secret

Sensible Daten

Ähnlich wie ConfigMap, aber für sensible Daten wie Passwörter, Tokens und Zertifikate (Base64-kodiert).

apiVersion: v1 kind: Secret metadata: name: db-secret type: Opaque data: username: YWRtaW4= # base64 password: c2VjcmV0 # base64

Ingress

HTTP-Routing

Definiert Regeln für externen HTTP/HTTPS-Zugriff auf Services (z.B. Domain-basiertes Routing, SSL/TLS).

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: app.example.com http: paths: - path: / backend: service: name: my-service port: number: 80

5. Orchestrator-Vergleich

Welcher Orchestrator passt zu welchem Einsatzzweck?

Orchestrator Komplexität Skalierbarkeit Lernkurve Einsatzgebiet
Kubernetes Hoch Sehr hoch Steil Enterprise, Cloud-Native, Microservices
Docker Swarm Niedrig Mittel Flach Kleine bis mittlere Setups, Docker-Nutzer
Nomad Mittel Hoch Mittel Multi-Workload, Edge, Hybrid-Cloud
Mesos/Marathon Sehr hoch Sehr hoch Sehr steil Large-Scale Datacenter, Legacy
Amazon ECS Mittel Hoch Mittel AWS-Umgebungen, Cloud-Native
OpenShift Hoch Sehr hoch Steil Enterprise mit Support-Bedarf

Entscheidungshilfe

  • Kubernetes: Wenn Sie maximale Flexibilität, Skalierbarkeit und Cloud-Portabilität benötigen
  • Docker Swarm: Wenn Sie bereits Docker nutzen und ein einfaches Setup für kleine bis mittlere Umgebungen wollen
  • Nomad: Wenn Sie neben Docker auch andere Workload-Typen (VMs, Binaries) orchestrieren müssen
  • Amazon ECS: Wenn Sie ausschließlich in AWS arbeiten und eine einfache Lösung suchen
  • OpenShift: Wenn Sie Enterprise-Support und eine integrierte Developer-Plattform benötigen

6. Best Practices

Skalierung & Performance

  • Horizontal Pod Autoscaler (HPA) für automatische Skalierung nutzen
  • Resource Requests und Limits für alle Container definieren
  • Readiness und Liveness Probes konfigurieren
  • Pod Disruption Budgets für Wartungsfenster
  • Cluster Autoscaler für Node-Skalierung

Resilienz & Verfügbarkeit

  • Mindestens 2 Replicas für produktive Workloads
  • Pod Anti-Affinity für Verteilung über Nodes
  • Graceful Shutdown implementieren
  • Circuit Breaker Pattern für externe Abhängigkeiten
  • Retry-Logik mit Backoff für Netzwerk-Fehler

Sicherheit

  • Namespaces für Mandantentrennung
  • RBAC (Role-Based Access Control) für Berechtigungen
  • Network Policies für Netzwerk-Isolation
  • Secrets nicht im Image, sondern als K8s Secrets
  • Regelmäßige Image-Scans auf Schwachstellen

Monitoring & Observability

  • Prometheus für Metriken-Sammlung
  • Grafana für Dashboards und Visualisierung
  • ELK/EFK-Stack oder Loki für Logs
  • Jaeger oder Zipkin für Distributed Tracing
  • Alertmanager für Benachrichtigungen

Weitere wichtige Praktiken

  • GitOps: Infrastructure as Code mit Git als Single Source of Truth (z.B. ArgoCD, Flux)
  • Immutable Infrastructure: Container-Images nicht patchen, sondern neu bauen
  • Health Checks: Readiness und Liveness Probes für alle Container
  • Resource Quotas: Limits für Namespaces, um Resource-Hogging zu verhindern
  • Backup & Disaster Recovery: etcd-Backups und Cluster-Wiederherstellung testen
  • Cost Management: Resource-Usage überwachen und optimieren (z.B. Kubecost)

FAQ – Häufige Fragen & Antworten

Häufige Fragen zur Container-Orchestrierung

Was ist der Unterschied zwischen Docker und Kubernetes?

Docker ist eine Container-Engine, die einzelne Container erstellt und ausführt. Kubernetes ist ein Container-Orchestrator, der viele Container über mehrere Server hinweg verwaltet.

  • Docker: Baut Images, startet Container auf einem einzelnen Host
  • Kubernetes: Koordiniert Container auf einem Cluster aus vielen Hosts, kümmert sich um Skalierung, Load Balancing, Self-Healing

Sie ergänzen sich: Docker baut die Container, Kubernetes orchestriert sie.

Warum ist Kubernetes so komplex?

Kubernetes ist komplex, weil es versucht, alle Aspekte der Container-Orchestrierung abzudecken:

  • Skalierung (Auto-Scaling, Manual Scaling)
  • Netzwerk (Service Discovery, Load Balancing, Ingress)
  • Storage (Persistent Volumes, Storage Classes)
  • Sicherheit (RBAC, Network Policies, Secrets)
  • Updates (Rolling Updates, Rollbacks, Canary Deployments)

Diese Komplexität ist notwendig für Enterprise-Anforderungen, aber für kleine Projekte kann Docker Swarm oder Nomad einfacher sein.

Was ist ein Pod und warum nicht direkt Container?

Ein Pod ist die kleinste Einheit in Kubernetes und kann einen oder mehrere Container enthalten. Gründe für Pods:

  • Shared Resources: Container in einem Pod teilen sich Netzwerk (gleiche IP) und Speicher (Volumes)
  • Sidecar Pattern: Hilfscontainer (z.B. Logging, Monitoring) neben dem Hauptcontainer
  • Lebenszyklus: Alle Container in einem Pod werden zusammen gestartet und gestoppt

Ein Pod ist wie ein "logischer Host" für zusammengehörige Container.

Wie funktioniert Auto-Scaling in Kubernetes?

Kubernetes bietet zwei Arten von Auto-Scaling:

  • Horizontal Pod Autoscaler (HPA): Erhöht die Anzahl der Pod-Replicas basierend auf CPU/Memory-Usage oder Custom Metrics
  • Cluster Autoscaler: Fügt neue Worker Nodes hinzu, wenn Pods nicht geplant werden können (zu wenig Ressourcen)

Beispiel HPA: Wenn die CPU-Auslastung über 70% steigt, werden automatisch mehr Pods gestartet. Sinkt sie unter 30%, werden Pods wieder entfernt.

Was ist der Unterschied zwischen Deployment und StatefulSet?
  • Deployment: Für zustandslose Anwendungen (stateless). Alle Pods sind identisch und austauschbar. Gut für Web-Server, APIs.
  • StatefulSet: Für zustandsbehaftete Anwendungen (stateful). Jeder Pod hat eine stabile Identität und eigenen Storage. Gut für Datenbanken, Message Queues.

Beispiel: Eine MySQL-Datenbank braucht einen StatefulSet, weil jeder Pod eigene Daten hat. Ein Nginx-Webserver braucht nur ein Deployment, weil alle Pods gleich sind.

Wie sicher ist Kubernetes?

Kubernetes bietet viele Sicherheitsfeatures, aber Sicherheit muss aktiv konfiguriert werden:

  • RBAC: Feingranulare Berechtigungen für Benutzer und Service Accounts
  • Network Policies: Firewall-Regeln zwischen Pods
  • Secrets: Verschlüsselte Speicherung sensibler Daten
  • Pod Security Policies: Einschränken, was Pods dürfen (z.B. kein Root)
  • Image Scanning: Automatische Prüfung auf Schwachstellen

Wichtig: Standardmäßig ist Kubernetes relativ offen. Security Hardening ist essenziell für produktive Umgebungen.

Was ist GitOps?

GitOps ist ein Paradigma, bei dem Git als Single Source of Truth für die gesamte Infrastruktur dient:

  • Alle Kubernetes-Manifeste (YAML) werden in Git versioniert
  • Änderungen erfolgen nur über Git Commits und Pull Requests
  • Ein GitOps-Tool (z.B. ArgoCD, Flux) synchronisiert automatisch den Cluster-Zustand mit Git

Vorteile: Audit-Trail, Collaboration, Rollbacks, Automatisierung. Keine manuellen kubectl-Befehle mehr.

Welche Cloud-Provider bieten Managed Kubernetes an?

Alle großen Cloud-Provider bieten Managed Kubernetes-Dienste an:

  • AWS: Amazon EKS (Elastic Kubernetes Service)
  • Azure: Azure Kubernetes Service (AKS)
  • Google Cloud: Google Kubernetes Engine (GKE)
  • DigitalOcean: DigitalOcean Kubernetes
  • Open-Source: Minikube, Kind, k3s für lokale Entwicklung

Vorteil Managed K8s: Der Provider kümmert sich um Control Plane, Updates und Sicherheit. Sie verwalten nur die Worker Nodes.

Zusammenfassung

Die wichtigsten Punkte

  • Container-Orchestrierung: Automatische Verwaltung von Containern in großen Umgebungen
  • Kubernetes: Der De-facto-Standard, sehr mächtig aber komplex
  • Docker Swarm: Einfacher, in Docker integriert, gut für kleine Setups
  • Architektur: Control Plane (API Server, etcd, Scheduler) + Worker Nodes (kubelet, kube-proxy)
  • Wichtige Konzepte: Pods, Services, Deployments, ConfigMaps, Secrets
  • Best Practices: Auto-Scaling, Health Checks, RBAC, Monitoring, GitOps
  • Cloud-Provider: EKS (AWS), AKS (Azure), GKE (Google) als Managed Services

Nächste Schritte

Nachdem Sie die Grundlagen der Container-Orchestrierung verstanden haben, können Sie folgende Themen vertiefen:

  • Docker & Container: Container-Grundlagen und Docker-Befehle
  • Kubernetes-Praxis: Eigene Cluster aufsetzen und Anwendungen deployen
  • Cloud-Infrastruktur: Managed Kubernetes in der Cloud nutzen
  • Monitoring: Prometheus, Grafana und Logging einrichten
Weiter zu Docker & Container

Weiterführende Themen

Docker & Container

Container-Grundlagen, Docker-Befehle, Images und Dockerfile.

Zu Docker & Container
Docker Compose

Multi-Container-Anwendungen mit Docker Compose definieren und starten.

Zu Docker Compose
Docker Portainer

Grafische Benutzeroberfläche für Docker-Verwaltung mit Portainer.

Zu Docker Portainer
Cloud-Sicherheit

Sicherheitsaspekte von Cloud-Infrastruktur und Container-Orchestrierung.

Zu Cloud-Sicherheit