Beskriv Kubernetes-arkitekturen: control plane vs worker-noder og komponentene deres.

Question

IT Interview Practice · Accepted Answer

En Kubernetes-klynge har to typer maskiner: **control plane** («hjernen» som tar beslutninger og lagrer tilstand) og **worker-noder** (der Pods dine faktisk kjører). Hver har et lite sett av veldefinerte komponenter.

## Det store bildet

```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) │
└─────────────────────┘ └─────────────────────┘
```

## Control plane-komponenter

```text
kube-apiserver        Det eneste inngangspunktet. Eksponerer REST-API-et; validerer
                      og persisterer objekter til etcd. kubectl, controllere og
                      kubelets snakker KUN med apiserveren.
etcd                  Distribuert, konsistent key-value-store. Holder HELE
                      klyngetilstanden (desired + current). Mist etcd = mist klyngen.
kube-scheduler        Ser etter Pods uten tildelt node og velger den beste noden
                      (basert på resource requests, affinity, taints, osv.).
kube-controller-      Kjører control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, osv. Hver loop driver actual → desired.
cloud-controller-     (I cloud) integrerer med provideren: load balancers, ruter,
manager               node-livssyklus.
```

## Worker-node-komponenter

```text
kubelet          Node-agenten. Snakker med apiserveren, starter/stopper containere via
                 runtime-en, og rapporterer Pod- og node-status. Den får nodens
                 virkelighet til å stemme med Pods tildelt den.
kube-proxy       Programmerer nodens nettverk (iptables/IPVS) slik at Service-virtuelle
                 IP-er load-balances til riktige Pod-endpoints.
container runtime Programvaren som faktisk kjører containere (containerd, CRI-O).
```

## Hvordan en «kubectl apply» flyter gjennom systemet

```text
1. kubectl → kube-apiserver: "Jeg vil ha en Deployment med 3 replicas"
2. apiserver validerer og skriver objektet til etcd
3. controller-manager (deployment→replicaset controller) ser det, oppretter 3 Pod-objekter
4. scheduler ser 3 utildelte Pods, tildeler hver til en node (skriver tilbake via apiserver)
5. hver nodes kubelet ser sine Pods, ber runtime hente images og starte containere
6. kube-proxy kobler opp Service-nettverk slik at trafikk når de nye Pods
Alt er en WATCH + RECONCILE-loop mediert av apiserveren.
```

```bash
kubectl get nodes                 # list opp noder (control-plane + workers)
kubectl get pods -n kube-system   # se control-plane / system-komponentene
kubectl get componentstatuses     # helsen til kjerne-control-plane-delene
```

## Hvorfor det er viktig

Å forstå delingen mellom control plane og worker-noder — og rollen til hver komponent — er det som gjør Kubernetes fra en svart boks til et system du kan resonnere om og drifte, så det er kjernekunnskap for enhver ingeniør på middle-nivå eller høyere. **Control plane** er den beslutningstakende hjernen: **kube-apiserver** er den ene inngangsdøren som hver komponent og bruker kommuniserer gjennom; **etcd** er den konsistente key-value-storen som holder hele klyngetilstanden og er kilden til sannhet (å miste den betyr å miste klyngen); **scheduleren** avgjør hvilken node hver nye Pod havner på; og **controller-manageren** kjører reconciliation-loopene som kontinuerlig driver faktisk tilstand mot desired state. På hver **worker-node** er **kubelet** agenten som får nodens containere til å stemme med Pods tildelt den, **kube-proxy** programmerer nettverket som får Service-virtuelle IP-er til å rute til riktige Pods, og en **container runtime** (containerd, CRI-O) kjører faktisk containerne. Å se hvordan en enkelt `kubectl apply` flyter gjennom dette systemet — apiserver til etcd, controllere som oppretter objekter, scheduler som plasserer Pods, kubelets som starter containere, kube-proxy som kobler opp nettverk, alt som watch-and-reconcile-loops — avslører det elegante, konsistente designet bak plattformen. Denne mentale modellen er nettopp hva du trenger for å feilsøke hvorfor en Pod sitter fast i Pending (scheduler), hvorfor klyngen ikke svarer (apiserver/etcd), eller hvorfor en Service ikke ruter (kube-proxy), noe som gjør den uunnværlig for å drifte og feilsøke ekte klynger.

Det store bildet

Control plane-komponenter

Worker-node-komponenter

Hvordan en «kubectl apply» flyter gjennom systemet

Hvorfor det er viktig

Relaterte spørsmål