Inside the Brain: ETCD & API Server

"Kubernetes không phải là magic. Nó chỉ là một vòng lặp vô tận của việc so sánh và sửa sai."

Nếu coi Kubernetes Cluster là một cơ thể sống, thì Control Plane chính là bộ não. Và sâu thẳm trong bộ não đó, có hai vùng quan trọng nhất, nơi nắm giữ mọi sự thật và quyền lực: ETCD và API Server.

Hiểu tường tận về cặp đôi này không chỉ giúp bạn debug tốt hơn mà còn là chiếc chìa khóa để bước vào thế giới của High Availability và System Design hạng nặng.

1. API Server (Kube-Apiserver): The Gatekeeper

Trong một thế giới đầy rẫy các microservices và controllers, quy tắc vàng của Kubernetes là:

"Không ai được phép nói chuyện trực tiếp với ETCD, ngoại trừ API Server."

Kube-apiserver là component duy nhất "hướng ngoại". Nó là cánh cổng, là người gác đền cho mọi yêu cầu thay đổi trạng thái của Cluster.

Luồng xử lý một Request (The Flow of Truth)

Khi bạn gõ kubectl run nginx --image=nginx, điều gì thực sự xảy ra? API Server không nhắm mắt làm ngơ mà thực hiện một quy trình kiểm soát nghiêm ngặt:

1. Authentication (Xác thực - "Bạn là ai?"):

   • API Server kiểm tra client certificate, bearer token, hoặc proxy auth.
   • User hay Service Account? Nếu không định danh được -> 401 Unauthorized.

2. Authorization (Phân quyền - "Bạn được phép làm gì?"):

   • Đã biết bạn là ai, giờ xem bạn có quyền tạo Pod không?
   • Cơ chế RBAC (Role-Based Access Control) được kích hoạt.
   • Không có quyền ghi vào namespace production? -> 403 Forbidden.

3. Admission Control (Kiểm duyệt - "Yêu cầu có hợp lệ không?"):

   • Đây là lớp phòng thủ cuối cùng. Ngay cả khi bạn là Admin, bạn vẫn có thể bị chặn.
   • Mutating Webhooks: Có thể tự động tiêm thêm sidecar container (như Istio) hoặc set default resource limit.
   • Validating Webhooks: Kiểm tra compliance, ví dụ: "Image này có từ private registry an toàn không?", "Pod này có chạy quyền root không?".
   • Vi phạm chính sách -> Request bị từ chối.

Chỉ khi vượt qua 3 ải này, API Server mới thực sự ghi dữ liệu vào ETCD.

2. ETCD: The Critical Core

Nếu API Server là "Bộ xử lý trung tâm" (CPU) thì ETCD chính là "Bộ nhớ dài hạn" (Hard Drive/Brain Memory).

ETCD không phải là database thông thường. Đừng so sánh nó với MySQL hay PostgreSQL. Nó là Consistent Key-Value Store phân tán.

• Key-Value: Đơn giản, nhanh.
• Strong Consistency: Khi một node đọc được dữ liệu, nó phải là dữ liệu mới nhất. Không có chuyện "eventually consistent" (nhất quán lỏng lẻo) ở đây. Kubernetes không chấp nhận sự mơ hồ.

Luật chơi của Quorum (Số đại biểu)

Tại sao Production Cluster luôn yêu cầu số lẻ các node chạy ETCD (3, 5, 7)?

Đó là vì cơ chế đồng thuận Raft Consensus Algorithm. Để một dữ liệu được coi là "đã ghi thành công", quá bán (majority) số node phải đồng ý.

Công thức tính Quorum: (N / 2) + 1

• Cluster 3 nodes: Cần 2 node sống để hoạt động. Chấp nhận chết 1.
• Cluster 5 nodes: Cần 3 node sống. Chấp nhận chết 2.
• Tại sao không phải 4?: 4 nodes thì Quorum là 3. Nếu mạng bị chia cắt (Network Partition) thành 2-2. Không bên nào đủ 3 phiếu -> Brain Split (Chết não). Cả cluster dừng hoạt động.

CAUTION

Mất ETCD là mất tất cả. Nếu dữ liệu trong ETCD bị corrupt hoặc mất mà không có backup, Cluster của bạn coi như "reset factory". Toàn bộ trạng thái về Pod đang chạy ở đâu, Service nào trỏ đi đâu... sẽ biến mất. Worker node vẫn chạy container cũ, nhưng bộ não đã quên mất chúng là ai.

3. The Declarative Model (Mô hình Khai báo)

Sức mạnh thực sự của Kubernetes nằm ở đây. Chúng ta không ra lệnh (Imperative - "Làm A, rồi làm B"), chúng ta khai báo mong muốn (Declarative - "Tôi muốn kết quả C").

• Desired State (Trạng thái mong muốn): Những gì bạn viết trong file YAML và gửi cho API Server. Dữ liệu này nằm trong ETCD.
• Current State (Trạng thái hiện tại): Những gì đang thực sự diễn ra trên các Worker Node.

API Server: The Diff Checker

API Server (cùng với Controller Manager) đóng vai trò là một vòng lặp đối chiếu vô tận:

1. Watch Loop: Liên tục theo dõi sự thay đổi trong ETCD.
2. Compare: So sánh Desired State vs Current State.
3. Reconcile: Nếu thấy lệch (Diff), ra lệnh cho Kubelet hoặc Controller liên quan để sửa lại cho khớp.

Ví dụ:

1. Bạn khai báo replicas: 3.
2. ETCD lưu replicas: 3.
3. 1 Pod bị crash. Current State còn 2.
4. Controller thấy 2 != 3.
5. Controller ra lệnh tạo thêm 1 Pod mới.
6. Hệ thống quay về trạng thái cân bằng (Converged).

---

Tổng kết

Khi bạn nhìn vào Kubernetes, hãy nhớ nguyên lý cốt lõi này: API Server là cửa ngõ duy nhất, ETCD là sự thật duy nhất. Mọi thứ còn lại chỉ là các worker cố gắng làm hài lòng hai "vị thần" này. Bảo vệ an toàn cho ETCD và kiểm soát chặt chẽ API Server chính là bảo vệ sự sống còn của cả hệ thống.