Kubernetes (K8s)

Entstehung und Beteiligte

Kubernetes wurde 2014 von Google veröffentlicht. Die Initiatoren Craig McLuckie, Joe Beda und Brendan Burns übertrugen Erfahrungen aus Googles internen Systemen Borg und Omega. 2015 wurde Kubernetes erstes großes Projekt der Cloud Native Computing Foundation.

Welches Problem sollte gelöst werden?

Viele Container müssen über Rechner verteilt, bei Fehlern neu gestartet, aktualisiert und erreichbar gemacht werden. Manuelle Skripte konnten diese dynamische Umgebung nicht zuverlässig steuern.

Technische Hürden und Lösungen

Kubernetes arbeitet deklarativ und gleicht gewünschten mit tatsächlichem Zustand ab. Konsens, Scheduling, Netzwerk, Storage und rollende Updates müssen trotz Ausfällen funktionieren. Die flexible API führt zu hoher Komplexität und zahlreichen Erweiterungspunkten.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• 2014 veröffentlicht Google Kubernetes.
• Der Name ist griechisch für Steuermann; K8s kürzt acht Buchstaben ab.
• etcd speichert den Clusterzustand.
• Pods sind die kleinste gemeinsam geplante Ausführungseinheit.

Was ist Kubernetes?

Kubernetes (K8s, griech. Steuermann) ist ein Open-Source-Orchestrierungssystem für Container-Workloads. Entwickelt von Google (intern als Borg), 2014 veröffentlicht. K8s übernimmt Scheduling (auf welchem Node läuft ein Pod?), Self-Healing (crashed Pods neu starten, ersetzen), Auto-Scaling (Horizontal Pod Autoscaler) und Rolling Deployments ohne Downtime.

Die Architektur: Control Plane (API Server, etcd für State, Scheduler, Controller Manager) + Worker Nodes (kubelet, kube-proxy, Container Runtime).

Kubernetes-Objekte

• Pod: Kleinste deploybare Einheit – ein oder mehrere Container die sich Netzwerk und Storage teilen.
• Deployment: Verwaltet Pod-Replikate, Rolling Updates und Rollbacks.
• Service: Stabiler DNS-Name und IP für einen Pod-Set. Typen: ClusterIP (intern), NodePort, LoadBalancer.
• Ingress: HTTP/HTTPS-Routing von extern auf Services (mit TLS-Termination).
• ConfigMap / Secret: Konfiguration und Credentials extern speichern (nicht im Image).
• PersistentVolumeClaim (PVC): Anfordern von persistentem Speicher.
• Namespace: Logische Trennung im Cluster (z.B. prod, staging, dev).

Managed K8s und Ökosystem

Jeder große CSP bietet Managed Kubernetes: EKS (AWS), AKS (Azure), GKE (Google) – Control Plane ist gemanaged, du pflegst nur Worker Nodes. Helm ist der Paketmanager für K8s (Charts = vorkonfigurierte Anwendungspakete).

Monitoring: Prometheus + Grafana. Service Mesh: Istio/Linkerd (mTLS, Traffic Management). GitOps: ArgoCD, Flux. Vertikales Scaling: KEDA (Event-driven). CI/CD: GitHub Actions, Tekton.