eBPF profiling, capacity và cost/request
Tối ưu theo bottleneck đã được chứng minh.
Nắm bản chất
Continuous profiling/eBPF-based sampling có thể cho thấy CPU hotspots trong các call stacks. Flame graph width biểu diễn tỉ lệ samples tích lũy, không nhất thiết là duration của một request. Với Python dùng cProfile/tracemalloc/py-spy; với JVM dùng JFR/async-profiler và Native Memory Tracking phù hợp.
Capacity planning dựa trên throughput an toàn theo SLO, headroom, failover budget và downstream limits. FinOps nên đo cost per successful request/job, không chỉ số lượng EC2 nodes. Pod có request quá cao làm lãng phí reserved capacity, nhưng quá thấp có thể gây contention/evictions.
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
Desired pods ≈ ceil(Peak_RPS / Safe_RPS_per_pod)
Cost_per_1k_jobs = (Attributed_cost / successful_jobs) * 1000
kubectl top nodes
kubectl -n perf19 top pods
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
Lập hai cấu hình resources requests/limits khác nhau, chạy cùng k6 tải, so sánh SLO và chi phí giả định. Ghi lại confidence/limitations của Kind benchmark.
Lỗi dễ mắc
Kind shares laptop host and Docker VM constraints; kết quả không đại diện trực tiếp cho cloud production network/CPU.
Tự kiểm tra
Thành công khi tối ưu performance được đánh giá qua tiêu chí nào?Xem đáp án ↗
Giảm latency/errors hoặc tăng throughput/cost-efficiency trong khi vẫn đáp ứng SLO và giữ đủ headroom.
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 ↗