Monitoring a production Kubernetes cluster

Vì sao cần monitor (và monitor đúng)

Kubernetes có rất nhiều thành phần phụ thuộc nhau — node, pod, deployment, service, ingress, storage, autoscaler, control plane. Lỗi nhỏ ở một layer lan ra cả hệ thống, và "running" không có nghĩa là "healthy":

• Pod Running nhưng app trả lỗi / deadlock.
• Node Ready nhưng memory pressure → pod bị evict.
• Deploy thành công nhưng latency người dùng tăng vọt.
• Service ổn nhưng ingress trả 5xx / timeout.

0 · Nguyên tắc nền tảng

Ba "lens" bổ sung cho nhau — đừng chọn một, dùng đúng lens cho đúng đối tượng:

SLO + error budget

Định nghĩa SLO cho từng critical service (vd availability 99.9%, p99 < 300ms). Alert theo multi-window burn-rate (cửa sổ nhanh + chậm) thay vì ngưỡng thô — page khi đốt budget nhanh, mở ticket khi đốt chậm. Bớt false-positive, bắt đúng lúc đau.

Kiến trúc thu thập

Pull-based: Prometheus scrape các exporter; logs và traces đi đường riêng; Alertmanager route ra on-call.

Mô hình 12 layer

L1 · Control plane

Trái tim cluster. Trên EKS/GKE control plane là managed → bạn chỉ thấy một phần metric (apiserver qua metrics endpoint, không thấy etcd nội bộ). Self-managed thì monitor đầy đủ.

# apiserver 5xx error ratio (5m)
sum(rate(apiserver_request_total{code=~"5.."}[5m]))
  / sum(rate(apiserver_request_total[5m]))

L2 · Nodes & capacity

Tài nguyên vật lý. USE: dùng bao nhiêu (Utilization), sắp nghẽn chưa (Saturation), có lỗi không (Errors). Nguồn: node-exporter + kube-state-metrics.

# ALERT: node memory > 85% trong 10 phút
- alert: NodeMemoryHigh
  expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.85
  for: 10m
  labels: { severity: warning }
  annotations: { runbook: "https://runbooks/node-mem" }

L3 · Workloads

Trạng thái vận hành của workload — nguồn chính là kube-state-metrics (state) + cAdvisor (resource per container).

# ALERT: pod restart > 3 lần / 10 phút
- alert: PodRestarting
  expr: increase(kube_pod_container_status_restarts_total[10m]) > 3
  for: 0m
  labels: { severity: warning }

L4 · Application

Cái người dùng thực sự cảm nhận. App tự expose /metrics (histogram cho latency là bắt buộc để tính quantile).

L5 · Data layer

Stateful = nơi sự cố đau nhất. Dùng exporter riêng cho từng loại.

L6 · Network / DNS / Ingress

Đường đi của request. DNS hỏng là "lỗi toàn cục" âm thầm.

# Ingress 5xx ratio (nginx ingress)
sum(rate(nginx_ingress_controller_requests{status=~"5.."}[5m]))
  / sum(rate(nginx_ingress_controller_requests[5m]))

L7 · Logging

Metrics nói cái gì đang xảy ra; logs nói tại sao. Log nên structured (JSON) với field nhất quán:

• timestamp · namespace · pod · container · app · env · request_id · level · error

Monitor chính pipeline: log volume (theo dõi chi phí), dropped/ingestion errors của Fluent Bit, retention đúng policy.

# LogQL: 5xx của payment trong 5 phút, group theo pod
sum by (pod) (count_over_time({app="payment"} | json | status=~"5.." [5m]))

L8 · Tracing / APM

Trả lời "chậm ở đâu" khi một request đi qua nhiều service. OpenTelemetry → Tempo/Jaeger.

• Sampling: head/tail-based; giữ 100% trace lỗi, sample phần còn lại để khỏi nổ chi phí.
• Span error rate + latency breakdown per service → tìm nút thắt.
• Exemplars: nối từ panel latency (metric) thẳng tới trace cụ thể; correlate trace ↔ log qua trace_id.

L9 · Alerting & on-call

Alert theo impact, không theo mọi dao động. Ba tier:

# Multi-window burn-rate (SLO 99.9% → budget 0.1%)
# Page khi đốt nhanh: 14.4x trong 1h VÀ 5m
- alert: ErrorBudgetFastBurn
  expr: |
    job:slo_errors:ratio_rate1h > (14.4 * 0.001)
    and job:slo_errors:ratio_rate5m > (14.4 * 0.001)
  labels: { severity: critical }

L10 · Dashboards & SLO

Dashboard cho con người dùng lúc 3 giờ sáng — tối giản, không nhồi panel. Bộ tối thiểu:

• SLO / error-budget: attainment + burn-rate + budget còn lại (per critical service).
• Cluster overview: node ready · CPU/mem tổng · pod running/pending/failed · recent events.
• Application (RED): rate · errors · duration · top failing API · deploy version hiện tại.
• Node (USE): CPU · mem · disk pressure · network · pod capacity.
• Security: failed auth · suspicious API · RBAC changes · policy violations.

L11 · Platform & Security

Monitoring không chỉ là tài nguyên — còn là posture (cấu hình an toàn không).

• Secrets: truy cập bất thường tới Vault/Secret; secret mount as env (rò rỉ).
• NetworkPolicy: % namespace có NetPol (coverage); packet bị deny.
• Pod Security Admission: mode (enforce/audit) · pod chạy root · privileged · hostPath.
• Image trust: registry không tin cậy · CVE nghiêm trọng (Trivy).
• Runtime: Falco — privilege escalation, shell trong container, đọc file nhạy cảm.
• GitOps drift: state thực tế lệch Git (xem Flux + Kyverno).

L12 · Cost

Cost là một signal vận hành. Theo dõi để cắt lãng phí mà không hy sinh độ tin cậy.

• Cost theo namespace/workload (Kubecost / OpenCost / Cost Explorer tag).
• Over/under-provision: request vs usage thật (p95) — node loãng = đốt tiền.
• Spot coverage · on-demand chạy việc spot làm được.
• Tài nguyên mồ côi: PV không gắn, LB idle, snapshot cũ.

Ví dụ điều tra một sự cố

App trên EKS, sau khi deploy bản mới user báo chậm. Có monitoring đúng → đi từ symptom xuống cause trong vài phút:

1. Latency có tăng sau deploy không? (so baseline)
2. 5xx có tăng không? (L4)
3. Pod có restart / OOMKilled không? (L3)
4. CPU/mem có vượt baseline? (L2)
5. HPA có scale lên/xuống bất thường? (L3)
6. App logs nói gì? (L7 — lọc theo request_id)
7. DB/cache khoẻ không? connection, replication lag? (L5)
8. Ingress có timeout/5xx? (L6)

Toolkit

References

• Puja Maheshvari — How I would design monitoring for a production Kubernetes cluster: medium.com
• Google SRE — Monitoring Distributed Systems (Four Golden Signals) & Alerting on SLOs (multi-window burn-rate).
• Brendan Gregg — The USE Method. · Tom Wilkie — The RED Method.
• Docs: Prometheus · kube-state-metrics · node-exporter · Grafana Loki / Tempo.