Beskriv Kubernetes-arkitekturen: control plane vs worker nodes og deres komponenter.

Question

IT Interview Practice · Accepted Answer

En Kubernetes-klynge har to slags maskiner: **control plane** (den "hjerne", der træffer beslutninger og gemmer tilstand) og **worker nodes** (hvor dine Pods faktisk kører). Hver har et lille sæt veldefinerede komponenter.

## Det store billede

```text
┌──────────────── CONTROL PLANE (hjernen) ──────────────────┐
│                                                            │
│   kube-apiserver ── hoveddøren; AL kommunikation herigennem│
│        │                                                   │
│   etcd ───────── key-value-store: klyngens SANDHEDS-       │
│                  KILDE (alle objekter & ønsket tilstand)   │
│   kube-scheduler ── afgør HVILKEN node en ny Pod kører på  │
│   controller-manager ── kører control loops (reconcilere)  │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (dine apps) │ │  └ Pods (dine apps) │
└─────────────────────┘ └─────────────────────┘
```

## Control plane-komponenter

```text
kube-apiserver        Det eneste indgangspunkt. Eksponerer REST API'et; validerer &
                      persisterer objekter til etcd. kubectl, controllere og kubelets
                      taler KUN med apiserveren.
etcd                  Distribueret, konsistent key-value-store. Rummer HELE
                      klyngens tilstand (ønsket + nuværende). Mist etcd = mist klyngen.
kube-scheduler        Holder øje med Pods uden tildelt node og vælger den bedste node
                      (ud fra resource requests, affinity, taints, osv.).
kube-controller-      Kører control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, osv. Hvert loop driver faktisk → ønsket.
cloud-controller-     (På cloud) integrerer med udbyderen: load balancers, routes,
manager               node-livscyklus.
```

## Worker node-komponenter

```text
kubelet          Node-agenten. Taler med apiserveren, starter/stopper containere via
                 runtime'en og rapporterer Pod- & node-status. Den får nodens
                 virkelighed til at matche de Pods, der er tildelt den.
kube-proxy       Programmerer nodens netværk (iptables/IPVS), så Service-virtuelle
                 IP'er load-balances til de rigtige Pod-endpoints.
container runtime Softwaren, der faktisk kører containere (containerd, CRI-O).
```

## Hvordan en "kubectl apply" flyder gennem systemet

```text
1. kubectl → kube-apiserver: "Jeg vil have en Deployment med 3 replicas"
2. apiserver validerer & skriver objektet til etcd
3. controller-manager (deployment→replicaset-controller) ser det, opretter 3 Pod-objekter
4. scheduler ser 3 utildelte Pods, tildeler hver til en node (skriver tilbage via apiserver)
5. hver nodes kubelet ser sine Pods, beder runtime'en hente images & starte containere
6. kube-proxy kobler Service-netværk op, så trafik når de nye Pods
Alt er et WATCH + RECONCILE-loop formidlet af apiserveren.
```

```bash
kubectl get nodes                 # list nodes (control-plane + workers)
kubectl get pods -n kube-system   # se control-plane / system-komponenterne
kubectl get componentstatuses     # helbred for kerne-control-plane-dele
```

## Hvorfor det betyder noget

At forstå opdelingen mellem control plane og worker nodes — og hver komponents rolle — er det, der forvandler Kubernetes fra en black box til et system, du kan ræsonnere om og drive, så det er kerneviden for enhver ingeniør på mellemniveau eller derover. **Control plane** er den beslutningstagende hjerne: **kube-apiserver** er den eneste hoveddør, som hver komponent og bruger kommunikerer igennem; **etcd** er den konsistente key-value-store, der rummer hele klyngens tilstand og er sandhedskilden (at miste den betyder at miste klyngen); **scheduleren** afgør, hvilken node hver ny Pod lander på; og **controller-manager** kører de reconciliation-loops, der løbende driver den faktiske tilstand hen mod den ønskede. På hver **worker node** er **kubelet** den agent, der får nodens containere til at matche de Pods, den er tildelt, **kube-proxy** programmerer det netværk, der får Service-virtuelle IP'er til at route til de rigtige Pods, og en **container runtime** (containerd, CRI-O) kører faktisk containerne. At se, hvordan en enkelt `kubectl apply` flyder gennem dette system — apiserver til etcd, controllere der opretter objekter, scheduler der placerer Pods, kubelets der starter containere, kube-proxy der kobler netværk — alt sammen som watch-and-reconcile-loops — afslører det elegante, konsistente design bag platformen. Denne mentale model er præcis, hvad du har brug for til at fejlfinde, hvorfor en Pod hænger i Pending (scheduler), hvorfor klyngen ikke svarer (apiserver/etcd), eller hvorfor en Service ikke router (kube-proxy), hvilket gør den uundværlig til at drive og fejlsøge rigtige klynger.

Det store billede

Control plane-komponenter

Worker node-komponenter

Hvordan en "kubectl apply" flyder gennem systemet

Hvorfor det betyder noget

Relaterede spørgsmål