Vấn đề khi KHÔNG có Probes
Kịch bản 1: App bị "Treo" (Zombies)
Container vẫn Running nhưng logic bên trong bị Deadlock. Traffic vẫn đổ vào và User nhận lỗi 500 liên tục.
Kịch bản 2: App đang Khởi động
App nặng (Java/Legacy) mất 30s để init. Nếu không có probe, K8s đẩy traffic ngay lập tức gây lỗi kết nối.
So sánh 3 loại Probes
| Đặc tính | Startup Probe | Readiness Probe | Liveness Probe |
|---|---|---|---|
| Mục đích chính | Kiểm tra app đã khởi động xong chưa? | App đã sẵn sàng nhận traffic chưa? | App còn sống hay đã bị treo/chết? |
| Hành động khi FAIL | Restart Container | Tách Pod khỏi Service (No Traffic) | Restart Container |
| Thời điểm chạy | Chạy đầu tiên, block 2 probe kia. | Xuyên suốt vòng đời Pod. | Xuyên suốt (sau Startup). |
| Use Case | App khởi động chậm (>1 phút). | Đợi DB migrate, load cache. | Phát hiện Deadlock, Memory Leak. |
Pod Lifecycle & Probe Timeline
Chú ý: Khi Startup Probe đang chạy, Liveness và Readiness sẽ bị tạm dừng để tránh việc Container bị restart oan khi chưa kịp khởi động xong.
Interactive Probe Simulator
Pod-01 (Stable)
Pod-02 (Stable)
Pod-03 (Stable)
Kubelet Logs
Cấu hình YAML & Các tham số
# Liveness Probe Configuration livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 # (1) periodSeconds: 10 # (2) timeoutSeconds: 2 # (3) failureThreshold: 3 # (4) successThreshold: 1 # (5)
initialDelaySeconds: Đợi bao lâu sau khi container start mới bắt đầu check. Quá ngắn → CrashLoopBackOff.
periodSeconds: Tần suất kiểm tra (mặc định 10s). Quá dày → tốn tài nguyên CPU.
failureThreshold: Sai bao nhiêu lần liên tiếp thì Kubelet mới "ra tay" (Restart/Evict).
Danger Zone ⚠️
Cấu hình liveness quá "hung hăng" (timeout thấp, failureThreshold = 1) có thể khiến Pod liên tục bị restart dù vẫn đang xử lý request nặng.
Probe Methods: Cách thức kiểm tra
httpGet
Kubelet gửi HTTP GET tới endpoint (ví dụ /health). Trạng thái 200-399 là Pass.
tcpSocket
Thử mở một kết nối TCP tới port chỉ định. Nếu mở được là Pass.
exec
Chạy một lệnh shell bên trong container. Exit code 0 là Pass.
Anti-patterns & Lỗi phổ biến
Dùng chung Endpoint cho Liveness & Readiness
Khi DB chết, Readiness nên fail (ngừng traffic), nhưng Liveness không nên fail (vô nghĩa khi restart pod nếu lỗi do DB ngoại vi).
Liveness Probe quá Aggressive
Set timeoutSeconds: 1 cho một Java app đang chịu tải cao khiến pod restart liên tục ngay khi nó vừa khởi động lại xong.
Bỏ quên Startup Probe cho App nặng
Ép Liveness phải gánh cả việc "đợi khởi động" bằng cách tăng initialDelaySeconds cực lớn (lãng phí thời gian khi pod thực sự crash sớm).
Kiểm tra dependencies bên ngoài bằng Liveness
Nếu Liveness check kết nối tới 3rd party API và API đó sập → Toàn bộ cluster của bạn sẽ bị restart loop (Cascading Failure).