Docker & KubernetesHPA vốn là vòng điều khiển có độ trễ nhiều tầng, nên độ trễ và dao động đều là hệ quả cấu hình chứ không phải lỗi.
Nguồn trễ cộng dồn:
1. metrics-server scrape kubelet mỗi ~15s và bản thân giá trị đã là trung bình → metric đã cũ vài chục giây.
2. HPA controller đánh giá theo chu kỳ (mặc định 15s).
3. Pod mới còn phải pull image, khởi động, pass readiness — thường là phần lâu nhất.
Cộng lại có thể vài phút mới có thêm capacity. Nếu spike traffic dốc, HPA về bản chất không kịp — phải chuẩn bị bằng cách giữ headroom (hạ averageUtilization xuống ~50-60%), hoặc pre-scale theo lịch cho các sự kiện biết trước.
Điều kiện dễ bỏ sót: HPA theo CPU utilization tính phần trăm so với requests.cpu. Container không đặt request thì HPA không tính được và báo <unknown>, không scale gì cả.
Dao động lên xuống xử lý bằng behavior policy:
behavior:
scaleDown:
stabilizationWindowSeconds: 300 # cho scale xuong cham lai
policies: [{ type: Percent, value: 50, periodSeconds: 60 }]
scaleUp:
stabilizationWindowSeconds: 0 # len ngay
policies: [{ type: Percent, value: 100, periodSeconds: 30 }]- Nguyên tắc: lên nhanh, xuống chậm.
- Với workload dựa vào hàng đợi, metric CPU thường sai bản chất — nên dùng custom metric (độ dài queue, request/s) qua Prometheus Adapter hoặc KEDA.
- Cuối cùng, không dùng HPA cùng VPA trên cùng một metric vì hai bộ điều khiển sẽ chống nhau.