Series: Kubernetes từ Zero đến Production

---

Tình huống thực tế

Hệ thống Todo đã được đưa vào production.

Hiện tại đã có:

• Health Check
• Rolling Update
• Horizontal Pod Autoscaler (HPA)

Một buổi sáng, Product Owner báo:

"Website hôm nay phản hồi rất chậm."

Nhưng không ai biết nguyên nhân.

Có thể là:

• CPU tăng cao
• Memory sắp đầy
• Pod liên tục restart
• Backend xử lý request chậm
• Database quá tải

Nếu chỉ dùng:

kubectl get pods

Bạn chỉ biết Pod còn chạy hay không.

Bạn không biết điều gì đang xảy ra bên trong hệ thống.

Đó là lúc Monitoring trở nên cực kỳ quan trọng.

---

Mục tiêu

Sau bài lab này, bạn sẽ:

• Hiểu Monitoring trong Kubernetes
• Triển khai Prometheus
• Triển khai Grafana
• Thu thập Metrics của Cluster
• Quan sát CPU, Memory và Restart Count
• Theo dõi Request Latency của ứng dụng
• Hiểu quy trình phát hiện sự cố bằng Dashboard

---

Kiến trúc Monitoring

          Application
               │
            Metrics
               │
          Prometheus
               │
          Time Series DB
               │
            Grafana
               │
          Dashboard

Luồng hoạt động:

1. Ứng dụng và Kubernetes phát sinh Metrics.
2. Prometheus thu thập (Scrape) Metrics.
3. Prometheus lưu dữ liệu theo thời gian.
4. Grafana đọc dữ liệu từ Prometheus.
5. Dashboard hiển thị biểu đồ theo thời gian thực.

---

Các thành phần sẽ cài đặt

Trong bài lab này chúng ta triển khai:

• Prometheus
• Grafana
• kube-state-metrics

Mỗi thành phần có nhiệm vụ riêng.

Prometheus

Prometheus chịu trách nhiệm:

• Thu thập Metrics
• Lưu dữ liệu
• Cho phép truy vấn bằng PromQL

---

Grafana

Grafana không thu thập dữ liệu.

Grafana chỉ:

• Kết nối Prometheus
• Hiển thị Dashboard
• Vẽ biểu đồ
• Thiết lập cảnh báo (Alert)

---

kube-state-metrics

kube-state-metrics cung cấp thông tin về các Kubernetes Object như:

• Pod
• Deployment
• StatefulSet
• Node
• Namespace

Ví dụ:

• Có bao nhiêu Pod Running
• Pod nào CrashLoopBackOff
• Deployment có bao nhiêu Replica

---

Kiến trúc hoàn chỉnh

                   Kubernetes Cluster
        +------------------------------------+
        |            Application             |
        |                                    |
        |    Frontend      Backend           |
        |                     │              |
        |                PostgreSQL          |
        +------------------+-----------------+
                           │
                    Metrics Endpoint
                           │
                   Prometheus Server
                           │
                 Time Series Database
                           │
                        Grafana

---

Phần 1. Triển khai Prometheus

Tạo namespace:

kubectl create namespace monitoring

Triển khai Prometheus.

Sau khi hoàn thành:

kubectl get pods -n monitoring

Ví dụ:

prometheus-server

Running

Kiểm tra Service:

kubectl get svc -n monitoring

---

Phần 2. Triển khai kube-state-metrics

Sau khi deploy:

kubectl get pods -n monitoring

Ví dụ:

kube-state-metrics
Running

Thành phần này sẽ giúp Prometheus biết trạng thái của các tài nguyên trong Kubernetes.

---

Phần 3. Triển khai Grafana

Deploy Grafana.

Kiểm tra:

kubectl get pods -n monitoring

Ví dụ:

grafana

Running

Expose Service:

kubectl port-forward svc/grafana 3000:80 -n monitoring

Mở trình duyệt:

http://localhost:3000

Đăng nhập Grafana.

---

Phần 4. Kết nối Prometheus

Trong Grafana:

Connections
     ↓
Data Sources
     ↓
Prometheus

Điền địa chỉ Prometheus.

Kiểm tra:

Save & Test

Nếu thành công:

Data source is working

Grafana đã có thể đọc dữ liệu từ Prometheus.

---

Phần 5. Dashboard CPU

Dashboard đầu tiên nên theo dõi:

Pod CPU Usage

Quan sát:

• Pod nào dùng nhiều CPU
• CPU tăng theo thời gian
• CPU tăng khi Load Test

Ví dụ:

Backend A

120m
↓
420m
↓
650m

Bạn có thể so sánh với Resource Requests và Limits đã cấu hình ở Lab 3.

---

Phần 6. Dashboard Memory

Tiếp theo là Memory.

