Jelaskan arsitektur Kubernetes: control plane vs worker node dan komponen-komponennya.

Question

IT Interview Practice · Accepted Answer

Sebuah cluster Kubernetes memiliki dua jenis mesin: **control plane** ("otak" yang membuat keputusan dan menyimpan state) dan **worker node** (tempat Pod Anda benar-benar berjalan). Masing-masing memiliki sekumpulan kecil komponen yang terdefinisi dengan baik.

## Gambaran besar

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

## Komponen control plane

```text
kube-apiserver        Titik masuk tunggal. Mengekspos REST API; memvalidasi &
                      menyimpan objek ke etcd. kubectl, controller, dan kubelet
                      semuanya HANYA bicara ke apiserver.
etcd                  Key-value store terdistribusi dan konsisten. Menyimpan SELURUH
                      state cluster (desired + current). Kehilangan etcd = kehilangan cluster.
kube-scheduler        Mengawasi Pod yang belum punya node dan memilih node terbaik
                      (berdasarkan resource request, affinity, taint, dll.).
kube-controller-      Menjalankan control loop: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, dll. Tiap loop menggiring actual → desired.
cloud-controller-     (Di cloud) berintegrasi dengan provider: load balancer, route,
manager               siklus hidup node.
```

## Komponen worker node

```text
kubelet          Agen node. Bicara ke apiserver, start/stop container lewat
                 runtime, dan melaporkan status Pod & node. Ia membuat kenyataan
                 di node sesuai dengan Pod yang ditugaskan padanya.
kube-proxy       Memprogram networking node (iptables/IPVS) agar IP virtual Service
                 di-load-balance ke endpoint Pod yang tepat.
container runtime Software yang benar-benar menjalankan container (containerd, CRI-O).
```

## Bagaimana sebuah "kubectl apply" mengalir melalui sistem

```text
1. kubectl → kube-apiserver: "Saya ingin Deployment dengan 3 replica"
2. apiserver memvalidasi & menulis objek ke etcd
3. controller-manager (controller deployment→replicaset) melihatnya, membuat 3 objek Pod
4. scheduler melihat 3 Pod tanpa node, menugaskan masing-masing ke node (tulis balik via apiserver)
5. kubelet tiap node melihat Pod-nya, menyuruh runtime menarik image & start container
6. kube-proxy menyiapkan networking Service agar trafik mencapai Pod baru
Semuanya adalah loop WATCH + RECONCILE yang dimediasi oleh apiserver.
```

```bash
kubectl get nodes                 # daftar node (control-plane + worker)
kubectl get pods -n kube-system   # lihat komponen control-plane / sistem
kubectl get componentstatuses     # kesehatan bagian inti control-plane
```

## Mengapa ini penting

Memahami pembagian antara control plane dan worker node — serta peran tiap komponen — adalah yang mengubah Kubernetes dari kotak hitam menjadi sistem yang bisa Anda nalar dan operasikan, sehingga ini adalah pengetahuan inti bagi setiap insinyur level menengah ke atas. **Control plane** adalah otak pengambil keputusan: **kube-apiserver** adalah pintu depan tunggal yang menjadi jalur komunikasi setiap komponen dan pengguna; **etcd** adalah key-value store konsisten yang menyimpan seluruh state cluster dan menjadi source of truth (kehilangannya berarti kehilangan cluster); **scheduler** memutuskan node mana yang menampung tiap Pod baru; dan **controller-manager** menjalankan reconciliation loop yang terus menggiring keadaan aktual menuju keadaan yang diinginkan. Pada setiap **worker node**, **kubelet** adalah agen yang membuat container node sesuai dengan Pod yang ditugaskan padanya, **kube-proxy** memprogram networking yang membuat IP virtual Service me-route ke Pod yang tepat, dan sebuah **container runtime** (containerd, CRI-O) benar-benar menjalankan container. Melihat bagaimana satu `kubectl apply` mengalir melalui sistem ini — apiserver ke etcd, controller membuat objek, scheduler menempatkan Pod, kubelet men-start container, kube-proxy menyiapkan networking, semuanya sebagai loop watch-and-reconcile — menyingkap desain yang elegan dan konsisten di balik platform ini. Model berpikir ini persis yang Anda butuhkan untuk men-debug mengapa sebuah Pod terjebak Pending (scheduler), mengapa cluster tidak responsif (apiserver/etcd), atau mengapa sebuah Service tidak me-route (kube-proxy), menjadikannya tak tergantikan untuk mengoperasikan dan menyelesaikan masalah cluster nyata.

Gambaran besar

Komponen control plane

Komponen worker node

Bagaimana sebuah "kubectl apply" mengalir melalui sistem

Mengapa ini penting

Pertanyaan terkait