Opišite arhitekturo Kubernetesa: control plane proti worker nodom in njihove komponente.

Question

IT Interview Practice · Accepted Answer

Gruča Kubernetes ima dve vrsti strojev: **control plane** (»možgane«, ki sprejemajo odločitve in hranijo stanje) in **worker node** (kjer vaši Podi dejansko tečejo). Vsaka ima majhen nabor dobro opredeljenih komponent.

## Širša slika

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

## Komponente control plane

```text
kube-apiserver        The single entry point. Exposes the REST API; validates &
                      persists objects to etcd. kubectl, controllers, and kubelets
                      all talk ONLY to the apiserver.
etcd                  Distributed, consistent key-value store. Holds the ENTIRE
                      cluster state (desired + current). Lose etcd = lose the cluster.
kube-scheduler        Watches for Pods with no node assigned and picks the best node
                      (based on resource requests, affinity, taints, etc.).
kube-controller-      Runs the control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Each loop drives actual → desired.
cloud-controller-     (On cloud) integrates with the provider: load balancers, routes,
manager               node lifecycle.
```

## Komponente worker nodov

```text
kubelet          The node agent. Talks to the apiserver, starts/stops containers via
                 the runtime, and reports Pod & node status. It makes the node's
                 reality match the Pods assigned to it.
kube-proxy       Programs the node's networking (iptables/IPVS) so that Service virtual
                 IPs are load-balanced to the right Pod endpoints.
container runtime The software that actually runs containers (containerd, CRI-O).
```

## Kako »kubectl apply« teče skozi sistem

```text
1. kubectl → kube-apiserver: "I want a Deployment with 3 replicas"
2. apiserver validates & writes the object to etcd
3. controller-manager (deployment→replicaset controller) sees it, creates 3 Pod objects
4. scheduler sees 3 unassigned Pods, assigns each to a node (writes back via apiserver)
5. each node's kubelet sees its Pods, tells the runtime to pull images & start containers
6. kube-proxy wires up Service networking so traffic reaches the new Pods
Everything is a WATCH + RECONCILE loop mediated by the apiserver.
```

```bash
kubectl get nodes                 # naštej node (control-plane + workerji)
kubectl get pods -n kube-system   # poglej komponente control-plane / sistema
kubectl get componentstatuses     # zdravje jedrnih delov control-plane
```

## Zakaj je to pomembno

Razumevanje delitve med control plane in worker nodi — ter vloge vsake komponente — je tisto, kar Kubernetes spremeni iz črne skrinjice v sistem, o katerem lahko sklepate in ga upravljate, zato je to jedrno znanje za vsakega inženirja srednje ravni ali višje. **Control plane** so možgani, ki sprejemajo odločitve: **kube-apiserver** je edina vhodna vrata, prek katerih komunicirajo vse komponente in uporabniki; **etcd** je konsistentna shramba ključ-vrednost, ki hrani celotno stanje gruče in je vir resnice (izguba pomeni izgubo gruče); **scheduler** odloči, na kateri node pristane vsak nov Pod; **controller-manager** pa poganja usklajevalne zanke, ki dejansko stanje neprestano poganjajo proti želenemu. Na vsakem **worker nodu** je **kubelet** agent, ki poskrbi, da se vsebniki noda ujemajo s Podi, dodeljenimi njemu, **kube-proxy** programira mreženje, ki poskrbi, da se virtualni IP-ji Service usmerjajo na prave Pode, **container runtime** (containerd, CRI-O) pa dejansko poganja vsebnike. Videti, kako en sam `kubectl apply` teče skozi ta sistem — od apiserverja do etcd, krmilniki ustvarjajo objekte, scheduler razporeja Pode, kubeleti zaganjajo vsebnike, kube-proxy povezuje mreženje, vse kot zanke watch-and-reconcile — razkriva elegantno, konsistentno zasnovo platforme. Ta miselni model je natanko to, kar potrebujete za odpravljanje napak, zakaj je Pod obtičal v stanju Pending (scheduler), zakaj se gruča ne odziva (apiserver/etcd) ali zakaj Service ne usmerja (kube-proxy), zaradi česar je nepogrešljiv pri upravljanju in odpravljanju težav resničnih gruč.

Širša slika

Komponente control plane

Komponente worker nodov

Kako »kubectl apply« teče skozi sistem

Zakaj je to pomembno

Povezana vprašanja