Jlèntrèhna arsitektur Kubernetes: control plane vs worker node lan komponèn-komponèné.

Question

IT Interview Practice · Accepted Answer

Sawijining cluster Kubernetes nduwé rong jinis mesin: **control plane** ("otak" sing gawé keputusan lan nyimpen state) lan **worker node** (papan Pod sampeyan tenanan mlaku). Saben nduwé sakumpulan cilik komponèn sing wis kadhéfinisi kanthi cetha.

## Gambaran gedhé

```text
┌──────────────── CONTROL PLANE (otak) ─────────────────────┐
│                                                            │
│   kube-apiserver ── lawang ngarep; KABÈH komunikasi liwat iki│
│        │                                                   │
│   etcd ───────── key-value store: SUMBER KEBENERAN         │
│                  cluster (kabèh objek & desired state)     │
│   kube-scheduler ── nemtokaké node SING ENDI Pod anyar mlaku│
│   controller-manager ── njalanaké control loop (reconciler)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pod (app sampeyan)│ │  └ Pod (app sampeyan)│
└─────────────────────┘ └─────────────────────┘
```

## Komponèn control plane

```text
kube-apiserver        Titik mlebu tunggal. Mbukak REST API; validasi &
                      nyimpen objek menyang etcd. kubectl, controller, lan kubelet
                      kabèh mung omong-omongan karo apiserver.
etcd                  Key-value store sing terdistribusi, konsisten. Nyekel SAKABÈHÉ
                      state cluster (desired + saiki). Ilang etcd = ilang cluster.
kube-scheduler        Ngawasi Pod sing durung diwènèhi node lan milih node paling apik
                      (adhedhasar resource request, affinity, taint, lsp.).
kube-controller-      Njalanaké control loop: node controller, replikasi (ReplicaSet),
manager               deployment, job, endpoints, lsp. Saben loop nggiring nyata → desired.
cloud-controller-     (Ing cloud) integrasi karo provider: load balancer, route,
manager               siklus urip node.
```

## Komponèn worker node

```text
kubelet          Agen node. Omong-omongan karo apiserver, wiwit/mandheg container liwat
                 runtime, lan nglaporaké status Pod & node. Dhèwèké nggawé kanyatan node
                 cocog karo Pod sing diwènèhaké marang dhèwèké.
kube-proxy       Ngatur networking node (iptables/IPVS) supaya IP virtual Service
                 diseimbangaké bebané menyang endpoint Pod sing bener.
container runtime Piranti lunak sing tenanan njalanaké container (containerd, CRI-O).
```

## Kepiyé sawijining "kubectl apply" mili liwat sistem

```text
1. kubectl → kube-apiserver: "Aku pengin Deployment kanthi 3 replica"
2. apiserver validasi & nulis objek menyang etcd
3. controller-manager (deployment→replicaset controller) ndeleng iku, nggawé 3 objek Pod
4. scheduler ndeleng 3 Pod durung diwènèhi node, mènèhaké saben menyang node (nulis manèh liwat apiserver)
5. kubelet saben node ndeleng Pod-é, ngongkon runtime narik image & wiwit container
6. kube-proxy nyambungaké networking Service supaya trafik nggayuh Pod anyar
Kabèh iku loop WATCH + RECONCILE sing dipermediasi apiserver.
```

```bash
kubectl get nodes                 # dhaptar node (control-plane + worker)
kubectl get pods -n kube-system   # ndeleng komponèn control-plane / sistem
kubectl get componentstatuses     # kaséhatan bagéyan inti control-plane
```

## Kenapa iki penting

Ngerti pambagéan antara control plane lan worker node — lan peran saben komponèn — iku sing ngowahi Kubernetes saka kothak ireng dadi sistem sing bisa sampeyan nalar lan operasi, mula iki kawruh inti kanggo insinyur tingkat middle-utawa-ndhuwur. **Control plane** iku otak sing gawé keputusan: **kube-apiserver** iku lawang ngarep tunggal sing dadi dalan saben komponèn lan pangguna komunikasi; **etcd** iku key-value store konsisten sing nyekel sakabèhé state cluster lan dadi sumber kebeneran (ilang iku tegesé ilang cluster); **scheduler** nemtokaké node ngendi saben Pod anyar mendharat; lan **controller-manager** njalanaké reconciliation loop sing terus-terusan nggiring kahanan nyata tumuju desired state. Ing saben **worker node**, **kubelet** iku agen sing nggawé container node cocog karo Pod sing diwènèhaké marang dhèwèké, **kube-proxy** ngatur networking sing nggawé IP virtual Service ngarahaké menyang Pod sing bener, lan **container runtime** (containerd, CRI-O) sing tenanan njalanaké container. Ndeleng carané siji `kubectl apply` mili liwat sistem iki — apiserver menyang etcd, controller nggawé objek, scheduler nyèlèhaké Pod, kubelet miwiti container, kube-proxy nyambung networking, kabèh minangka loop watch-and-reconcile — mbukak rancangan sing anggun lan konsisten ing mburi platform iki. Model mental iki pas karo apa sing sampeyan butuhaké kanggo debug kenapa sawijining Pod macet Pending (scheduler), kenapa cluster ora nanggapi (apiserver/etcd), utawa kenapa Service ora ngarahaké (kube-proxy), dadi ora bisa dipisahaké kanggo ngoperasi lan ngrampungaké masalah cluster nyata.

Gambaran gedhé

Komponèn control plane

Komponèn worker node

Kepiyé sawijining "kubectl apply" mili liwat sistem

Kenapa iki penting

Pitakon sing gegandhengan