1 Visual Flow Diagram
2 Giải thích bằng ví dụ đời thực
Hãy tưởng tượng Kubernetes như một **Nhà Hàng Cao Cấp**:
- kubectl Khách hàng viết yêu cầu món ăn vào tờ order.
- API Server Lễ tân tiếp nhận order, kiểm tra xem khách có tiền không (Auth) và tờ giấy có viết đúng mẫu không.
- etcd Sổ cái ghi chép. Mọi order đều phải được ghi vào sổ thì mới được coi là "đã nhận".
- Scheduler Quản lý bếp, xem thử đầu bếp nào đang rảnh (Node nào còn trống tài nguyên) để giao việc.
- kubelet Bếp trưởng tại mỗi trạm, nhận lệnh từ quản lý và đôn đốc công nhân nấu ăn.
- Runtime Các thiết bị nấu bếp (lò vi sóng, chảo...) trực tiếp tạo ra món ăn (Container).
3 Nhập vai (Dialogue)
4 Quy trình kỹ thuật thực tế (Technical Workflow)
Bước 1: kubectl Authentication & Validation
Người dùng chạy lệnh `kubectl apply`. Công cụ sẽ gửi một **HTTP POST** request chứa manifest YAML tới `kube-apiserver`.
Bước 2: etcd Persistence
`kube-apiserver` kiểm tra quyền (RBAC) và ghi dữ liệu vào `etcd`. Chỉ khi ghi thành công vào `etcd`, yêu cầu mới được coi là chính thức.
Bước 3: Resource Scheduling
`kube-scheduler` liên tục **watch** API Server. Nó phát hiện một Pod mới có `nodeName` trống. Nó tính toán các thuật toán (filtering & scoring) để chọn Node tối ưu nhất.
Bước 4: Kubelet Execution
`kubelet` trên Node được chọn phát hiện có Pod được gán cho mình. Nó gọi **CRI (Container Runtime Interface)** để khởi tạo container.
Declarative Model
K8s không chạy lệnh một lần rồi thôi. Nó liên tục so sánh **Desired State** (YAML) với **Actual State** (Thực tế) để tự động sửa lỗi.
Watch Mechanism
Thay vì hỏi liên tục (polling), các component sử dụng cơ chế **watch** (HTTP long streaming) để nhận thông báo ngay lập tức khi `etcd` thay đổi.
High Availability
Nếu `kubelet` chết, `controller-manager` sẽ nhận ra và yêu cầu `scheduler` tìm một Node khác để hồi sinh Pod. Đó là khả năng **Self-healing**.