Perihalkan seni bina Kubernetes: control plane berbanding worker node dan komponennya.

Question

IT Interview Practice · Accepted Answer

Sebuah cluster Kubernetes mempunyai dua jenis mesin: **control plane** (si "otak" yang membuat keputusan dan menyimpan keadaan) dan **worker node** (tempat Pod anda sebenarnya berjalan). Setiap satu ada set kecil komponen yang tertakrif jelas.

## Gambaran besar

```text
┌──────────────── CONTROL PLANE (si otak) ──────────────────┐
│                                                            │
│   kube-apiserver ── pintu depan; SEMUA komunikasi melaluinya│
│        │                                                   │
│   etcd ───────── stor key-value: SUMBER KEBENARAN cluster  │
│                  (semua objek & keadaan dikehendaki)       │
│   kube-scheduler ── memutuskan Pod baharu berjalan di NODE MANA│
│   controller-manager ── menjalankan control loop (reconciler)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pod (app anda)   │ │  └ Pod (app anda)   │
└─────────────────────┘ └─────────────────────┘
```

## Komponen control plane

```text
kube-apiserver        Titik masuk tunggal. Mendedahkan REST API; mengesahkan &
                      menyimpan objek ke etcd. kubectl, controller, dan kubelet
                      semuanya bercakap HANYA dengan apiserver.
etcd                  Stor key-value teragih dan konsisten. Menyimpan SELURUH keadaan
                      cluster (dikehendaki + semasa). Hilang etcd = hilang cluster.
kube-scheduler        Memerhati Pod yang belum ditugaskan node dan memilih node terbaik
                      (berdasarkan resource request, affinity, taint, dsb.).
kube-controller-      Menjalankan control loop: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, dsb. Setiap gelung memacu sebenar → dikehendaki.
cloud-controller-     (Pada cloud) menyepadu dengan penyedia: load balancer, route,
manager               kitaran hayat node.
```

## Komponen worker node

```text
kubelet          Ejen node. Bercakap dengan apiserver, memulakan/menghentikan kontena
                 melalui runtime, dan melaporkan status Pod & node. Ia menjadikan realiti
                 node sepadan dengan Pod yang ditugaskan kepadanya.
kube-proxy       Memprogram rangkaian node (iptables/IPVS) supaya IP maya Service
                 diimbang beban ke endpoint Pod yang betul.
container runtime Perisian yang sebenarnya menjalankan kontena (containerd, CRI-O).
```

## Bagaimana satu "kubectl apply" mengalir melalui sistem

```text
1. kubectl → kube-apiserver: "Saya mahu satu Deployment dengan 3 replika"
2. apiserver mengesahkan & menulis objek ke etcd
3. controller-manager (controller deployment→replicaset) melihatnya, mencipta 3 objek Pod
4. scheduler melihat 3 Pod belum ditugaskan, menugaskan setiap satu ke node (tulis balik via apiserver)
5. kubelet setiap node melihat Pod-nya, menyuruh runtime menarik imej & memulakan kontena
6. kube-proxy menyambung rangkaian Service supaya trafik sampai ke Pod baharu
Segalanya ialah gelung WATCH + RECONCILE yang diantara oleh apiserver.
```

```bash
kubectl get nodes                 # senaraikan node (control-plane + worker)
kubectl get pods -n kube-system   # lihat komponen control-plane / sistem
kubectl get componentstatuses     # kesihatan kepingan control-plane teras
```

## Mengapa ia penting

Memahami pembahagian antara control plane dan worker node — serta peranan setiap komponen — ialah apa yang menukar Kubernetes daripada kotak hitam kepada sistem yang boleh anda taakul dan kendalikan, jadi ia pengetahuan teras untuk mana-mana jurutera peringkat pertengahan ke atas. **Control plane** ialah otak pembuat keputusan: **kube-apiserver** ialah pintu depan tunggal yang menjadi laluan komunikasi setiap komponen dan pengguna; **etcd** ialah stor key-value konsisten yang menyimpan seluruh keadaan cluster dan merupakan sumber kebenaran (kehilangannya bermakna kehilangan cluster); **scheduler** memutuskan node mana setiap Pod baharu mendarat; dan **controller-manager** menjalankan gelung penyelarasan yang sentiasa memacu keadaan sebenar ke arah keadaan dikehendaki. Pada setiap **worker node**, **kubelet** ialah ejen yang menjadikan kontena node sepadan dengan Pod yang ditugaskan kepadanya, **kube-proxy** memprogram rangkaian yang menjadikan IP maya Service menghala ke Pod yang betul, dan satu **container runtime** (containerd, CRI-O) sebenarnya menjalankan kontena. Melihat cara satu `kubectl apply` mengalir melalui sistem ini — apiserver ke etcd, controller mencipta objek, scheduler meletakkan Pod, kubelet memulakan kontena, kube-proxy menyambung rangkaian, semuanya sebagai gelung watch-and-reconcile — mendedahkan reka bentuk yang anggun dan konsisten di sebalik platform. Model pemikiran ini tepat apa yang anda perlukan untuk menyahpepijat mengapa satu Pod tersekat Pending (scheduler), mengapa cluster tidak bertindak balas (apiserver/etcd), atau mengapa satu Service tidak menghala (kube-proxy), menjadikannya amat diperlukan untuk mengendali dan menyelesaikan masalah cluster sebenar.

Gambaran besar

Komponen control plane

Komponen worker node

Bagaimana satu "kubectl apply" mengalir melalui sistem

Mengapa ia penting

Soalan berkaitan