Kubernetes: Kiến trúc và các thành phần

Bài viết này cũng có bản English.

Hi các bạn 👋. Mình là Hùng Anh.

Đây là bài thứ năm trong series Kubernetes Fundamentals. Ở bài trước, mình kết thúc bằng 1 câu hỏi: khi container rải rác trên hàng chục, hàng trăm máy, ai sẽ là người quyết định container nào chạy ở đâu, tự khởi động lại khi nó chết, hay scale thêm khi tải tăng? Đó chính xác là bài toán Kubernetes sinh ra để giải quyết.

Bài này sẽ hơi khác các bài trước 1 chút — thay vì giải quyết đúng 1 bài toán cụ thể, nó giống 1 tấm bản đồ: 1 cluster Kubernetes thực sự gồm những mảnh nào, và mỗi mảnh làm nhiệm vụ gì?

Bắt đầu thôi.

1. Nhìn tổng quan 1 Cluster

1 cluster Kubernetes gồm 2 loại máy phối hợp với nhau:

Control Plane — bộ não. Nó ra quyết định: cái gì cần chạy, chạy ở đâu, và trạng thái hiện tại của cluster có khớp với điều đó hay chưa.
Node — cơ bắp. Mỗi node là 1 máy (vật lý hoặc ảo) thực sự chạy container của bạn, được gom lại bên trong các Pod.

Control Plane không bao giờ tự chạy code ứng dụng của bạn — nó chỉ ra lệnh cho node làm việc đó. Từ đây trở đi, mọi thứ chỉ là trả lời: bên trong 2 cái hộp đó cụ thể có những gì?

2. Các thành phần của Control Plane

kube-apiserver — cửa chính. Nó expose Kubernetes API, và gần như mọi thứ khác — kể cả kubectl, mọi thành phần khác trong Control Plane, và mọi node — đều chỉ nói chuyện với cluster thông qua nó.
etcd — 1 key-value store nhất quán, có tính sẵn sàng cao. Đây là nơi toàn bộ trạng thái của cluster thực sự được lưu; mất etcd nghĩa là mất cả cluster.
kube-scheduler — theo dõi các Pod mới tạo mà chưa được gán node, rồi chọn ra node nào sẽ chạy chúng.
kube-controller-manager — chạy các controller: những vòng lặp chạy ngầm, liên tục theo dõi trạng thái thực tế của cluster và điều chỉnh nó về đúng trạng thái bạn mong muốn (ví dụ: "phải có đúng 3 bản sao của Pod này đang chạy" — nếu 1 cái chết, controller phát hiện và tự tạo 1 cái mới).
cloud-controller-manager — chỉ xuất hiện khi chạy trên 1 cloud provider (AWS, GCP, Azure...). Nó xử lý phần đặc thù của cloud, ví dụ tự tạo 1 load balancer, để phần còn lại của Kubernetes không cần biết mình đang chạy trên cloud nào.

3. Các thành phần trên Node

kubelet — agent chạy trên mỗi node. Nó nói chuyện với Control Plane và đảm bảo các container được mô tả cho node đó thực sự đang chạy và khỏe mạnh.
kube-proxy — duy trì các network rule trên mỗi node, cho phép traffic đi đúng tới Pod thông qua 1 Kubernetes Service.
Container runtime — chính là container runtime đã nói ở bài trước (containerd, CRI-O...), phần thực sự tạo và chạy các container mà kubelet yêu cầu.

4. Addons

Addons không phải là phần lõi của Kubernetes, nhưng thiếu chúng thì cluster gần như không dùng được:

DNS — cấp cho mỗi Service 1 tên DNS để các Pod khác tra cứu, thay vì phải hardcode địa chỉ IP.
Dashboard — web UI để xem và quản lý cluster.
Monitoring & Logging — thu thập metric và log của container về 1 nơi tập trung để bạn thực sự tìm kiếm và xem biểu đồ được.
Network Plugins (CNI) — phải tự cài thêm riêng; đây là thứ thực sự cấp IP cho Pod và cho phép chúng nói chuyện với nhau qua các node.

5. Tổng kết

1 cluster gồm 2 loại máy: Control Plane quyết định cái gì cần chạy và chạy ở đâu (kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager), và Node thực sự chạy nó (kubelet, kube-proxy, container runtime) — cùng các addon như DNS, dashboard, monitoring, và networking lấp đầy phần còn lại.

Đó là toàn bộ tấm bản đồ. Từ đây, series sẽ chuyển từ "1 cluster gồm những gì" sang "làm sao để mô tả đúng thứ mình muốn nó chạy" — Pod, Deployment, và Service.

Happy reading! 🍵