Kubernetes-Architektur im Überblick

Lernziele

Nach dieser Lektion kannst du die Kubernetes-Architektur an einem Whiteboard skizzieren: Control Plane mit API Server, etcd, Scheduler und Controller Manager auf der einen Seite, Worker Nodes mit kubelet, kube-proxy und Container Runtime auf der anderen. Du verstehst, warum alle Komponenten ausschließlich über die Kubernetes API kommunizieren, kannst den Pod-Lebensweg von kubectl apply bis Running erklären und begründen, wann Managed Kubernetes die bessere Wahl ist als ein selbst betriebener Cluster.

Das Problem: Container alleine reichen nicht

Docker hat Container populär gemacht — aber „Container laufen lassen” ist nicht „Anwendung betreiben”. Was passiert, wenn der Prozess abstürzt und niemand ihn neu startet? Wenn der Server stirbt und der Container mit ihm? Wenn du Version 2 ausrollen willst, während Version 1 noch Traffic bekommt? Wenn du hundert Microservices hast und jeder eine eigene IP bräuchte?

Früher hast du das mit Shell-Skripten, Cron-Jobs und einem Load Balancer pro Service gelöst — und jeder hat es anders gemacht. Kubernetes ersetzt diese Ad-hoc-Automatisierung durch ein einheitliches Betriebsmodell: Du beschreibst den gewünschten Zustand (Desired State), das System hält ihn gegen die Realität (Actual State) — und korrigiert Abweichungen selbst.

Das klingt abstrakt, ist aber der Kern jedes Interviews: Reconciliation. Ein Deployment sagt „drei Replicas”. Einer stirbt. Der ReplicaSet Controller sieht „Actual: 2, Desired: 3” und erstellt einen neuen Pod. Kein Mensch, kein Cron — eine Schleife, die permanent vergleicht und handelt.

Was Kubernetes ist — und was nicht

Kubernetes ist kein Platform-as-a-Service wie Heroku. Es startet Container, aber du musst Images bauen, Health Checks definieren, Ressourcen setzen und oft selbst entscheiden, wie Logs und Metrics aussehen. Es ist kein Ersatz für Docker — Docker (bzw. containerd) ist die Runtime unter Kubernetes. Kubernetes ist die Orchestrierungsschicht darüber: Scheduling, Self-Healing, Skalierung, Service Discovery, Rolling Updates.

Als Platform Engineer lieferst du oft genau die fehlende Schicht — Golden Paths, Observability, GitOps — auf Kubernetes, nicht statt Kubernetes.

Die Arbeitsteilung: Control Plane und Worker Nodes

Kubernetes folgt dem Modell Control Plane (entscheiden) und Worker Nodes (ausführen). Die Trennung ist logisch; physisch können beide auf derselben Maschine laufen (minikube, kind) — in Produktion trennst du sie.

Control Plane — vier Kernkomponenten:

• API Server — die einzige Tür ins System. Jede Interaktion (kubectl, Controller, kubelet) ist ein HTTP-Request an ihn. Authentifizierung, Autorisierung, Validierung, Admission — alles passiert hier, bevor etwas in den Cluster-State geschrieben wird. Es gibt keinen Seitenkanal.
• etcd — verteilter Key-Value-Store; der gesamte Cluster-Zustand liegt hier. Deployments, Pods, Secrets, ConfigMaps — am Ende Einträge in etcd. Nur der API Server spricht direkt mit etcd. Verlierst du etcd ohne Backup, verlierst du den Cluster.
• Scheduler — sieht Pods ohne nodeName, filtert passende Nodes (Ressourcen, Taints, Affinity), scored und schreibt die Binding-Entscheidung zurück in die API. Er startet nichts — er entscheidet nur.
• Controller Manager — Dutzende Control Loops: Deployment → ReplicaSet, ReplicaSet → Pods, Service → Endpoints, Node Health. Jeder Controller beobachtet API-Objekte per Watch und reconciled Desired vs. Actual.

Worker Nodes:

• kubelet — Agent auf jedem Node. Liest Pod-Specs „seiner” Pods aus der API, instruiert die Container Runtime (heute fast immer containerd), meldet Status zurück (Ready, CrashLoopBackOff, …).
• kube-proxy — implementiert Service-IPs auf dem Node (iptables, IPVS oder eBPF — je nach Modus). Ohne kube-proxy (oder Cilium-Ersatz) funktionieren ClusterIPs nicht.

Der Interview-Klassiker: Komponenten reden nicht direkt miteinander. Der Scheduler ruft nie das kubelet an. Alles läuft über die API — deshalb ist ein ausgefallener Scheduler kein Datenverlust: der Pod-Objekt ohne Node-Zuordnung liegt in etcd und wird nachgeholt, sobald der Scheduler wieder da ist.

Der Lebensweg eines Pods — alle Komponenten in einem Ablauf

Was passiert bei kubectl apply -f deployment.yaml?

1. kubectl → API Server: Manifest validiert, authentifiziert, autorisiert; Deployment-Objekt landet in etcd.
2. Deployment Controller: Sieht neues Deployment, erstellt ReplicaSet — nur API-Objekte, noch kein laufender Container.
3. ReplicaSet Controller: Erstellt Pod-Objekte (Desired Replicas) — wieder nur in etcd.
4. Scheduler: Sieht ungebundene Pods, wählt Nodes, schreibt nodeName (Binding).
5. kubelet auf dem Node: Sieht zugewiesene Pods, pullt Images, startet Container via containerd, meldet Status an die API.
6. Endpoint Controller (im Controller Manager): Sieht Ready-Pods, pflegt Endpoints für den Service.

