Control plane và reconciliation loops

Kubernetes vận hành bằng mô hình desired state: client ghi trạng thái mong muốn qua API server, các controller độc lập quan sát trạng thái hiện tại và lặp lại hành động cho tới khi hệ thống tiến gần về trạng thái đó.

1. Control Plane

Control plane là tập các thành phần quản lý trạng thái toàn cluster. kube-apiserver là HTTP API front door; các client và component trao đổi với cluster thông qua API này. etcd lưu API data nhất quán. kube-scheduler tìm Pod chưa được bind và chọn node phù hợp. kube-controller-manager chạy các controller hiện thực hành vi của Kubernetes API. cloud-controller-manager là thành phần tùy chọn để tích hợp cloud provider.

Trên worker node, kubelet theo dõi Pod được giao cho node và phối hợp container runtime, volumes, networking và probes. Container runtime thực thi containers thông qua CRI-compatible integration. Vì vậy, kubelet/runtime không thuộc control plane nhưng là phần bắt buộc của vòng thực thi desired state trên node.

2. Components và trách nhiệm

3. Create Deployment call flow

1. Client gửi Deployment object tới kube-apiserver.
2. Request đi qua authentication, authorization, admission, validation/defaulting theo API path được cấu hình.
3. Object được persist vào cluster state; watchers/informers có thể quan sát thay đổi.
4. Deployment controller reconcile và tạo/cập nhật ReplicaSet.
5. ReplicaSet controller reconcile và tạo/cập nhật Pods để đạt replica count mong muốn.
6. Scheduler quan sát Pod chưa bind, chọn node và ghi binding.
7. Kubelet trên node quan sát Pod đã được giao, phối hợp runtime, mount, network và probes rồi cập nhật status.
8. Các controller liên quan Service/EndpointSlice cập nhật tập backend đủ điều kiện để nhận traffic dựa trên object và readiness.

kubectl / client
      |
      v
kube-apiserver ---> etcd
      |
      +--> Deployment controller --> ReplicaSet --> Pods
      |
      +--> Scheduler ---------------> Pod -> Node binding
                                      |
                                      v
                                   kubelet
                                      |
                                      v
                             runtime / network / volumes

4. Reconciliation semantics

Controller nên được hiểu là level-triggered reconciliation: controller so sánh observed state với desired state rồi thực hiện hành động cần thiết. Thiết kế tốt phải idempotent, chấp nhận retry và không dựa vào giả định event chỉ tới đúng một lần hay luôn giữ thứ tự tuyệt đối.

• Desired state: spec mà user/system đã ghi vào API.
• Observed state: object/resource thực tế mà controller đang thấy tại thời điểm reconcile.
• Convergence: nhiều vòng reconcile có thể cần thiết trước khi observed state tiến tới desired state.
• Status: phản ánh quan sát của controller/kubelet và có thể trễ so với thay đổi spec.

Do đó, automation nên chờ condition rõ ràng như Available, readiness hoặc rollout completion thay vì coi HTTP success từ API server là completion của workload.

5. HA, leader election và failure model

API server có thể chạy nhiều replica và được đặt sau load balancer. Với controller manager và scheduler, nhiều replica thường phối hợp bằng leader election để chỉ một active leader thực hiện một nhóm control duties tại một thời điểm. Kubernetes dùng Lease objects cho node heartbeats và cho các cơ chế leader election.

etcd phụ thuộc quorum: cluster N members chỉ chịu được tối đa (N-1)/2 permanent member failures mà vẫn giữ majority. Khi mất quorum, cluster không thể tiếp tục consensus cho update; recovery phải dựa vào quy trình snapshot/restore hoặc member recovery phù hợp.

6. Operational signals và capacity

Production troubleshooting cần nhìn cả latency và backlog của control loop. Các signal hữu ích gồm API request rate/latency/errors, API Priority and Fairness queue/reject behavior, etcd request/disk latency và quorum health, scheduler pending Pods, controller workqueue depth/retries, node Lease freshness, Pod scheduling latency, rollout duration và EndpointSlice/readiness propagation delay.

Capacity planning không chỉ là CPU/RAM trung bình. Hãy test burst create/update, watch fan-out, controller resync/retry, node churn và rollout lớn. Giữ headroom để control plane vẫn tiến triển khi một instance hoặc failure domain bị mất, thay vì chỉ đủ capacity cho steady state.

7. Security boundaries

API access là security boundary trung tâm: authentication xác định caller; authorization quyết định hành động được phép; admission có thể mutate hoặc reject object trước khi persistence. Dùng least-privilege RBAC, bảo vệ kubeconfig/service-account credentials, hạn chế quyền truy cập trực tiếp etcd, mã hóa traffic và kiểm soát admission/webhook dependencies theo threat model.

Admission webhook nằm trên write path có thể trở thành availability dependency. Khi thiết kế policy cần hiểu timeout/failure policy, tránh webhook vòng lặp hoặc phụ thuộc downstream không ổn định, và có break-glass procedure được audit.

8. Rollback và recovery

• Với workload rollout: giữ revision/history phù hợp, xác định readiness/availability gate và rollback khi error budget hoặc health signal vượt ngưỡng.
• Với control-plane change: canary hoặc thay đổi từng instance, giữ compatibility giữa version/config trong cửa sổ rollout và có đường quay lại cấu hình trước.
• Với etcd: tạo snapshot định kỳ, kiểm tra snapshot status, diễn tập restore và ghi rõ RPO/RTO; backup không được test restore thì chưa phải recovery plan hoàn chỉnh.
• Sau incident: reconcile lại actual-vs-desired state và kiểm tra stale objects, pending Pods, unavailable replicas, node conditions cùng traffic eligibility thay vì chỉ xác nhận component đã restart.