Bài 2. Kubernetes hoạt động như thế nào? Hiểu kiến trúc chỉ trong 15 phút
"Muốn sử dụng Kubernetes hiệu quả, bạn không cần nhớ hàng chục thành phần ngay từ đầu. Chỉ cần hiểu ai làm việc gì trong hệ thống là đủ."
Ở bài trước, chúng ta đã biết vì sao Kubernetes ra đời: để quản lý hàng trăm, thậm chí hàng nghìn container một cách tự động.
Nhưng một câu hỏi mới lại xuất hiện:
Kubernetes thực sự hoạt động như thế nào?
Trong bài viết này, chúng ta sẽ cùng nhìn vào "bộ máy" bên trong Kubernetes theo cách đơn giản nhất.
Hãy tưởng tượng Kubernetes như một công ty
Thay vì nghĩ đến những thuật ngữ phức tạp, hãy tưởng tượng Kubernetes là một công ty.
- Bạn là khách hàng.
- Control Plane là ban quản lý.
- Worker Node là các nhân viên thực hiện công việc.
Bạn không cần đi tìm từng nhân viên để giao việc.
Bạn chỉ cần nói với quản lý:
"Tôi muốn chạy 3 bản sao của ứng dụng."
Ban quản lý sẽ tự phân công nhân viên thực hiện.
Đó chính là triết lý của Kubernetes.
1. Kiến trúc tổng quan

Một Kubernetes Cluster luôn có hai phần chính:
- Control Plane
- Worker Node
Chỉ cần nhớ hai thành phần này là bạn đã hiểu hơn 80% kiến trúc Kubernetes.
2. Control Plane - Bộ não của Kubernetes
Control Plane giống như ban quản lý.
Nó không chạy ứng dụng, mà chịu trách nhiệm ra quyết định.
Ví dụ:
- Ứng dụng nên chạy ở đâu?
- Có bao nhiêu Pod?
- Pod nào bị lỗi?
- Có cần tạo Pod mới không?
Mọi quyết định đều được Control Plane xử lý.
API Server - Cánh cửa chính
Mỗi khi bạn gõ:
kubectl apply -f deployment.yaml
Lệnh này không đi thẳng tới Worker Node.
Nó sẽ gửi yêu cầu tới API Server.
Bạn có thể xem API Server như quầy tiếp nhận yêu cầu.
Mọi thao tác đều phải đi qua đây.
etcd - Bộ nhớ của Kubernetes
Sau khi nhận yêu cầu, Kubernetes cần lưu lại mong muốn của bạn.
Ví dụ:
Tôi muốn có 3 Pod.
Thông tin này được lưu trong etcd.
Bạn có thể tưởng tượng etcd giống như cuốn sổ ghi chép của Kubernetes.
Scheduler - Người phân công công việc
Giả sử Cluster có 3 máy chủ.
Scheduler sẽ quyết định:
Pod này nên chạy ở máy nào?
Nó sẽ xem xét:
- Node nào còn tài nguyên?
- Node nào phù hợp?
- Node nào đang quá tải?
Rồi chọn nơi tốt nhất.
Controller Manager - Người luôn kiểm tra mọi thứ
Giả sử bạn muốn:
Có 3 Pod.
Nhưng vì một lý do nào đó chỉ còn 2 Pod.
Controller sẽ phát hiện:
Thiếu mất 1 Pod.
Và ngay lập tức tạo thêm một Pod mới.
Đây là lý do Kubernetes luôn cố gắng giữ hệ thống ở trạng thái mong muốn (Desired State).
3. Worker Node - Nơi ứng dụng thực sự chạy
Nếu Control Plane là ban quản lý thì Worker Node là nơi công việc được thực hiện.
Mỗi Worker Node thường có:
- Kubelet
- Container Runtime
- Các Pod
Ứng dụng của bạn sẽ chạy tại đây.
Kubelet - Người thực thi mệnh lệnh
Kubelet giống như một nhân viên.
Nó nhận lệnh từ Control Plane:
Hãy chạy Pod này.
Kubelet sẽ:
- tải image
- tạo container
- kiểm tra Pod còn sống hay không
- báo cáo trạng thái về Control Plane
Container Runtime
Đây là thành phần chịu trách nhiệm chạy container.
Hiện nay phổ biến nhất là:
- containerd
- CRI-O
Bạn chỉ cần biết:
Container Runtime là "động cơ" giúp container thực sự chạy trên máy.
4. Toàn bộ quá trình diễn ra như thế nào?
Khi bạn deploy ứng dụng:

kubectl apply → API Server → etcd lưu trạng thái mong muốn → Scheduler chọn Worker Node → Kubelet tạo Pod → Container Runtime chạy Container
Toàn bộ quá trình này thường chỉ diễn ra trong vài giây.
Điều quan trọng nhất cần nhớ
Nếu chỉ nhớ một điều sau bài viết này, hãy nhớ:
Control Plane quyết định. Worker Node thực hiện.
Hay ngắn gọn hơn:
Control Plane
↓
Ra quyết định
Worker Node
↓
Chạy ứng dụng
Chỉ với hai khái niệm này, bạn đã có nền tảng để hiểu gần như mọi thành phần khác của Kubernetes.
Tổng kết
Trong bài này, chúng ta đã làm quen với "bộ máy" của Kubernetes:
- Control Plane là bộ não điều khiển toàn bộ Cluster.
- API Server nhận mọi yêu cầu từ người dùng.
- etcd lưu trạng thái của hệ thống.
- Scheduler quyết định Pod sẽ chạy ở đâu.
- Controller đảm bảo hệ thống luôn đúng với mong muốn.
- Worker Node là nơi ứng dụng thực sự được chạy.
- Kubelet nhận lệnh và tạo Pod trên từng máy.
Đừng lo nếu bạn chưa nhớ hết các thành phần này. Trong những bài tiếp theo, chúng ta sẽ gặp lại chúng nhiều lần và dần hiểu rõ vai trò của từng thành phần.
👉 Bài tiếp theo: Pod là gì? Tại sao Kubernetes không chạy Container mà lại chạy Pod?
All rights reserved