Cluster Architecture

Bài này vẽ bức tranh tổng thể của một cluster Kubernetes. Mỗi thành phần ở đây sẽ được đi sâu trong các bài tiếp theo của phần Cluster Architecture.

1. Kubernetes là gì?

Kubernetes (viết tắt K8s) là công cụ giúp tự động hóa việc triển khai, scale và vận hành ứng dụng chạy trong container.

Thay vì tự SSH vào từng máy để chạy docker run, bạn chỉ cần khai báo trạng thái mong muốn (ví dụ "chạy 3 bản nginx"), Kubernetes tự lo phần còn lại: chọn máy để chạy, khởi động lại khi container chết, chia tải, cập nhật phiên bản mới.

2. Khi nào nên dùng Kubernetes?

Tình huống	Kubernetes giúp gì
Dự án lớn	Quản lý hàng trăm container trên nhiều máy từ một chỗ
Nhu cầu scale cao	Tăng/giảm số Pod bằng một lệnh hoặc tự động theo tải (HPA)
Triển khai đa môi trường	Cùng một bộ YAML chạy ở dev, staging, production, on-prem hay cloud
Microservices	Mỗi service là một Deployment riêng, gọi nhau qua Service và DNS nội bộ
Self-healing	Container chết thì tạo lại, node chết thì chuyển Pod sang node khác

3. Kiến trúc tổng thể

Một cluster gồm hai phần chính:

Control Plane (Master Node): "bộ não", quản lý toàn cluster, quyết định Pod chạy ở đâu và giữ cho mọi thứ đúng như khai báo.
Data Plane (các Worker Node): "cơ bắp", nơi Pod của ứng dụng thật sự chạy.

Nhóm	Thành phần	Vai trò ngắn gọn
Control Plane	`kube-apiserver`	Cổng vào duy nhất của cluster
	`etcd`	Cơ sở dữ liệu lưu toàn bộ trạng thái cluster
	`kube-scheduler`	Chọn node cho Pod mới
	`kube-controller-manager`	Giữ trạng thái thực tế khớp với trạng thái mong muốn
	`cloud-controller-manager`	Làm việc với cloud provider (chỉ có khi chạy trên cloud)
Mọi node	`kubelet`	Agent trên node, nhận việc và chạy Pod
	`kube-proxy`	Chuyển tiếp traffic của Service tới Pod
	Container runtime	Tải image và chạy container (containerd, CRI-O)

💡 Ứng dụng chạy ở đâu?

Ứng dụng có thể chạy trên cả master lẫn worker, nhưng best practice là chỉ chạy trên worker. Với kubeadm, master có sẵn taint node-role.kubernetes.io/control-plane:NoSchedule để chặn Pod thường.

4. Control Plane

4.1. etcd

etcd là một key-value database phân tán, lưu toàn bộ trạng thái của cluster:
- Các node và Pod đã được khai báo.
- Cấu hình Deployment, Service.
- ConfigMap, Secret.
- Trạng thái được báo cáo của các tài nguyên.
Mọi lệnh kubectl get thực chất là đọc dữ liệu từ etcd (thông qua API server).

Ghi nhớ

Các thành phần Kubernetes không đọc và ghi trực tiếp vào etcd. Tất cả đi qua kube-apiserver. Đây là lý do khi apiserver chết, cả cluster "đứng hình" dù etcd vẫn sống.

Chi tiết: ETCD.

4.2. kube-apiserver

Là entrypoint của K8s cluster: mọi yêu cầu, từ Admin hay từ các thành phần bên trong, đều đi qua đây.
Khi Admin yêu cầu triển khai ứng dụng, chính API server tiếp nhận, xác thực, kiểm tra request rồi lưu vào etcd.
Scheduler, controller-manager và kubelet đều giao tiếp với nhau gián tiếp qua API server.

User → kubectl → kube-apiserver → etcd

Chi tiết: kube-apiserver.

4.3. kube-scheduler

Scheduler theo dõi những Pod chưa được gán node, rồi chọn node phù hợp nhất dựa trên:
- Lượng CPU và RAM Pod yêu cầu (resources.requests).
- Tài nguyên còn có thể cấp phát trên node.
- Các ràng buộc như node affinity, taints và tolerations.
Scheduler chỉ quyết định Pod chạy ở đâu (ghi tên node vào Pod). Nó không làm việc trực tiếp với worker node; việc chạy Pod là của kubelet.

Pod yêu cầu 2 CPU
├── Node A: còn có thể cấp phát 1 CPU → không phù hợp
└── Node B: còn có thể cấp phát 4 CPU → có thể được chọn

Scheduler lấy dữ liệu ở đâu?

Scheduler không đọc etcd trực tiếp. Nó watch API server để biết Pod nào chưa có node và node nào còn bao nhiêu tài nguyên, rồi ghi kết quả lại qua API server. Một số sơ đồ vẽ mũi tên Scheduler → etcd là để nói về nguồn dữ liệu, không phải kết nối thật.

