Hướng dẫn tính toán Resource (CPU, Memory) cho Pod theo lượng Request trong Kubernetes

📑 Mục Lục

1. Giới thiệu
2. Các yếu tố ảnh hưởng đến resource
3. Công thức tính sơ bộ CPU theo RPS
4. Công thức tính Memory theo session
5. Ví dụ thực tế
6. Khuyến nghị theo dõi và tuning
7. Tổng kết

📘 Giới thiệu

Việc xác định giới hạn resources.requests và resources.limits phù hợp cho mỗi pod trong Kubernetes là rất quan trọng để:

• Tránh overprovision dẫn đến lãng phí.
• Tránh underprovision gây crash hoặc timeout.

Trong bài viết này, ta sẽ tìm hiểu cách ước lượng CPU và Memory cho Pod dựa vào lưu lượng request (RPS) và behavior của ứng dụng.

📊 Các yếu tố ảnh hưởng

1. RPS (Request per Second): số lượng request mỗi giây.
2. Thời gian xử lý trung bình (latency): trung bình 1 request mất bao lâu để xử lý.
3. CPU time per request: tính bằng latency × CPU usage.
4. Memory/session: nếu mỗi request tạo ra session/data lưu trong RAM.
5. Concurrency model: dùng thread/block hay async.

🧮 Tính CPU theo RPS

Giả sử:

• Mỗi request mất 100ms CPU time.
• Lưu lượng dự kiến 100 RPS.

Công thức:

CPU cores cần = (Request/sec × CPU time/request) / 1000
              = (100 × 100) / 1000 = 10 cores

Với HPA, bạn có thể chia thành 10 pod, mỗi pod request 1 CPU.

Nếu request không đồng đều (có burst), bạn nên tính thêm hệ số buffer 20–30%.

📦 Tính Memory

Giả sử:

• Mỗi request giữ trong RAM 1 session khoảng 1MB.
• Max concurrent requests = 200.

Tổng memory cần = 1MB × 200 = 200MB + overhead (GC, JIT, cache...)

Khuyến nghị: cộng thêm 30–50% buffer tùy ngôn ngữ:

• Go/Node: ~30%
• Java/Python: ~50–100%

📚 Ví dụ thực tế

Ứng dụng REST API có:

• 50 RPS trung bình, peak 150 RPS.
• Mỗi request cần 120ms CPU.
• Ứng dụng Java, mỗi session giữ 1.5MB RAM.

Tính CPU:

Peak CPU = (150 × 120) / 1000 = 18 cores
→ Nếu chia 6 pod → mỗi pod ~3 cores (requests.cpu: 2.5, limits.cpu: 3.5)

Tính Memory:

Max concurrent ~300
RAM = 300 × 1.5MB = 450MB + 50% buffer = ~700MB
→ requests.memory: 600Mi, limits.memory: 1Gi

📈 Khuyến nghị theo dõi và tuning

• Dùng Prometheus + Grafana hoặc Vertical Pod Autoscaler để theo dõi:
  • container_cpu_usage_seconds_total
  • container_memory_working_set_bytes
• Đo latency per request.
• Tuning dựa theo percentile (p95, p99) thay vì trung bình.
• Kết hợp với HPA hoặc KEDA để scale hiệu quả.

🔚 Tổng kết

Tính toán tài nguyên Pod theo request không thể chính xác 100%, nhưng bạn có thể:

• Ước lượng ban đầu dựa vào RPS và latency.
• Cộng buffer để tránh thiếu hụt tài nguyên.
• Theo dõi thực tế để điều chỉnh về sau.

Việc thiết kế đúng ngay từ đầu giúp hệ thống ổn định, tiết kiệm chi phí và dễ mở rộng trong Kubernetes.