Liveness, readiness và startup probe là gì, và khi nào dùng từng loại?

Question

IT Interview Practice · Accepted Answer

Probe cho phép kubelet kiểm tra sức khỏe của một container và hành động theo kết quả. Có ba loại: **liveness** (nó còn sống, hay nên được restart?), **readiness** (nó đã sẵn sàng nhận lưu lượng chưa?), và **startup** (nó đã khởi động xong chưa?). Mỗi loại trả lời một câu hỏi khác nhau.

## Ba probe nhìn thoáng qua

```text
LIVENESS   → "App có bị kẹt/deadlock không?"   LỖI → kubelet RESTART container
READINESS  → "Có phục vụ lưu lượng ngay được không?" LỖI → Pod bị gỡ khỏi endpoint
                                                            của Service (KHÔNG restart)
STARTUP    → "Quá trình boot chậm đã xong chưa?" chạy ĐẦU TIÊN; trong lúc nó chạy,
                                                  liveness & readiness bị hoãn lại
```

## Readiness so với liveness — sự phân biệt then chốt

```text
Readiness điều khiển LƯU LƯỢNG:
  → một Pod trượt readiness bị KÉO RA khỏi load-balancer của Service,
    nhưng vẫn chạy (ví dụ đang khởi động cache hoặc một phụ thuộc đang down)
Liveness điều khiển SỰ SỐNG:
  → một Pod trượt liveness bị GIẾT và restart (đã hỏng không thể tự phục hồi)
Dùng liveness khi ý bạn là readiness sẽ gây vòng lặp restart vô ích.
```

## Định nghĩa probe

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # cho app khởi động chậm thời gian trước khi cái khác vào
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = tối đa 5 phút để khởi động
        periodSeconds: 10

readinessProbe:          # kiểm soát lưu lượng
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # restart nếu không khỏe
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Các cơ chế probe

```text
httpGet    → GET một đường dẫn; 2xx/3xx = đạt    (phổ biến nhất cho web app)
tcpSocket  → có mở được kết nối TCP không?        (cho dịch vụ không phải HTTP)
exec       → chạy một lệnh; exit 0 = đạt          (kiểm tra tùy biến)
grpc       → health check gRPC gốc
Các núm chỉnh chính: initialDelaySeconds, periodSeconds, timeoutSeconds,
                     failureThreshold, successThreshold.
```

## Vì sao có startup probe

```text
App khởi động chậm (JVM warmup, migration lớn) trước đây buộc bạn đặt initialDelaySeconds
rất lớn cho liveness — khiến crash thật bị phát hiện chậm.
startupProbe khắc phục: nó bảo vệ quá trình boot chậm, và CHỈ sau khi nó đạt thì
liveness/readiness mới bắt đầu với timing (chặt) bình thường.
```

```bash
kubectl describe pod app     # xem lỗi probe & lý do restart trong events
kubectl get pod app          # cột READY phản ánh readiness; RESTARTS phản ánh liveness
```

## Tại sao điều này quan trọng

Health probe là cách Kubernetes mang lại khả năng tự phục hồi và định tuyến lưu lượng an toàn, nên hiểu ba loại và khi nào dùng từng cái là kiến thức độ tin cậy thiết yếu. Sự phân biệt then chốt — thứ khiến nhiều kỹ sư vấp — là giữa **readiness** và **liveness**: readiness điều khiển **lưu lượng** (một Pod trượt bị kéo ra khỏi load-balancer của Service nhưng vẫn chạy, lý tưởng khi nó đang khởi động hoặc một phụ thuộc tạm down), còn liveness điều khiển **sự sống** (một Pod trượt bị giết và restart, cho khi nó deadlock không thể phục hồi). Nhầm lẫn hai cái — dùng liveness khi ý là readiness — gây vòng lặp restart vô ích và sự cố, nên biết mỗi probe trả lời câu hỏi nào là điều rất thực tế. **Startup** probe giải quyết một nỗi đau lịch sử thật: app khởi động chậm từng buộc đặt `initialDelaySeconds` rất lớn cho liveness (làm chậm việc phát hiện crash thật), trong khi startup probe bảo vệ khoảng thời gian boot và cho liveness/readiness chạy với timing chặt, bình thường chỉ khi startup thành công. Hiểu các cơ chế probe (`httpGet`, `tcpSocket`, `exec`, `grpc`) và các núm chỉnh (`initialDelaySeconds`, `periodSeconds`, `failureThreshold`, v.v.) giúp bạn cấu hình health check đúng thay vì đoán mò. Vì probe trực tiếp quyết định liệu người dùng có chạm vào Pod khỏe mạnh và liệu Pod hỏng có tự phục hồi, làm đúng chúng là điều nền tảng để chạy workload đáng tin cậy, cấp production trên Kubernetes.

Ba probe nhìn thoáng qua

Readiness so với liveness — sự phân biệt then chốt

Định nghĩa probe

Các cơ chế probe

Vì sao có startup probe

Tại sao điều này quan trọng

Câu hỏi liên quan