Quan sát:

Backend Memory

420Mi
↓
560Mi
↓
720Mi

Nếu Memory tăng liên tục và không giảm, rất có thể ứng dụng đang gặp Memory Leak.

Monitoring giúp phát hiện vấn đề này trước khi Pod bị OOMKilled.

---

Phần 7. Dashboard Restart Count

Một Dashboard rất quan trọng:

Pod Restart Count

Nếu thấy:

Backend

0
↓
0
↓
5
↓
12

Đó là dấu hiệu bất thường.

Có thể:

• Liveness Probe thất bại
• OOMKilled
• CrashLoopBackOff
• Ứng dụng bị lỗi

Nếu không theo dõi Restart Count, bạn có thể chỉ phát hiện sự cố khi người dùng bắt đầu phản ánh.

---

Phần 8. Dashboard Request Latency

Đối với ứng dụng Spring Boot, bạn có thể export Metrics bằng Micrometer.

Ví dụ:

GET /api/todos

Average

35ms

Sau khi có Metrics:

Prometheus sẽ thu thập.

Grafana sẽ hiển thị:

Request Latency

30ms
↓
50ms
↓
180ms
↓
600ms

Nếu Latency tăng bất thường trong khi CPU vẫn thấp, nguyên nhân có thể nằm ở Database hoặc mạng.

---

Phần 9. Kiểm thử Monitoring

Thực hiện Load Test giống Lab 4.

Ví dụ:

ab -n 10000 -c 100 \
http://todo.company.local/api/todos

Hoặc:

k6 run script.js

Quan sát Dashboard.

Bạn sẽ thấy:

• CPU tăng
• Memory tăng
• Số lượng Pod tăng (do HPA)
• Request Latency thay đổi

Monitoring sẽ giúp bạn nhìn thấy toàn bộ quá trình này theo thời gian thực.

---

Phần 10. Điều tra sự cố

Giả sử Dashboard hiển thị:

CPU

95%

Bạn tiếp tục kiểm tra:

kubectl top pods

Sau đó:

kubectl describe pod

Cuối cùng:

kubectl logs

Đây là quy trình điều tra phổ biến:

Grafana Dashboard
        ↓
     CPU tăng
        ↓
Prometheus Metrics
        ↓
   kubectl top
        ↓
 kubectl describe
        ↓
   kubectl logs

Dashboard giúp bạn biết có vấn đề, còn kubectl giúp bạn tìm nguyên nhân.

---

Dashboard nên có

Sau bài lab này, Dashboard tối thiểu nên bao gồm:

• Pod CPU Usage
• Pod Memory Usage
• Pod Restart Count
• Number of Running Pods
• Request Latency
• Request Rate
• Node CPU
• Node Memory

Chỉ với những Dashboard này, bạn đã có thể theo dõi phần lớn tình trạng của một Kubernetes Cluster.

---

Thử tạo lỗi

Tình huống 1: Load Test

Chạy:

ab -n 10000 -c 100

Quan sát:

• CPU tăng
• HPA tăng Pod
• Dashboard cập nhật theo thời gian thực

---

Tình huống 2: Pod Crash

Xóa một Backend Pod:

kubectl delete pod <pod-name>

Quan sát:

• Restart Count
• Số lượng Pod
• CPU của Pod mới

Dashboard sẽ phản ánh ngay những thay đổi này.

---

Dọn dẹp

Nếu không còn sử dụng Monitoring:

kubectl delete namespace monitoring

Hoặc giữ nguyên để sử dụng cho các bài lab tiếp theo.

---

Những gì bạn đã học

Sau bài lab này, bạn đã biết:

✅ Vai trò của Monitoring

✅ Prometheus

✅ Grafana

✅ kube-state-metrics

✅ Dashboard CPU

✅ Dashboard Memory

✅ Dashboard Restart Count

✅ Dashboard Request Latency

✅ Theo dõi hệ thống theo thời gian thực

✅ Quy trình điều tra sự cố bằng Metrics

---

Bài học rút ra

Monitoring không giúp hệ thống tự sửa lỗi.

Nhưng nó giúp DevOps Engineer biết:

• Điều gì đang xảy ra?
• Sự cố bắt đầu từ khi nào?
• Thành phần nào gặp vấn đề?
• Mức độ ảnh hưởng ra sao?

Thay vì chờ người dùng báo lỗi, bạn có thể phát hiện bất thường ngay từ Dashboard và xử lý trước khi sự cố lan rộng.

Ở bài lab tiếp theo, chúng ta sẽ xây dựng hệ thống Logging tập trung với Fluent Bit và Elasticsearch để không chỉ biết hệ thống đang gặp vấn đề gì, mà còn biết chính xác lỗi nào đã xảy ra trong từng Pod.