Kiến Trúc Kubernetes: Control Plane và Node
Trước khi gõ lệnh đầu tiên, ta nên biết mình đang nói chuyện với cái gì. Một cluster Kubernetes chia làm hai phần rõ rệt: control plane — bộ não ra quyết định, và các node — nơi ứng dụng thật sự chạy. Hiểu sơ đồ này một lần thì mọi lệnh kubectl về sau đều có chỗ để đặt vào.
Series này không đào sâu nội tại từng thành phần (cách etcd đồng thuận, scheduler chấm điểm node ra sao...) — đó là chuyện của series chuyên sâu sau. Ở đây ta nắm vai trò mỗi mảnh và cách chúng phối hợp.
Bức tranh tổng thể
┌──────────────── CONTROL PLANE (bộ não) ───────────────┐
│ │
kubectl ──(YAML)──► │ kube-apiserver ◄──► etcd (lưu trạng thái cluster) │
│ ▲ │
│ │ scheduler (chọn node cho pod) │
│ │ controller-manager (giữ desired state) │
└────────┼──────────────────────────────────────────────┘
│ (mệnh lệnh xuống node)
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─── NODE 1 ───┐ ┌─── NODE 2 ───┐ ┌─── NODE 3 ───┐
│ kubelet │ │ kubelet │ │ kubelet │
│ kube-proxy │ │ kube-proxy │ │ kube-proxy │
│ [container] │ │ [container] │ │ [container] │
└──────────────┘ └──────────────┘ └──────────────┘
Quy tắc vàng để nhớ: mọi thứ đi qua kube-apiserver. kubectl không bao giờ nói chuyện trực tiếp với node; nó gửi yêu cầu tới API server. Các thành phần khác cũng vậy. API server là cánh cổng duy nhất ra vào cluster.
Control plane: bộ não
Bốn thành phần chính, mỗi cái một việc:
- kube-apiserver — mặt tiền của cluster. Mọi lệnh (
kubectl, các controller, kubelet) đều đi qua đây. Nó nhận yêu cầu, xác thực, kiểm tra hợp lệ, rồi ghi vào etcd. Là thành phần duy nhất nói chuyện trực tiếp với etcd. - etcd — cơ sở dữ liệu key-value lưu toàn bộ trạng thái cluster: bạn đã khai báo gì, hiện có gì đang chạy. Nếu ví cluster là một cơ thể thì etcd là trí nhớ. Mất etcd là mất cluster — nên ở production nó được sao lưu cẩn thận.
- kube-scheduler — khi có một pod mới chưa được gán node, scheduler quyết định nó chạy ở node nào, dựa trên tài nguyên còn trống, ràng buộc, ái lực... Nó chỉ chọn, không tự khởi container.
- kube-controller-manager — chạy các control loop (nhớ Bài 0): liên tục so sánh trạng thái mong muốn với thực tế và hành động để khớp lại. Ví dụ controller của ReplicaSet đảm bảo "muốn 3 bản sao thì luôn có 3".
(Trên cloud còn có cloud-controller-manager để nói chuyện với hạ tầng nhà cung cấp — tạo load balancer, volume... Trên minikube ta không cần bận tâm.)
Node: nơi ứng dụng chạy
Node là máy (thật hoặc ảo) chạy workload của bạn. Mỗi node có:
- kubelet — "đại diện" của Kubernetes trên mỗi node. Nó nhận từ API server danh sách pod cần chạy trên node mình, rồi ra lệnh cho container runtime (Docker/containerd) khởi container, và báo cáo ngược tình trạng sức khỏe lên control plane.
- kube-proxy — lo phần mạng: duy trì luật mạng để Service (Bài 5) định tuyến lưu lượng tới đúng pod, kể cả khi pod thay đổi. Đây là mảnh khiến "một địa chỉ ổn định cho nhiều pod" hoạt động được.
- container runtime — phần mềm thật sự chạy container (containerd, CRI-O, hoặc Docker). Kubernetes nói chuyện với nó qua chuẩn CRI.
Một chi tiết hay: bản thân các thành phần control plane trong minikube cũng chạy dưới dạng pod — Kubernetes tự vận hành chính nó. Ta soi được điều đó ngay.
Soi kiến trúc thật trong minikube
kubectl cluster-info cho thấy control plane đang chạy ở đâu:
Kubernetes control plane is running at https://127.0.0.1:50639
CoreDNS is running at https://127.0.0.1:50639/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Và đây là phần thú vị — liệt kê pod trong namespace kube-system (nơi các thành phần hệ thống sống), ta thấy đúng những cái tên vừa học:
kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-7d764666f9-4hhdj 1/1 Running 0 37s
etcd-minikube 1/1 Running 0 43s
kube-apiserver-minikube 1/1 Running 0 43s
kube-controller-manager-minikube 1/1 Running 0 44s
kube-proxy-npmxl 1/1 Running 0 37s
kube-scheduler-minikube 1/1 Running 0 43s
storage-provisioner 1/1 Running 0 42s
Cả bộ não nằm gọn ở đây: etcd, kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy. Thêm hai cái đáng nói:
- coredns — DNS nội bộ của cluster. Nhờ nó mà một pod gọi service khác bằng tên (
my-service) thay vì IP. Sẽ rõ ở Bài 5. - storage-provisioner — addon của minikube tự cấp phát ổ đĩa khi bạn xin (Bài 8).
Vì minikube chỉ một node, node đó vừa là control plane vừa chạy workload. Cluster production tách riêng: node control plane không chạy ứng dụng người dùng. Nhưng vai trò các thành phần thì giống hệt.
Một yêu cầu đi qua hệ thống thế nào
Ghép lại bằng một ví dụ — khi bạn bảo "chạy 3 bản sao ứng dụng":
1. kubectl gửi YAML lên ──► kube-apiserver
2. apiserver ghi "muốn 3 bản sao" ──► etcd
3. controller-manager thấy: muốn 3, đang có 0 ──► tạo 3 pod (ghi qua apiserver)
4. scheduler thấy 3 pod chưa có node ──► gán mỗi pod vào một node
5. kubelet ở node đó hỏi apiserver "có pod nào của tôi?" ──► khởi container
6. kube-proxy cập nhật luật mạng để truy cập được
Không thành phần nào "chỉ huy" thành phần khác trực tiếp. Tất cả đọc/ghi trạng thái qua API server và phản ứng — một kiến trúc lỏng lẻo nhưng bền bỉ. Đây cũng là lý do Kubernetes tự chữa lành tốt: mỗi controller cứ lặng lẽ kéo phần việc của mình về đúng trạng thái mong muốn.
Tổng kết
Cluster Kubernetes gồm control plane (bộ não) và các node (cơ bắp). Control plane có kube-apiserver (cổng duy nhất, mọi thứ đi qua), etcd (lưu toàn bộ trạng thái), scheduler (chọn node cho pod) và controller-manager (chạy control loop giữ desired state). Mỗi node có kubelet (chạy & báo cáo pod), kube-proxy (mạng cho Service) và container runtime. Trong minikube, chính các thành phần này chạy dưới dạng pod ở kube-system — ta soi tận mắt được. Điểm cần khắc cốt: mọi tương tác đều qua API server, và hệ thống vận hành bằng các vòng lặp khớp trạng thái.
Đủ lý thuyết. Bài 2 ta cài minikube + kubectl cho bài bản và chạy những lệnh đầu tiên trên cluster của chính mình.