Mô tả kiến trúc Kubernetes: control plane so với worker node và các thành phần của chúng.

Question

IT Interview Practice · Accepted Answer

Một cluster Kubernetes có hai loại máy: **control plane** ("bộ não" đưa ra quyết định và lưu trạng thái) và **worker node** (nơi các Pod của bạn thật sự chạy). Mỗi loại có một tập nhỏ các thành phần được định nghĩa rõ ràng.

## Bức tranh tổng thể

```text
┌──────────────── CONTROL PLANE (bộ não) ───────────────────┐
│                                                            │
│   kube-apiserver ── cửa chính; MỌI liên lạc đi qua nó      │
│        │                                                   │
│   etcd ───────── kho key-value: NGUỒN SỰ THẬT của cluster  │
│                  (mọi object & trạng thái mong muốn)       │
│   kube-scheduler ── quyết định Pod mới chạy trên NODE NÀO  │
│   controller-manager ── chạy các control loop (reconciler) │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pod (app của bạn)│ │  └ Pod (app của bạn)│
└─────────────────────┘ └─────────────────────┘
```

## Các thành phần control plane

```text
kube-apiserver        Điểm vào duy nhất. Cung cấp REST API; xác thực & lưu object
                      vào etcd. kubectl, controller, kubelet đều CHỈ nói với apiserver.
etcd                  Kho key-value phân tán, nhất quán. Giữ TOÀN BỘ trạng thái cluster
                      (mong muốn + hiện tại). Mất etcd = mất cluster.
kube-scheduler        Theo dõi các Pod chưa được gán node và chọn node tốt nhất
                      (dựa trên resource request, affinity, taint, v.v.).
kube-controller-      Chạy các control loop: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, v.v. Mỗi loop đưa thực tế → mong muốn.
cloud-controller-     (Trên cloud) tích hợp với nhà cung cấp: load balancer, route,
manager               vòng đời node.
```

## Các thành phần worker node

```text
kubelet          Tác nhân của node. Nói chuyện với apiserver, khởi động/dừng container
                 qua runtime, và báo cáo trạng thái Pod & node. Nó làm cho thực tế của
                 node khớp với các Pod được gán cho nó.
kube-proxy       Lập trình mạng của node (iptables/IPVS) để IP ảo của Service được
                 cân bằng tải tới đúng endpoint Pod.
container runtime Phần mềm thật sự chạy container (containerd, CRI-O).
```

## Một lệnh "kubectl apply" chảy qua hệ thống ra sao

```text
1. kubectl → kube-apiserver: "Tôi muốn một Deployment với 3 replica"
2. apiserver xác thực & ghi object vào etcd
3. controller-manager (deployment→replicaset controller) thấy nó, tạo 3 object Pod
4. scheduler thấy 3 Pod chưa gán, gán mỗi cái vào một node (ghi ngược lại qua apiserver)
5. kubelet của mỗi node thấy Pod của mình, bảo runtime kéo image & khởi động container
6. kube-proxy nối mạng Service để lưu lượng tới được các Pod mới
Mọi thứ là một vòng lặp THEO DÕI (WATCH) + HÒA GIẢI (RECONCILE) qua trung gian apiserver.
```

```bash
kubectl get nodes                 # liệt kê node (control-plane + worker)
kubectl get pods -n kube-system   # xem các thành phần control-plane / hệ thống
kubectl get componentstatuses     # sức khỏe của các mảnh control-plane cốt lõi
```

## Tại sao điều này quan trọng

Hiểu sự phân chia giữa control plane và worker node — cùng vai trò của từng thành phần — là thứ biến Kubernetes từ một hộp đen thành một hệ thống bạn có thể suy luận và vận hành, nên đây là kiến thức cốt lõi cho bất kỳ kỹ sư từ trung cấp trở lên. **Control plane** là bộ não ra quyết định: **kube-apiserver** là cửa chính duy nhất mà mọi thành phần và người dùng liên lạc qua; **etcd** là kho key-value nhất quán giữ toàn bộ trạng thái cluster và là nguồn sự thật (mất nó nghĩa là mất cluster); **scheduler** quyết định mỗi Pod mới đáp xuống node nào; và **controller-manager** chạy các vòng lặp hòa giải liên tục đưa trạng thái thực tế tiến về trạng thái mong muốn. Trên mỗi **worker node**, **kubelet** là tác nhân làm cho container của node khớp với các Pod được gán cho nó, **kube-proxy** lập trình mạng để IP ảo của Service định tuyến tới đúng Pod, và một **container runtime** (containerd, CRI-O) thật sự chạy container. Thấy được cách một lệnh `kubectl apply` chảy qua hệ thống này — apiserver tới etcd, controller tạo object, scheduler đặt Pod, kubelet khởi động container, kube-proxy nối mạng, tất cả đều là các vòng lặp theo dõi-và-hòa-giải — cho thấy thiết kế thanh lịch, nhất quán đằng sau nền tảng. Mô hình tư duy này chính là thứ bạn cần để gỡ lỗi vì sao một Pod kẹt ở Pending (scheduler), vì sao cluster không phản hồi (apiserver/etcd), hay vì sao một Service không định tuyến (kube-proxy), khiến nó không thể thiếu khi vận hành và xử lý sự cố các cluster thật.

Bức tranh tổng thể

Các thành phần control plane

Các thành phần worker node

Một lệnh "kubectl apply" chảy qua hệ thống ra sao

Tại sao điều này quan trọng

Câu hỏi liên quan