Erst in Schritt 5 läuft Code. Schritte 1–4 sind reine API-Mechanik — deshalb kann kubectl get pods lange Pending zeigen, obwohl „nichts kaputt” ist: Der Scheduler findet keinen passenden Node, oder Images werden noch gezogen.

Beobachte das live mit Events:

kubectl create deployment web --image=nginx --replicas=2
kubectl get events --sort-by=.metadata.creationTimestamp | tail -10

Du siehst ScalingReplicaSet, Scheduled, Pulling, Started — die Arbeitsteilung schwarz auf weiß.

Namespaces — die erste Isolation

Bevor du in Lektion 18 tief in RBAC gehst: Namespaces sind die erste logische Grenze — nicht die sicherste, aber die organisatorische. team-a und team-b in getrennten Namespaces; Quotas, NetworkPolicies und RBAC pro Namespace. Der API Server kennt keine „Teams” — nur Objekte mit Namespace-Feld. Multi-Tenancy baut darauf auf, ersetzt aber nicht NetworkPolicy und RBAC.

Managed oder self-hosted?

EKS, GKE, AKS: Provider betreibt Control Plane (API Server, etcd, Scheduler, Controller Manager) — HA, Backups, Patching inklusive. Du verantwortest Worker, Add-ons (CNI, Ingress, Monitoring) und eure Workloads.

Self-hosted (kubeadm, kops): Volle Kontrolle über API-Flags, etcd-Tuning, Air-Gap — dafür etcd-Backups, Zertifikatsrotation, Control-Plane-Upgrades und HA-Design (Lektion 5) bei dir.

Im Interview: Managed ist der Default für die meisten Teams. Self-hosted rechtfertigt sich bei On-Prem-Pflicht, Air-Gap oder Spezial-Compliance — nicht weil „wir Kubernetes besser verstehen wollen”. Wer das klar sagt und trotzdem erklären kann, was der Provider abnimmt, wirkt senior.

Praxis: die Architektur zum Anfassen

kind create cluster --name archlab

kubectl cluster-info
kubectl get nodes -o wide

# Control-Plane-Komponenten laufen als Pods (kind/minikube)
kubectl get pods -n kube-system

kubectl api-resources | head -20

kubectl create deployment web --image=nginx --replicas=2
kubectl get events --sort-by=.metadata.creationTimestamp | tail -10

kind delete cluster --name archlab

Zwei Dinge solltest du dir merken: kubectl get pods -n kube-system zeigt, dass die Control Plane selbst containerisiert sein kann — logische Trennung ≠ separate Maschinen. Und Events sind dein Freund, um zu verstehen, welche Komponente gerade aktiv war.

Typische Stolperfallen

„Der Scheduler startet Pods.” — Nein. Er schreibt nur die Node-Zuordnung. Starten tut ausschließlich das kubelet.

„Der Cluster-State liegt im API Server.” — Nein. etcd. Der API Server ist die Schnittstelle zu etcd.

„Control Plane down = Apps down.” — Bestehende Pods laufen weiter; kubelet hält Container am Leben. Was fehlt: neues Scheduling, Self-Healing, Deployments. „Cluster kaputt ≠ Apps tot” ist Senior-Nuance.

Kubernetes = Docker. — Kubernetes orchestriert; containerd/CRI runnt die Container. Wer das verwechselt, versteht weder Tool.

Interview-Vorbereitung

Auf „Beschreibe die Kubernetes-Architektur” antwortest du in drei Stufen:

1. Prinzip: Deklarativer Desired State, Reconciliation durch Controller.
2. Arbeitsteilung: Control Plane (API Server, etcd, Scheduler, Controller Manager) vs. Worker (kubelet, kube-proxy, Runtime) — alles über die API, nichts direkt.
3. Pod-Lebensweg: apply → Controller → Scheduler → kubelet → Running.

Follow-ups:

• „Was passiert bei Control-Plane-Ausfall?” — Pods laufen, kein Self-Healing/Scheduling.
• „Warum nur eine API?” — AuthN, AuthZ, Validierung, Audit an einem Punkt; entkoppelte Komponenten.
• „Wo der State?” — etcd, nur API Server spricht direkt damit.
• „EKS oder selbst?” — Managed Default; self-hosted bei On-Prem/Air-Gap mit vollem Betriebsaufwand.

Zusammenfassung

Kubernetes trennt Entscheiden von Ausführen und verbindet beides über genau eine Schnittstelle — die Kubernetes API. Der Zustand lebt in etcd; Controller reconcilen unermüdlich; der Weg eines Pods führt durch Scheduler und kubelet, ohne dass zwei Komponenten je direkt miteinander sprechen. Managed Kubernetes nimmt dir die Control Plane ab, nicht das Verständnis.

In der nächsten Lektion zoomen wir auf das Herzstück: Wie der API Server Requests durch Authentifizierung, Autorisierung und Admission schleust — und warum etcd mit Raft den Cluster-State hütet.