Kuvaile Kubernetesin arkkitehtuuri: control plane vs worker-nodet ja niiden komponentit.

Question

IT Interview Practice · Accepted Answer

Kubernetes-klusterissa on kahdenlaisia koneita: **control plane** ("aivot", jotka tekevät päätöksiä ja tallentavat tilan) ja **worker-nodet** (joissa Podisi oikeasti ajetaan). Kummallakin on pieni joukko hyvin määriteltyjä komponentteja.

## Kokonaiskuva

```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 -komponentit

```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.
```

## Worker-noden komponentit

```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).
```

## Miten "kubectl apply" virtaa järjestelmän läpi

```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                 # listaa nodet (control-plane + workerit)
kubectl get pods -n kube-system   # näe control-plane / järjestelmäkomponentit
kubectl get componentstatuses     # ydin-control-plane-osien terveys
```

## Miksi se on tärkeää

Sen ymmärtäminen, miten control plane ja worker-nodet jakautuvat — ja kunkin komponentin rooli — on se, mikä muuttaa Kubernetesin mustasta laatikosta järjestelmäksi, josta voit päätellä ja jota voit operoida, joten se on ydintietoa kenelle tahansa keskitason tai ylemmän insinöörille. **Control plane** on päätöksentekevät aivot: **kube-apiserver** on yksi etuovi, jonka kautta jokainen komponentti ja käyttäjä viestii; **etcd** on konsistentti avain-arvo-varasto, joka pitää koko klusterin tilan ja on totuuden lähde (sen menettäminen tarkoittaa klusterin menettämistä); **scheduler** päättää, mille nodelle kukin uusi Pod laskeutuu; ja **controller-manager** ajaa reconciliation-looppeja, jotka jatkuvasti ajavat todellista tilaa haluttua kohti. Jokaisella **worker-nodella** **kubelet** on agentti, joka saa noden kontit vastaamaan sille annettuja Podeja, **kube-proxy** ohjelmoi verkotuksen, joka saa Service-virtuaali-IP:t reitittymään oikeisiin Podeihin, ja **container runtime** (containerd, CRI-O) oikeasti ajaa kontit. Sen näkeminen, miten yksittäinen `kubectl apply` virtaa tämän järjestelmän läpi — apiserverista etcd:hen, kontrollerit luomassa objekteja, scheduler sijoittamassa Podeja, kubeletit käynnistämässä kontteja, kube-proxy kytkemässä verkotusta, kaikki watch-and-reconcile-looppeina — paljastaa alustan takana olevan tyylikkään, konsistentin suunnittelun. Tämä ajatusmalli on juuri se, mitä tarvitset debugataksesi miksi Pod jää Pending-tilaan (scheduler), miksi klusteri ei vastaa (apiserver/etcd) tai miksi Service ei reititä (kube-proxy), tehden siitä välttämättömän todellisten klustereiden operointiin ja vianetsintään.

Kokonaiskuva

Control plane -komponentit

Worker-noden komponentit

Miten "kubectl apply" virtaa järjestelmän läpi

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset