Control Plane Metrics — Quan Sát Bộ Não Cluster

Why this matters in production

Control plane là "bộ não" của cluster: API server tiếp nhận mọi request, scheduler quyết định Pod chạy ở đâu, controller-manager đảm bảo trạng thái thực tế hội tụ về trạng thái khai báo, etcd lưu toàn bộ state (Chương 5). Khi control plane gặp vấn đề, triệu chứng lan ra toàn cluster: kubectl chậm hoặc timeout, Pod kẹt ở Pending, Deployment không rollout, HPA không scale. Nhưng đây chính là nghịch lý nguy hiểm nhất của vận hành GKE: các triệu chứng này biểu hiện ở tầng workload, trong khi nguyên nhân nằm ở control plane — và nếu bạn không bật control plane metric, bạn không có cách nào nhìn thấy nguyên nhân.

Vì control plane do Google quản lý và chạy ngoài project của bạn, bạn không thể scrape trực tiếp endpoint /metrics của nó như Prometheus thông thường. GKE giải quyết bằng cách phơi bày một tập metric chọn lọc qua Google Cloud Managed Service for Prometheus khi bạn opt-in. Theo tài liệu control plane metrics, các gói này mặc định tắt và phải bật tường minh — lý do là chi phí, vì metric control plane có cardinality cao.

Đây là file mà mọi đội vận hành cluster nghiêm túc cần đọc trước, không phải sau, sự cố đầu tiên. Bật control plane metric sau khi đã có incident nghĩa là không có baseline lịch sử để so sánh — bạn không biết apiserver_request_duration_seconds p99 bình thường là 50ms hay 500ms, nên không biết con số hiện tại có bất thường không.

Internal model: ba gói metric control plane

GKE chia control plane metric thành ba gói, bật độc lập qua flag --monitoring:

Gói	Flag --monitoring	Component	Câu hỏi chính trả lời
API server	API_SERVER	kube-apiserver	Request rate/error/latency, etcd có chậm không, webhook có nghẽn không
Scheduler	SCHEDULER	kube-scheduler	Pod có xếp được không, mất bao lâu, có preemption không
Controller-manager	CONTROLLER_MANAGER	kube-controller-manager	Reconciliation có kịp không, work queue có dồn không

Cả ba đều yêu cầu system metric (SYSTEM) đã bật, và đều đi qua Managed Service for Prometheus với resource type prometheus_target, tiền tố metric prometheus.googleapis.com/. Điều này có nghĩa bạn query chúng bằng PromQL (tên metric Prometheus gốc) trong Cloud Monitoring, và chúng mang resource label cluster/location/project_id nhất quán với phần còn lại của stack.

API server metrics — cổng vào của mọi thứ

API server là điểm nghẽn tiềm tàng số một, vì mọi thành phần (kubelet, controller, kubectl, operator, webhook) đều nói chuyện qua nó. Các metric then chốt:

• apiserver_request_total — counter tổng số request, có label verb (GET/LIST/WATCH/POST/PATCH/DELETE), group, version, resource, code (HTTP status). Đây là metric nền tảng để tính request rate (rate(...)) và error rate (lọc code=~"5.."). Một spike LIST request từ một controller hỏng (list toàn bộ Pod mỗi giây thay vì watch) là nguyên nhân kinh điển làm nghẽn API server — và chỉ metric này thấy được.

• apiserver_request_duration_seconds — histogram độ trễ xử lý request. Đây là metric quan trọng nhất để đo sức khỏe API server. Dùng histogram_quantile() để tính p50/p95/p99 latency theo verb/resource. LIST trên resource lớn (ví dụ list tất cả Secret) có latency cao là tín hiệu cảnh báo. Latency p99 tăng dần theo thời gian thường báo hiệu etcd đang chậm hoặc cluster đang phình.

• apiserver_current_inflight_requests — gauge số request đang xử lý đồng thời, tách theo request_kind (mutating/readOnly). Liên quan trực tiếp tới API Priority and Fairness (APF, Chương 5): khi inflight chạm trần, request bị xếp hàng hoặc bị từ chối với HTTP 429. Theo dõi metric này cùng apiserver_flowcontrol_* để chẩn đoán throttling.

• apiserver_storage_objects — gauge số object đang lưu theo resource. Đây là metric "sức khỏe dài hạn" của cluster: số object tăng không kiểm soát (ví dụ hàng triệu Event, hàng trăm nghìn Secret từ một controller rò rỉ) làm etcd phình, làm LIST chậm, và cuối cùng làm chậm toàn bộ API server. Một trong những metric tốt nhất để phát hiện anti-pattern "leak resource".

• etcd op latency (qua các metric như apiserver_storage_* / etcd_request_duration_seconds khi được phơi bày) — độ trễ thao tác đọc/ghi etcd. Vì etcd là backend đồng thuận Raft (Chương 5), ghi chậm ở etcd lan thẳng thành ghi chậm ở API server. Latency etcd tăng là tín hiệu cluster đang chạm giới hạn scale của control plane.

• apiserver_admission_webhook_admission_duration_seconds — độ trễ của admission webhook bên thứ ba (Chương 10). Một webhook chậm hoặc treo với failurePolicy: Fail có thể làm chết khả năng tạo Pod toàn cluster. Metric này cô lập chính xác webhook nào đang là nút cổ chai — vô giá khi debug "tự nhiên không deploy được gì".

Scheduler metrics — vì sao Pod kẹt Pending

Scheduling failure là nguyên nhân hàng đầu Pod stuck ở Pending (Chương 8). Scheduler metric trả lời "có xếp được không và mất bao lâu":

• scheduler_pending_pods — gauge số Pod đang chờ, tách theo queue: active (đang chờ thử), backoff (vừa fail, đang chờ retry), unschedulable (không node nào phù hợp). Phân biệt ba hàng đợi này là chìa khóa: unschedulable cao kéo dài nghĩa là thiếu tài nguyên/vi phạm constraint (cần Cluster Autoscaler hoặc sửa request), còn backoff cao báo hiệu Pod liên tục fail bind (ví dụ volume không attach được).

• scheduler_scheduling_attempt_duration_seconds — histogram thời gian một lần thử schedule. Tăng cao báo hiệu scheduler đang vất vả: quá nhiều node phải đánh giá, hoặc affinity/anti-affinity phức tạp (chi phí O(pods×namespaces), Chương 8) làm chậm scoring. Ở cluster lớn, đây là metric để quyết định tinh chỉnh percentageOfNodesToScore.

• scheduler_schedule_attempts_total — counter số lần thử, có label result (scheduled/unschedulable/error). Tỷ lệ unschedulable/error cao là tín hiệu cấu trúc: node pool sai, taint chặn, resource fragmentation.

• scheduler_preemption_attempts_total và scheduler_preemption_victims — đếm sự kiện preemption và số Pod bị "đuổi" để nhường chỗ cho Pod priority cao hơn (Chương 8). Preemption nhiều bất thường báo hiệu thiết kế PriorityClass có vấn đề hoặc cluster thiếu capacity kinh niên — Pod priority cao liên tục đẩy Pod thấp ra, gây cascading eviction và starvation.

Controller-manager metrics — reconciliation có kịp không

Controller-manager chạy hàng chục controller (Deployment, ReplicaSet, Node, Job...), mỗi cái là một reconciliation loop tiêu thụ work queue (Chương 5). Metric then chốt:

• workqueue_depth — gauge độ sâu hàng đợi của mỗi controller. Đây là tín hiệu sức khỏe trực tiếp nhất: queue depth tăng và không giảm nghĩa là controller không reconcile kịp tốc độ thay đổi — nó đang tụt hậu. Ở cluster có churn cao (nhiều Pod tạo/xóa liên tục), theo dõi queue depth của node controller và endpoint controller là quan trọng.

• workqueue_adds_total — counter số item thêm vào queue, đo tốc độ công việc đến. So sánh với tốc độ xử lý cho thấy controller có theo kịp không.

• workqueue_queue_duration_seconds / workqueue_work_duration_seconds — thời gian item chờ trong queue và thời gian xử lý mỗi item. Tăng cao báo hiệu reconciliation chậm.

• node_collector_evictions_total — counter số node eviction theo zone, do node lifecycle controller thực hiện khi node NotReady quá lâu. Spike metric này tương quan với sự cố hạ tầng (zone outage, network partition) — một tín hiệu sớm rất giá trị.

Production architecture patterns

Bật control plane metric ngay khi tạo cluster

Pattern đúng là coi control plane metric như một phần của cluster baseline, bật ngay từ ngày đầu để tích lũy dữ liệu lịch sử. Không có baseline, mọi con số trong sự cố đều vô nghĩa vì không biết "bình thường" là bao nhiêu.

Alerting phân tầng theo metric control plane

• Alert tier-1 (cluster-health): apiserver_request_duration_seconds p99 vượt ngưỡng kéo dài; apiserver_current_inflight_requests chạm trần (báo APF throttling); etcd latency tăng. Đây là alert "control plane đang ốm".
• Alert tier-2 (capacity): scheduler_pending_pods{queue="unschedulable"} cao kéo dài (thiếu capacity, cần kiểm tra Cluster Autoscaler); apiserver_storage_objects tăng bất thường (resource leak).
• Alert tier-3 (efficiency): preemption rate cao; workqueue depth dồn.

Dùng control plane metric để biện minh tách cluster

Khi apiserver_* latency và inflight tăng dần dù workload không đổi, đó là tín hiệu cluster đang chạm giới hạn scale của control plane (Chương 5). Dữ liệu này là cơ sở định lượng để quyết định tách workload sang cluster mới thay vì nhồi thêm — một quyết định kiến trúc cần bằng chứng, không phải cảm tính.

Real-world scenarios

Kịch bản 1 — Một operator hỏng làm nghẽn API server. Một custom controller được deploy có bug: thay vì dùng watch (informer), nó LIST toàn bộ Pod trong cluster mỗi 2 giây. apiserver_request_total{verb="LIST",resource="pods"} tăng vọt; apiserver_request_duration_seconds p99 tăng theo; apiserver_current_inflight_requests chạm trần và APF bắt đầu throttle các client khác bằng HTTP 429. Triệu chứng người dùng thấy: kubectl của mọi người đột nhiên chậm. Không có control plane metric, đội ngũ sẽ đoán mò; có metric, họ thấy ngay verb LIST trên pods bùng nổ và truy ra operator thủ phạm trong vài phút.

Kịch bản 2 — Pod Pending hàng loạt sau khi thêm anti-affinity. Một team thêm requiredDuringScheduling pod anti-affinity với topologyKey: hostname cho mọi Pod (anti-pattern, Chương 8). scheduler_pending_pods{queue="unschedulable"} tăng; scheduler_scheduling_attempt_duration_seconds cũng tăng vì scoring tốn kém. Metric chỉ thẳng vào scheduler là nút thắt, dẫn đến phát hiện constraint anti-affinity quá cứng.

Common mistakes / anti-patterns

• Không bật cho đến khi có sự cố. Không có baseline lịch sử nên khi cần nhất thì dữ liệu không có. Đúng: bật từ ngày tạo cluster.

• Bật rồi không alert. Có metric nhưng không ai nhìn cho đến khi user phàn nàn. Đúng: thiết lập alert SLO-based trên p99 latency và pending pods ngay khi bật.

• Bỏ qua apiserver_storage_objects. Resource leak (Event không bị GC, Secret nhân bản) phình âm thầm cho đến khi etcd chạm giới hạn và cả cluster chậm. Đúng: alert trên xu hướng tăng object count.

• Quên rằng metric này tốn phí. Bật cả ba gói trên hàng trăm cluster nhỏ mà không cân nhắc — control plane metric đi qua Managed Service for Prometheus, tính phí theo sample ingest. Đúng: bật API_SERVER + SCHEDULER cho mọi cluster (giá trị cao), cân nhắc CONTROLLER_MANAGER theo nhu cầu, và dùng dashboard để xác nhận chúng được dùng.

GCP-native implementation guidance

Bật cả ba gói control plane metric:

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Query vận hành điển hình (PromQL trong Cloud Monitoring):

# Error rate API server (% request trả 5xx) theo resource
sum by (resource) (rate(apiserver_request_total{code=~"5.."}[5m]))
  /
sum by (resource) (rate(apiserver_request_total[5m]))

# p99 latency API server theo verb (loại WATCH vì long-lived)
histogram_quantile(0.99,
  sum by (le, verb) (
    rate(apiserver_request_duration_seconds_bucket{verb!="WATCH"}[5m])
  ))

# Pod unschedulable kéo dài — tín hiệu thiếu capacity
scheduler_pending_pods{queue="unschedulable"}

# Work queue depth controller-manager dồn ứ
workqueue_depth

Lưu ý: tên metric là tên Prometheus gốc vì các gói này đi qua Managed Service for Prometheus; bạn dùng PromQL chứ không phải MQL khi query chúng.

Official references

• Control plane metrics — danh sách gói, cách bật, mô hình chi phí
• API server metrics list
• Scheduler metrics list
• Controller Manager metrics
• API Priority and Fairness — bối cảnh inflight/429
• Managed Service for Prometheus pricing — sample ingest

---

Tóm lại: control plane metric là cách duy nhất để quan sát bộ não cluster mà Google quản lý. API server metric (apiserver_request_*, inflight, storage objects, webhook duration) trả lời "cổng vào có khỏe không"; scheduler metric (pending_pods, attempt duration, preemption) trả lời "Pod có xếp được không"; controller-manager metric (workqueue_depth, node eviction) trả lời "reconciliation có kịp không". Bật chúng từ ngày đầu, alert trên latency percentile và pending pods, và bạn sẽ thấy nguyên nhân thay vì chỉ triệu chứng.