Lab 4 - Autoscaling hệ thống với Horizontal Pod Autoscaler (HPA)
Series: Kubernetes từ Zero đến Production
Tình huống thực tế
Website của công ty chuẩn bị mở chương trình Flash Sale.
Ngày thường:
100 Users
Ngày diễn ra Flash Sale:
10,000 Users
Nếu hệ thống vẫn chỉ chạy với 3 Backend Pods như Lab 3, điều gì sẽ xảy ra?
- CPU tăng lên 100%
- Request xử lý chậm
- Người dùng phải chờ lâu
- Có thể xảy ra timeout hoặc lỗi 5xx
Một lựa chọn là tăng số lượng Pod lên 20.
Nhưng sau khi Flash Sale kết thúc thì sao?
20 Pod sẽ tiếp tục chạy dù chỉ còn vài chục người dùng, gây lãng phí tài nguyên.
Giải pháp tốt hơn là để Kubernetes tự động điều chỉnh số lượng Pod theo tải thực tế.
Đó chính là nhiệm vụ của Horizontal Pod Autoscaler (HPA).
Mục tiêu
Sau bài lab này, bạn sẽ:
- Hiểu Horizontal Pod Autoscaler hoạt động như thế nào
- Cài đặt Metrics Server
- Tạo HPA cho Backend
- Sinh tải bằng Apache Benchmark và k6
- Quan sát Kubernetes tự động scale Pods
- Hiểu vòng đời Scale Up và Scale Down
Kiến trúc Autoscaling
CPU Usage
│
▼
Metrics Server
│
▼
Horizontal Pod Autoscaler
│
Scale Deployment
│
Backend Pods (2~20)
│
PostgreSQL
Luồng hoạt động:
- Metrics Server thu thập CPU của Pod.
- HPA đọc các chỉ số này.
- Nếu CPU vượt ngưỡng, HPA tăng số lượng Pod.
- Khi tải giảm, HPA tự động giảm Pod.
Điều kiện tiên quyết
Tiếp tục sử dụng hệ thống Todo ở Lab 3.
Kiểm tra:
kubectl get all -n todo-app
Đảm bảo:
- Frontend Running
- Backend Running
- PostgreSQL Running
Phần 1. Kiểm tra Metrics Server
HPA cần Metrics Server để lấy thông tin CPU và Memory.
Kiểm tra:
kubectl top nodes
Nếu hiển thị CPU và Memory nghĩa là Metrics Server đã hoạt động.
Ví dụ:
NAME CPU(cores) MEMORY(bytes)
minikube 420m 1850Mi
Kiểm tra Pod:
kubectl top pods -n todo-app
Ví dụ:
todo-backend
CPU: 120m
Memory: 410Mi
Nếu các lệnh trên báo lỗi, hãy cài hoặc bật Metrics Server trước khi tiếp tục.
Phần 2. Tạo Horizontal Pod Autoscaler
Tạo HPA:
kubectl autoscale deployment todo-backend \
--cpu-percent=70 \
--min=2 \
--max=20 \
-n todo-app
Hoặc khai báo bằng YAML:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: todo-backend
spec:
minReplicas: 2
maxReplicas: 20
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: todo-backend
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
Ý nghĩa:
- Tối thiểu 2 Pods
- Tối đa 20 Pods
- Scale khi CPU trung bình vượt 70%
Phần 3. Quan sát HPA
Kiểm tra:
kubectl get hpa -n todo-app
Ví dụ:
NAME TARGETS MINPODS MAXPODS REPLICAS
todo-backend 15% / 70% 2 20 2
Quan sát liên tục:
kubectl get hpa -w -n todo-app
Phần 4. Sinh tải với Apache Benchmark
Apache Benchmark (ab) là công cụ đơn giản để gửi nhiều HTTP request trong thời gian ngắn.
Ví dụ:
ab -n 10000 -c 100 \
http://todo.company.local/api/todos
Ý nghĩa:
- 10.000 request
- 100 request đồng thời
Theo dõi CPU:
kubectl top pods -n todo-app
Bạn sẽ thấy CPU của Backend tăng lên.
Phần 5. Quan sát Scale Up
Theo dõi Pods:
kubectl get pods -w -n todo-app
Ban đầu:
Backend
Pod A
Pod B
Sau khi CPU vượt ngưỡng:
Backend
Pod A
Pod B
Pod C
Pod D
Pod E
Kiểm tra Deployment:
kubectl get deployment todo-backend -n todo-app
Bạn sẽ thấy số lượng Replica tăng dần.
Đây là lúc Kubernetes tự động mở rộng hệ thống để đáp ứng lượng truy cập tăng cao.
Phần 6. Sinh tải với k6
Ngoài Apache Benchmark, một công cụ rất phổ biến trong kiểm thử hiệu năng là k6.
Ví dụ script:
import http from 'k6/http';
export default function () {
http.get('http://todo.company.local/api/todos');
}
Chạy:
k6 run script.js
So với Apache Benchmark:
| Công cụ | Phù hợp với |
|---|---|
| Apache Benchmark | Kiểm tra nhanh một endpoint |
| k6 | Mô phỏng nhiều kịch bản người dùng, dễ tích hợp vào CI/CD |
Trong các dự án thực tế, k6 thường được sử dụng nhiều hơn khi cần kiểm thử tải một cách linh hoạt.
Phần 7. Quan sát Scale Down
Dừng Load Test.
Tiếp tục theo dõi:
kubectl get hpa -w -n todo-app
Sau một khoảng thời gian:
5 Pods
↓
4 Pods
↓
3 Pods
↓
2 Pods
Kubernetes không xóa Pod ngay lập tức.
HPA sẽ chờ hệ thống ổn định trước khi giảm số lượng Pod để tránh việc liên tục Scale Up và Scale Down trong thời gian ngắn.
HPA hoạt động như thế nào?
Khi CPU tăng:
CPU tăng
│
Metrics Server
│
Horizontal Pod Autoscaler
│
Deployment
│
ReplicaSet
│
Pods tăng từ 2 → 5 → 8 ...
Khi CPU giảm:
CPU giảm
│
Metrics Server
│
Horizontal Pod Autoscaler
│
Deployment
│
Pods giảm về mức tối thiểu
Điểm quan trọng là HPA không tạo Pod trực tiếp.
Nó chỉ thay đổi số lượng Replica của Deployment, còn Deployment sẽ chịu trách nhiệm tạo hoặc xóa Pod.
Thử tạo lỗi
Tình huống 1: Metrics Server không hoạt động
Kiểm tra:
kubectl top pods
Nếu xuất hiện lỗi:
Metrics API not available
HPA sẽ không thể lấy số liệu CPU và sẽ không tự động scale.
Tình huống 2: Không khai báo Resource Requests
Nếu Deployment không có:
resources:
requests:
cpu: 500m
HPA có thể không tính được tỷ lệ sử dụng CPU chính xác.
Đây là lý do Lab 3 luôn yêu cầu cấu hình Resource Requests trước khi triển khai HPA.
Dọn dẹp
Nếu không muốn giữ HPA:
kubectl delete hpa todo-backend -n todo-app
Hoặc tiếp tục sử dụng để chuẩn bị cho Lab 5.
Những gì bạn đã học
Sau bài lab này, bạn đã biết:
✅ Vai trò của Metrics Server
✅ Horizontal Pod Autoscaler (HPA)
✅ Cấu hình minReplicas và maxReplicas
✅ Scale theo CPU Usage
✅ Sinh tải bằng Apache Benchmark
✅ Sinh tải bằng k6
✅ Quan sát Scale Up
✅ Quan sát Scale Down
✅ Mối quan hệ giữa HPA và Deployment
Bài học rút ra
Một hệ thống production không nên sử dụng số lượng Pod cố định.
Khi lượng người dùng tăng, hệ thống cần mở rộng đủ nhanh để duy trì hiệu năng.
Khi lượng truy cập giảm, hệ thống cũng cần tự động thu hẹp để tiết kiệm tài nguyên.
Horizontal Pod Autoscaler giúp Kubernetes thực hiện điều đó một cách tự động dựa trên các chỉ số thực tế, thay vì phụ thuộc vào thao tác thủ công của DevOps Engineer.
Ở bài lab tiếp theo, chúng ta sẽ tiếp tục xây dựng khả năng quan sát (Observability) cho hệ thống bằng cách triển khai Prometheus và Grafana để theo dõi CPU, Memory, Request và nhiều chỉ số quan trọng khác của toàn bộ Kubernetes Cluster.
All rights reserved
