Giám sát Kubernetes cluster: monitoring production thực chiến

Giám sát Kubernetes cluster không phải là chuyện “cài Prometheus là xong”. Trong production, cluster có thể vẫn chạy nhưng ứng dụng đã chậm, node đã đầy disk, pod restart liên tục, hoặc control plane bắt đầu nghẽn mà đội vận hành chưa nhận ra. Nếu monitoring chỉ dừng ở vài dashboard đẹp mắt thì lúc incident xảy ra, anh em vẫn thiếu dữ liệu để quyết định.

Bài này đi theo hướng thực chiến: chọn đúng tín hiệu cần theo dõi, triển khai stack giám sát cơ bản, đọc metric trong bối cảnh thật, thiết kế cảnh báo đủ nhạy nhưng không spam, và xây quy trình troubleshooting khi giám sát Kubernetes cluster báo đỏ.

1. Mục tiêu thật sự của giám sát Kubernetes cluster

Nhiều đội mới triển khai Kubernetes thường nhầm giữa “có metric” và “có khả năng quan sát”. Monitoring tốt phải trả lời được ít nhất 4 câu hỏi:

Ứng dụng có đang phục vụ người dùng bình thường không?
Cluster còn đủ tài nguyên cho tải hiện tại và tải tăng đột biến không?
Sự cố nằm ở app, node, network hay control plane?
Khi có cảnh báo, người trực on-call cần làm gì trước?

Nếu chưa trả lời được 4 câu hỏi này, hệ thống giám sát vẫn chưa phục vụ production đúng nghĩa.

2. Bối cảnh lab và production mẫu

Cluster Kubernetes 1.29 hoặc 1.30, 3 worker node.
Container runtime: containerd.
Ứng dụng mẫu: web app chạy Deployment + Service + Ingress.
Monitoring stack: Prometheus, Alertmanager, Grafana, kube-state-metrics, node-exporter.
Môi trường có thể là on-prem lab, VPS hoặc cloud như EKS/GKE/AKS.

Trong bài, em ưu tiên mô hình phổ biến và dễ nhân rộng sang production.

3. Theo dõi những lớp nào trong cluster?

3.1. Lớp hạ tầng node

Đây là nơi phát hiện CPU, RAM, disk, network, inode hoặc filesystem pressure. Nếu node nghẹt tài nguyên, pod có thể bị eviction hoặc latency tăng dù app code không đổi.

3.2. Lớp Kubernetes object

Cần theo dõi trạng thái Deployment, StatefulSet, DaemonSet, pod phase, restart count, unschedulable pod, job fail, HPA activity. Đây là vùng dữ liệu mà kube-state-metrics cung cấp rất tốt.

3.3. Lớp ứng dụng

Đây mới là lớp gần trải nghiệm người dùng nhất: request rate, error rate, latency, queue depth, số kết nối, throughput, tỉ lệ timeout. Chỉ nhìn CPU node mà không nhìn metric ứng dụng rất dễ chẩn đoán sai.

3.4. Lớp control plane

Ở cluster tự quản hoặc lab, cần theo dõi API server latency, etcd health, scheduler activity, controller-manager error. Nếu control plane chậm, rollout và scheduling sẽ bị ảnh hưởng.

4. Triển khai monitoring stack cơ bản bằng Helm

Một lựa chọn thực tế là dùng kube-prometheus-stack của Prometheus Community.

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm upgrade --install kube-prometheus prometheus-community/kube-prometheus-stack   --namespace monitoring

Giải thích ngắn:

Prometheus: thu thập metric.
Alertmanager: gom nhóm và gửi cảnh báo.
Grafana: dashboard quan sát.
kube-state-metrics: metric từ Kubernetes objects.
node-exporter: metric tài nguyên node.

Sau khi cài, kiểm tra pod:

kubectl get pods -n monitoring
kubectl get svc -n monitoring

Output mẫu:

NAME                                                     READY   STATUS    RESTARTS   AGE
kube-prometheus-grafana-6ff8d8c7d7-j2jvl                3/3     Running   0          3m
kube-prometheus-kube-state-metrics-7f5d74c88f-f8n7j     1/1     Running   0          3m
kube-prometheus-operator-77b7fd7db7-gkg5b               1/1     Running   0          3m
prometheus-kube-prometheus-prometheus-0                 2/2     Running   0          3m

5. Những metric nên có từ ngày đầu

Node và tài nguyên

CPU usage theo node.
Memory usage và available memory.
Disk usage, disk IO, inode usage.
Network receive/transmit errors.

Pod và workload

Pod restart count.
CrashLoopBackOff và ImagePullBackOff.
Pending pod kéo dài.
Deployment unavailable replicas.

Ứng dụng

HTTP 5xx rate.
P95/P99 latency.
Request throughput.
Queue length hoặc worker backlog nếu có job nền.

Khi giám sát Kubernetes cluster, nên bắt đầu từ các tín hiệu trực tiếp gắn với rủi ro vận hành thay vì thu gom mọi metric có thể có.

6. Kiểm tra nhanh bằng kubectl trước khi mở Grafana