Chi tiết: kube-scheduler.

4.4. kube-controller-manager

Là thành phần quản lý, xử lý các tác vụ bên trong cluster để đảm bảo các tài nguyên hoạt động đúng như mong muốn.
Làm việc trực tiếp với API server theo một vòng lặp không ngừng:

Ví dụ: khai báo cần 3 bản sao ứng dụng. Nếu chỉ còn 2 Pod hoạt động, controller tương ứng sẽ tạo thêm 1 Pod để đưa hệ thống về số lượng mong muốn.
Các controller thường chạy trong kube-controller-manager:

Controller	Việc làm
Node controller	Theo dõi tình trạng node, phản ứng khi node không còn sẵn sàng
Deployment controller	Tạo và quản lý ReplicaSet, điều phối cập nhật phiên bản
ReplicaSet controller	Giữ đủ số Pod theo `replicas`
EndpointSlice controller	Cập nhật danh sách Pod phía sau mỗi Service
Namespace, ServiceAccount, Job…	Mỗi loại object có controller riêng

Chi tiết: kube-controller-manager.

4.5. cloud-controller-manager

Khi cluster chạy trên cloud (AWS, GCP, Azure), cloud-controller-manager chứa các controller cần gọi API của cloud provider:

Controller	Ví dụ trên AWS
Node	Node EC2 bị xóa → xóa object Node khỏi cluster
Route	Cấu hình route trong VPC cho mạng Pod
Service	Service `type: LoadBalancer` → tạo ELB/NLB

ghi chú

Cluster lab dựng bằng kubeadm trên VMware không có cloud-controller-manager. Đó là lý do Service LoadBalancer trên lab bị EXTERNAL-IP <pending> (xem LoadBalancer).

5. Worker Node (Data Plane)

5.1. kubelet – người quản lý node

kubelet là agent chạy trên mỗi node, quản lý mọi thứ bên trong node đó. Nó:
1. Theo dõi các Pod được gán cho node của mình qua API server.
2. Yêu cầu container runtime chạy các container cần thiết.
3. Theo dõi tình trạng Pod và container (restart khi chết, chạy probe).
4. Báo cáo trạng thái Pod và node về API server.

Chi tiết: kubelet.

5.2. kube-proxy

kube-proxy chạy trên mỗi node, thực hiện một phần chức năng của Service: chuyển traffic gửi tới Service sang các Pod phía sau.

Web App → Service Database → Pod Database

Phân biệt CNI và kube-proxy

Plugin mạng CNI (Calico, Flannel…): thiết lập mạng cho Pod, cấp IP và cho Pod ở các node khác nhau nói chuyện được với nhau.
kube-proxy: chỉ lo cơ chế chuyển tiếp lưu lượng của Service.

Nhiều người tưởng kube-proxy phụ trách toàn bộ việc giao tiếp giữa các node, nhưng đó là việc của CNI.

Chi tiết: kube-proxy.

5.3. Container runtime – chạy container

Runtime thực hiện các thao tác như tải image, tạo, khởi động và dừng container.
kubelet nói chuyện với runtime qua chuẩn CRI (Container Runtime Interface).
Các runtime thường gặp: containerd và CRI-O.

Chi tiết: Docker - containerd - runc - CRI/OCI.

6. Cluster Lab

kubectl get nodes -o wide
kubectl get pods -n kube-system -o wide

NAME                                 READY   STATUS    NODE
etcd-k8s-master                      1/1     Running   k8s-master
kube-apiserver-k8s-master            1/1     Running   k8s-master
kube-controller-manager-k8s-master   1/1     Running   k8s-master
kube-scheduler-k8s-master            1/1     Running   k8s-master
kube-proxy-xxxxx                     1/1     Running   k8s-worker1
calico-node-xxxxx                    1/1     Running   k8s-worker1
coredns-xxxxxxxxxx-xxxxx             1/1     Running   k8s-worker2

Bạn thấy	Nghĩa là
Pod có hậu tố `-k8s-master`	Static pod của control plane, do kubelet trên master chạy từ file trong `/etc/kubernetes/manifests/`
`kube-proxy`, `calico-node` có trên mọi node	Chạy bằng DaemonSet
Không thấy `kubelet`	kubelet chạy bằng systemd, kiểm tra bằng `systemctl status kubelet`
Không thấy `cloud-controller-manager`	Lab không chạy trên cloud

1. Kubernetes là gì?​

2. Khi nào nên dùng Kubernetes?​

3. Kiến trúc tổng thể​

4. Control Plane​

4.1. etcd​

4.2. kube-apiserver​

4.3. kube-scheduler​

4.4. kube-controller-manager​

4.5. cloud-controller-manager​

5. Worker Node (Data Plane)​

5.1. kubelet – người quản lý node​

5.2. kube-proxy​

5.3. Container runtime – chạy container​

6. Cluster Lab​