Kubernetes (K8s)
1. Tổng quan
A. Định nghĩa
Nền tảng điều phối container (container orchestration) mã nguồn mở tự động hóa theo cách khai báo việc triển khai·mở rộng·vận hành các ứng dụng đã được container hóa; khởi nguồn từ hệ thống nội bộ của Google (Borg) và hiện là dự án tốt nghiệp (graduated) của CNCF.
B. Bối cảnh ra đời và sự cần thiết
Docker đã chuẩn hóa container, nhưng tại hiện trường vận hành, người ta phải xử lý không phải một container mà hàng trăm đến hàng nghìn container. Việc con người quản lý thủ công chạy container nào trên máy chủ nào, ai khởi động lại khi container chết, tăng lên thế nào khi lưu lượng dồn đến là điều không thể. Khi MSA và cloud native lan rộng, độ phức tạp này bùng nổ. Kubernetes ra đời để giải bài toán "tự động hóa vận hành container quy mô lớn" này, cho phép quản trị viên chỉ cần khai báo "trạng thái mong muốn (Desired State)" là hệ thống tự duy trì trạng thái đó.
C. Đặc điểm
Triết lý cốt lõi là cấu hình khai báo (Declarative). Thay vì "hãy làm thế này (mệnh lệnh)", chỉ cần mô tả bằng YAML "phải ở trạng thái như thế này (khai báo)", Kubernetes sẽ so sánh với trạng thái hiện tại và tự điều chỉnh. Nhờ đó có thể tự phục hồi·tự động mở rộng·triển khai không gián đoạn, và vì độc lập với hạ tầng nên tính di động giữa on-premise·đa đám mây cao.
2. Kiến trúc
flowchart LR
subgraph CP[Control Plane · bộ não]
API[API Server] --- ETCD[(etcd)]
API --- SCH[Scheduler]
API --- CM[Controller Manager]
end
CP --> N1[Worker Node<br/>kubelet·kube-proxy·Pod]
CP --> N2[Worker Node<br/>kubelet·kube-proxy·Pod]
Kubernetes được chia thành Control Plane (master) đảm nhận ra lệnh·ra quyết định và Worker Node chạy các container thực tế. Sự phân tách này "tách biệt quyết định (điều khiển) với thực thi (công việc)", mang lại sự vững chắc: dù node chết thì phần điều khiển vẫn sống, và dù phần điều khiển khởi động lại thì khối lượng công việc trên node vẫn tiếp tục chạy.
- API Server: Cửa ngõ duy nhất mà mọi yêu cầu đi qua (REST). Sau khi xác thực·kiểm định sẽ ghi trạng thái vào etcd, và mọi thành phần chỉ giao tiếp thông qua API Server này.
- etcd: Kho Key-Value phân tán lưu mọi trạng thái của cụm (trạng thái mong muốn·trạng thái hiện tại). Trên thực tế đây là "nguồn sự thật duy nhất (SSOT)" của cụm, nếu bị hỏng thì toàn cụm gặp nguy nên sao lưu là bắt buộc.
- Scheduler: Quyết định bố trí Pod mới lên node nào có tính đến tài nguyên·ràng buộc (CPU·bộ nhớ·affinity).
- Controller Manager: Tập hợp các controller chạy vòng lặp điều hòa (Reconcile) sẽ giải thích ở dưới.
- kubelet: Trên mỗi node, nhận chỉ thị từ API Server để thực sự chạy·giám sát Pod.
- kube-proxy: Quản lý quy tắc mạng của node để định tuyến·cân bằng tải lưu lượng hướng tới Service về các Pod phù hợp.
| Thành phần | Vai trò |
|---|---|
| API Server | Cửa ngõ của mọi yêu cầu (REST) |
| etcd | Lưu trạng thái cụm (KV phân tán, SSOT) |
| Scheduler | Bố trí Pod lên node phù hợp |
| Controller Manager | Điều hòa trạng thái (Reconcile Loop) |
| kubelet | Chạy·quản lý Pod trên node |
| kube-proxy | Định tuyến mạng·cân bằng tải |
3. Các đối tượng cốt lõi
Mọi thứ được xử lý trong Kubernetes đều được khai báo dưới dạng "đối tượng (object)". Đơn vị nhỏ nhất không phải là container mà là Pod, nhằm gói các container liên kết chặt chẽ (ví dụ: ứng dụng + sidecar thu thập log) thành một để chia sẻ cùng mạng·lưu trữ. Pod là tạm thời (có thể chết và được tạo lại bất cứ lúc nào) nên IP thay đổi, vì vậy cần Service cung cấp điểm truy cập ổn định.
| Đối tượng | Giải thích |
|---|---|
| Pod | Đơn vị triển khai nhỏ nhất (nhóm container, tạm thời) |
| ReplicaSet/Deployment | Duy trì số bản sao·rollout·rollback |
| Service | Điểm truy cập ổn định·cân bằng tải cho tập Pod |
| Ingress | Định tuyến HTTP(S) từ bên ngoài·phân phối theo đường dẫn |
| ConfigMap/Secret | Tách cấu hình·thông tin bí mật khỏi mã |
| Namespace | Cô lập logic (đa tenant·phân tách môi trường) |
Ví dụ, khi triển khai một ứng dụng web, Deployment quản lý theo cách khai báo "3 bản sao", phía trước là Service phân tán lưu lượng tới 3 Pod, và Ingress kết nối tên miền bên ngoài tới Service này.
4. Cơ chế cốt lõi — Vòng lặp điều hòa (Reconciliation)
Nguyên lý căn bản giúp tự động hóa của Kubernetes vận hành là vòng lặp điều hòa. Mỗi controller liên tục so sánh "trạng thái đã khai báo (ví dụ: 3 bản sao)" với "trạng thái hiện tại (thực tế 2), và nếu có chênh lệch thì đưa hiện tại hội tụ về trạng thái mong muốn". Nếu node chết khiến Pod biến mất, controller phát hiện điều đó và khởi chạy Pod mới trên node khác. Nhờ có vòng lặp này, "tự phục hồi" không phải phép màu mà là tất yếu.
- Tự động mở rộng: Ứng phó linh hoạt với nhu cầu bằng HPA (tăng giảm số Pod theo chiều ngang theo tải)·VPA (điều chỉnh yêu cầu tài nguyên theo chiều dọc)·Cluster Autoscaler (tăng giảm chính số node).
- Cập nhật cuốn chiếu/rollback: Thay dần Pod phiên bản mới để triển khai không gián đoạn, và khi có sự cố thì rollback ngay về revision trước.
5. Các điểm cần cân nhắc và hàm ý
- Độ phức tạp vận hành: Mạnh mẽ bao nhiêu thì đường cong học tập dốc bấy nhiêu. Vì thế thay vì tự xây dựng, nhiều trường hợp dùng dịch vụ được quản lý (EKS·GKE·AKS) để giảm gánh nặng vận hành Control Plane.
- Bảo mật: Cấu hình mặc định khá dễ dãi nên bắt buộc phải áp dụng RBAC (tối thiểu hóa quyền)·chính sách mạng·quét lỗ hổng image.
- Khả năng quan sát: Pod sinh ra và mất đi liên tục nên giám sát như Prometheus·Grafana·thu thập log là thiết yếu cho vận hành.
- Hạ tầng tiêu chuẩn·triển vọng: Kubernetes là nền tảng tiêu chuẩn trên thực tế của MSA·DevOps·CI/CD, và tự động hóa triển khai đang mở rộng với GitOps (ArgoCD, v.v.) — lấy kho Git làm nguồn của trạng thái mong muốn.
Tóm tắt một câu: Kubernetes là nền tảng điều phối tự động hóa theo cách khai báo việc triển khai·mở rộng·vận hành container, trong đó Control Plane và Node liên tục đưa Pod hội tụ về trạng thái mong muốn bằng vòng lặp điều hòa (Reconcile), và cùng với dịch vụ được quản lý·GitOps đã trở thành hạ tầng tiêu chuẩn của cloud native.