Khi có cảnh báo, anh em không nhất thiết phải vào dashboard đầu tiên. Một số lệnh giúp dựng tình hình rất nhanh:

kubectl get nodes -o wide
kubectl top nodes
kubectl get pods -A --field-selector=status.phase!=Running
kubectl top pods -A --sort-by=cpu
kubectl top pods -A --sort-by=memory

Nếu thấy pod restart nhiều, xem tiếp:

kubectl get pods -A --sort-by='.status.containerStatuses[0].restartCount'
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

--previous cực hữu ích khi container vừa crash và bị khởi động lại.

7. Ví dụ cảnh báo nên có trong production

Node disk usage cao

Nếu /var/lib/containerd hoặc filesystem chứa image đầy, pod mới có thể không pull được image.

Pod restart tăng đột biến

Đây thường là dấu hiệu app lỗi, dependency timeout, OOMKill hoặc probe cấu hình quá gắt.

Deployment thiếu replica sẵn sàng

Nếu desired replica là 6 mà ready chỉ còn 3, người dùng có thể chưa thấy lỗi ngay nhưng hệ thống đã mất khả năng chịu tải.

API server latency cao

Cluster có thể chậm rollout, autoscaler phản ứng muộn hoặc job CI/CD treo khi gọi Kubernetes API.

8. Thiết kế alert tránh spam

Một sai lầm rất phổ biến là cảnh báo theo từng pod đơn lẻ và bắn ngay khi metric nhích nhẹ. Kết quả là on-call bị mù vì quá nhiều notification.

Nguyên tắc thực dụng:

Cảnh báo theo tác động vận hành, không chỉ theo biến động tạm thời.
Dùng for: để tránh false positive ngắn hạn.
Group alert theo cluster, namespace hoặc service.
Phân cấp severity rõ: info, warning, critical.

Ví dụ PrometheusRule:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: k8s-workload-alerts
  namespace: monitoring
spec:
  groups:
  - name: workload.rules
    rules:
    - alert: KubernetesPodCrashLooping
      expr: increase(kube_pod_container_status_restarts_total[10m]) > 3
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "Pod restart tăng bất thường"
        description: "Container restart hơn 3 lần trong 10 phút. Kiểm tra logs, events và resource limits."

Alert này chưa hoàn hảo cho mọi môi trường, nhưng đủ tốt để bắt đầu và có hành động rõ ràng.

9. Troubleshooting theo tình huống thực tế

9.1. Pod Pending lâu

kubectl describe pod <pod-name> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp

Tìm các lỗi như:

Insufficient CPU hoặc memory.
Node selector / affinity không khớp.
PersistentVolumeClaim chưa bind.
Taint/toleration sai.

9.2. Pod bị OOMKilled

kubectl describe pod <pod-name> -n <namespace>
kubectl top pod <pod-name> -n <namespace>

Khi thấy OOMKilled, đừng tăng memory limit ngay theo phản xạ. Hãy kiểm tra memory usage theo thời gian trên Grafana để xem đó là leak, burst tải hay cấu hình request/limit quá chặt.

9.3. Node NotReady

kubectl describe node <node-name>
kubectl get pods -A -o wide | grep <node-name>

Sau đó kiểm tra tại máy node: kubelet, container runtime, disk pressure, network route, DNS nội bộ.

10. Kết hợp dashboard với runbook

Dashboard tốt không chỉ để nhìn mà còn để hành động. Mỗi panel cảnh báo quan trọng nên có:

Mô tả metric đo cái gì.
Ngưỡng nào là nguy hiểm.
Lệnh kiểm tra tiếp theo bằng kubectl.
Link runbook hoặc SOP nội bộ.

Đây là điểm biến monitoring từ “hệ quan sát” thành “hệ hỗ trợ vận hành”.

11. Tài liệu chính thống nên tham khảo

12. Checklist nghiệm thu monitoring cho cluster

Prometheus scrape được node, kube-state-metrics và metric ứng dụng quan trọng.
Có dashboard cho node, workload và application latency/error rate.
Cảnh báo có phân mức severity và không spam tức thời.
Mỗi cảnh báo chính có hướng xử lý ban đầu hoặc link runbook.
Kiểm tra được restart count, pending pod, OOMKill và disk pressure.
Retention và storage của Prometheus phù hợp tài nguyên thực tế.
Alertmanager đã route đúng kênh thông báo của đội trực.

13. Bài tập lab cuối bài

Cài kube-prometheus-stack trên cluster lab.
Tạo một pod tiêu thụ memory cao để quan sát alert OOM hoặc memory pressure.
Cố tình scale workload vượt tài nguyên node để tạo Pending pod.
Viết một alert riêng cho HTTP 5xx rate của ứng dụng mẫu.
Tạo runbook ngắn: khi pod CrashLoopBackOff thì đội trực làm gì trong 10 phút đầu.

Kết luận: giám sát Kubernetes cluster tốt không nằm ở số lượng biểu đồ, mà ở việc anh em có nhìn ra tín hiệu sớm, phân biệt được lỗi app với lỗi hạ tầng, và có bước xử lý rõ ràng trước khi sự cố lan rộng trong production.