Ein praxisnaher Überblick über Kubernetes
Wenn Sie eine Webanwendung entwickelt haben, die auf einem einzelnen Server problemlos läuft, aber unter realer Last zusammenbricht, verstehen Sie bereits das Problem, das Kubernetes löst. Container im großen Maßstab zu verwalten – über mehrere Maschinen hinweg, mit Zero-Downtime-Deployments und automatischer Wiederherstellung – ist tatsächlich schwierig. Kubernetes (K8s) ist das Werkzeug, auf das sich die Branche geeinigt hat, um dies zu bewältigen.
Dieser Artikel bietet Ihnen einen klaren Überblick über Kubernetes: was es ist, wie seine Architektur funktioniert und wie seine Kernkomponenten zusammenwirken, um moderne Webanwendungen zu betreiben.
Wichtigste Erkenntnisse
- Kubernetes ist die De-facto-Plattform für Container-Orchestrierung und automatisiert Scheduling, Skalierung, Self-Healing und Traffic-Routing über einen Cluster von Maschinen hinweg.
- Ein Cluster besteht aus zwei Schichten: einer Control Plane (API Server, Scheduler, Controller Manager, etcd), die Entscheidungen trifft, und Worker Nodes (Kubelet, Container Runtime, kube-proxy), die Ihre Workloads ausführen.
- Pods sind die kleinste deploybare Einheit, werden jedoch typischerweise über Deployments und ReplicaSets verwaltet, die Replikation und Rolling Updates übernehmen.
- Services stellen stabile Netzwerk-Endpunkte für kurzlebige Pods bereit, während Ingress oder die neuere Gateway API das externe HTTP/HTTPS-Routing übernehmen.
- ConfigMaps und Secrets halten Konfiguration und sensible Daten aus den Container-Images heraus und machen Ihre Deployments portabel und sicher.
Was ist Kubernetes und warum gibt es das?
Kubernetes ist eine Open-Source-Plattform zur Container-Orchestrierung, die ursprünglich von Google entwickelt und 2015 an die Cloud Native Computing Foundation (CNCF) gespendet wurde. Sie ist weit verbreitet und gilt als Standardplattform für Container-Orchestrierung.
Die Kurzfassung: Docker verpackt Ihre Anwendung in Container. Kubernetes betreibt und verwaltet diese Container über einen Cluster von Maschinen hinweg und übernimmt dabei automatisch Scheduling, Skalierung, Self-Healing und Traffic-Routing.
Grundlagen der Kubernetes-Architektur: Wie ein Cluster organisiert ist
Ein Kubernetes-Cluster besteht aus zwei eindeutigen Schichten.
Die Control Plane (das Gehirn)
Die Control Plane trifft Entscheidungen für den gesamten Cluster. Ihre wichtigsten Komponenten sind:
- API Server – der einzige Einstiegspunkt für alle Befehle. Jeder
kubectl-Aufruf landet hier. - Scheduler – entscheidet basierend auf den verfügbaren Ressourcen, welcher Worker Node einen bestimmten Pod ausführen soll.
- Controller Manager – gleicht kontinuierlich den tatsächlichen Cluster-Zustand mit Ihrem gewünschten Zustand ab.
- etcd – ein verteilter Key-Value-Store, der die gesamte Cluster-Konfiguration und den Zustand enthält. Er ist die Quelle der Wahrheit (Source of Truth).
Worker Nodes (wo Ihre Anwendung tatsächlich läuft)
Worker Nodes führen Ihre containerisierten Workloads aus. Jeder Node enthält:
- Kubelet – der Node-Agent, der sicherstellt, dass die Container wie spezifiziert ausgeführt werden.
- Container Runtime – lädt Images herunter und führt Container aus (typischerweise containerd in modernen Clustern).
- Kube-proxy – verwaltet Netzwerkregeln, damit Pods miteinander und mit Services kommunizieren können.
Zentrale Kubernetes-Konzepte für Webanwendungen
Pods
Ein Pod ist die kleinste deploybare Einheit in Kubernetes. Er umschließt einen oder mehrere Container, die einen gemeinsamen Netzwerk- und Storage-Kontext teilen. Pods werden selten direkt erstellt, da Workload-Controller sie für Sie verwalten.
Deployments und ReplicaSets
Ein Deployment ist die Art und Weise, wie Sie beschreiben, was ausgeführt werden soll: welches Container-Image, wie viele Replicas und wie Updates ausgerollt werden sollen. Es verwaltet ein darunterliegendes ReplicaSet, das sicherstellt, dass jederzeit die richtige Anzahl von Pod-Kopien läuft. Stürzt ein Pod ab, ersetzt das ReplicaSet ihn automatisch.
Für eine Frontend-Anwendung erlaubt ein Deployment Ihnen zu sagen: „Führe 3 Replicas meiner React-App aus”, und Kubernetes übernimmt den Rest, einschließlich Rolling Updates ohne Ausfallzeit.
Services
Pods sind kurzlebig, und ihre IP-Adressen ändern sich. Ein Service stellt Ihren Pods einen stabilen Netzwerk-Endpunkt zur Verfügung. Die wichtigsten Typen sind:
| Typ | Anwendungsfall |
|---|---|
ClusterIP | Interne Kommunikation zwischen Services (Standardtyp) |
NodePort | Stellt einen Service auf einem statischen Port für Tests bereit |
LoadBalancer | Cloud-verwalteter externer Zugriff (am häufigsten in Produktionsumgebungen) |
Ingress und Gateway API
Für HTTP/HTTPS-Routing – also etwa /api-Traffic an einen Service und / an einen anderen zu senden – verwenden Sie Ingress oder die neuere Gateway API. Die Gateway API ist die aktuelle Entwicklungsrichtung des Ökosystems und bietet mehr Flexibilität sowie eine rollenbasierte Konfiguration. Wenn Sie neu starten, lohnt es sich, Gateway API gegenüber traditionellen Ingress-Controllern zu evaluieren.
Discover how at OpenReplay.com.
ConfigMaps und Secrets
Halten Sie Konfiguration aus Ihren Container-Images heraus. ConfigMaps speichern nicht-sensible Einstellungen (API-URLs, Feature Flags). Secrets speichern sensible Daten (Tokens, Passwörter). Beide können als Umgebungsvariablen in Pods injiziert oder als Dateien eingebunden werden.
Wie alles zusammenpasst
Wenn Sie eine Full-Stack-Anwendung auf Kubernetes deployen, sieht der Ablauf so aus:
- Sie schreiben ein Deployment-YAML, das Ihren Anwendungs-Container und die Anzahl der Replicas beschreibt.
- Der Scheduler platziert die Pods auf Worker Nodes mit verfügbarer Kapazität.
- Ein Service gibt diesen Pods eine stabile interne Adresse.
- Ein Ingress oder Gateway leitet externen HTTP-Traffic an diesen Service weiter.
- Wenn ein Pod stirbt, ersetzt das ReplicaSet ihn. Bei Traffic-Spitzen skalieren Sie das Deployment.
Fazit
Die Grundlagen der Kubernetes-Architektur lassen sich auf Folgendes reduzieren: Die Control Plane entscheidet, die Worker Nodes führen aus, und Abstraktionen wie Pods, Deployments und Services bieten Ihnen eine konsistente Möglichkeit, Ihre Anwendung zu beschreiben und zu verwalten. Speziell für Webanwendungen bringt Sie das Verständnis von Deployments, Services und Routing den größten Teil des Weges. Der Rest – Storage, Namespaces, Resource Limits – baut darauf auf, sobald Sie die Grundlagen beherrschen.
FAQs
Wahrscheinlich nicht. Kubernetes bringt einen erheblichen operativen Overhead mit sich, einschließlich Cluster-Wartung, YAML-Konfiguration und einer steileren Lernkurve. Für kleine Projekte oder Anwendungen in frühen Phasen ist eine Managed-Plattform wie Vercel, Render oder ein einzelner VPS mit Docker Compose meist schneller und günstiger. Greifen Sie zu Kubernetes, wenn Sie Multi-Service-Orchestrierung, vorhersagbare Skalierung oder strikte Uptime-Garantien über Umgebungen hinweg benötigen.
Docker ist eine Toolchain zum Erstellen, Verpacken und Ausführen von Containern. Es baut und betreibt einzelne Container auf einem einzelnen Host. Kubernetes ist ein Orchestrator, der viele Container über viele Maschinen hinweg verwaltet und dabei Scheduling, Skalierung, Networking und Recovery übernimmt. Es handelt sich um sich ergänzende Werkzeuge: Docker erstellt die Container, und Kubernetes betreibt sie skaliert über einen Cluster hinweg.
Wenn Sie ein neues Projekt starten, ist die Gateway API langfristig die bessere Wahl. Sie bietet ein ausdrucksstärkeres Modell, eine klarere Trennung zwischen Infrastruktur- und Anwendungsteams und entspricht der Richtung, in die sich das Ökosystem entwickelt. Ingress wird weiterhin breit unterstützt und ist für bestehende Setups in Ordnung, aber neue Cluster sollten zuerst die Gateway API evaluieren, sofern der gewählte Controller sie unterstützt.
Verwenden Sie Secrets statt ConfigMaps für sensible Werte. Beachten Sie, dass Base64-Kodierung keine Verschlüsselung ist – aktivieren Sie daher Encryption at Rest in etcd und beschränken Sie den Zugriff mit RBAC. Für Secret-Management auf Produktionsniveau integrieren Sie ein externes Tool wie HashiCorp Vault, AWS Secrets Manager oder den External Secrets Operator, um Credentials sicher in Ihre Pods einzuschleusen.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
