Beschreibe die Kubernetes-Architektur: control plane vs. worker nodes und ihre Komponenten.

Question

IT Interview Practice · Accepted Answer

Ein Kubernetes-Cluster hat zwei Arten von Maschinen: die **control plane** (das "Gehirn", das Entscheidungen trifft und den Zustand speichert) und die **worker nodes** (wo deine Pods tatsächlich laufen). Jede hat einen kleinen Satz klar definierter Komponenten.

## Das Gesamtbild

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## Komponenten der control plane

```text
kube-apiserver        Der einzige Eintrittspunkt. Stellt die REST-API bereit; validiert &
                      persistiert Objekte in etcd. kubectl, Controller und kubelets
                      sprechen NUR mit dem apiserver.
etcd                  Verteilter, konsistenter key-value store. Hält den GESAMTEN
                      Clusterzustand (desired + current). etcd verlieren = Cluster verlieren.
kube-scheduler        Überwacht Pods ohne zugewiesenen Node und wählt den besten Node
                      (anhand von resource requests, affinity, taints usw.).
kube-controller-      Führt die control loops aus: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints usw. Jede Schleife treibt actual → desired.
cloud-controller-     (In der Cloud) integriert sich mit dem Provider: load balancers, routes,
manager               node lifecycle.
```

## Komponenten eines worker node

```text
kubelet          Der Node-Agent. Spricht mit dem apiserver, startet/stoppt Container über
                 die runtime und meldet Pod- & Node-Status. Er bringt die Realität des
                 Node mit den ihm zugewiesenen Pods in Einklang.
kube-proxy       Programmiert das Networking des Node (iptables/IPVS), sodass virtuelle
                 Service-IPs auf die richtigen Pod-Endpunkte load-balanced werden.
container runtime Die Software, die tatsächlich Container ausführt (containerd, CRI-O).
```

## Wie ein "kubectl apply" durch das System fließt

```text
1. kubectl → kube-apiserver: "Ich will ein Deployment mit 3 Replicas"
2. apiserver validiert & schreibt das Objekt in etcd
3. controller-manager (deployment→replicaset controller) sieht es, erstellt 3 Pod-Objekte
4. scheduler sieht 3 nicht zugewiesene Pods, weist jeden einem Node zu (schreibt via apiserver zurück)
5. der kubelet jedes Node sieht seine Pods, weist die runtime an, Images zu pullen & Container zu starten
6. kube-proxy verdrahtet das Service-Networking, sodass Traffic die neuen Pods erreicht
Alles ist eine WATCH + RECONCILE-Schleife, vermittelt durch den apiserver.
```

```bash
kubectl get nodes                 # Nodes auflisten (control-plane + workers)
kubectl get pods -n kube-system   # die control-plane / system Komponenten ansehen
kubectl get componentstatuses     # Gesundheit der zentralen control-plane-Teile
```

## Warum es wichtig ist

Die Trennung zwischen control plane und worker nodes zu verstehen — und die Rolle jeder Komponente — ist es, was Kubernetes von einer Blackbox in ein System verwandelt, über das du nachdenken und das du betreiben kannst, daher ist es Kernwissen für jeden Ingenieur ab dem mittleren Level. Die **control plane** ist das entscheidungsfindende Gehirn: Der **kube-apiserver** ist die einzige Eingangstür, über die jede Komponente und jeder Nutzer kommuniziert; **etcd** ist der konsistente key-value store, der den gesamten Clusterzustand hält und die source of truth ist (ihn zu verlieren bedeutet, den Cluster zu verlieren); der **scheduler** entscheidet, auf welchem Node jeder neue Pod landet; und der **controller-manager** führt die reconciliation loops aus, die den tatsächlichen Zustand kontinuierlich auf den desired state zutreiben. Auf jedem **worker node** ist der **kubelet** der Agent, der die Container des Node mit den ihm zugewiesenen Pods in Einklang bringt, **kube-proxy** programmiert das Networking, das virtuelle Service-IPs auf die richtigen Pods routet, und eine **container runtime** (containerd, CRI-O) führt die Container tatsächlich aus. Zu sehen, wie ein einziges `kubectl apply` durch dieses System fließt — apiserver zu etcd, Controller erstellen Objekte, scheduler platziert Pods, kubelets starten Container, kube-proxy verdrahtet Networking, alles als watch-and-reconcile-Schleifen — offenbart das elegante, konsistente Design hinter der Plattform. Dieses mentale Modell ist genau das, was du brauchst, um zu debuggen, warum ein Pod im Zustand Pending festhängt (scheduler), warum der Cluster nicht reagiert (apiserver/etcd) oder warum ein Service nicht routet (kube-proxy), was es für den Betrieb und die Fehlersuche in echten Clustern unverzichtbar macht.

Das Gesamtbild

Komponenten der control plane

Komponenten eines worker node

Wie ein "kubectl apply" durch das System fließt

Warum es wichtig ist

Ähnliche Fragen