k6, Prometheus histograms và HPA
Chọn load model đúng để đo đúng bottleneck.
Nắm bản chất
k6 constant-arrival-rate đặt tốc độ bắt đầu iterations; khi hệ thống/load
generator thiếu capacity có thể xuất hiện dropped_iterations.
Closed VU-based model có thể giảm request rate khi service chậm, che sự cố
saturation.
Prometheus classic histogram quantile toàn dịch vụ phải gộp buckets theo
le rồi dùng histogram_quantile, không lấy trung bình
p95 của từng Pod. HPA theo CPU phù hợp CPU-bound workloads hơn các services bị
chậm do chờ I/O. Metrics Server là phụ thuộc cần để HPA resource metrics hoạt
động.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
histogram_quantile(0.95,
sum by (le)(rate(perf19_request_duration_seconds_bucket[2m]))
)
kubectl -n perf19 get hpa -w
kubectl -n perf19 describe hpa perf19-api
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Chạy k6 hai lần với MODE=cpu và MODE=io trong lab Buổi 19. Ghi CPU, p95, RPS, dropped iterations và replicas HPA.
Lỗi dễ mắc
Một threshold k6 đạt không chứng minh một job queue đã xử lý xong, nếu API chỉ trả 202 khi tiếp nhận.
Tự kiểm tra
Vì sao p95 của các Pods không được lấy trung bình đơn giản?Xem đáp án ↗
Vì percentile của tổng phân phối không bằng trung bình percentiles của các phân phối con.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 19Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