Phân Biệt Readiness Probe vs Liveness Probe Trong Kubernetes

Cơ chế tự phục hồi (Self-healing) là tính năng ăn tiền nhất của Kubernetes. Nhưng nếu bạn cấu hình sai hoặc nhầm lẫn giữa Readiness Probe và Liveness Probe, bạn có thể tự tay tạo ra một vụ sập mạng dây chuyền (Cascading Failure) trên toàn bộ hệ thống!

1. Bản chất và nhiệm vụ của từng loại Probe

Readiness Probe: "Tôi đã sẵn sàng nhận khách chưa?"

Hành động khi FAIL: K8s sẽ ngắt Pod ra khỏi Service Endpoint. Lưu lượng truy cập (Traffic) sẽ không được chuyển vào Pod này nữa.
Pod CÓ BỊ RESTART KHÔNG? ➔ KHÔNG! Container vẫn tiếp tục chạy, K8s chỉ đứng ngoài chờ đợi cho đến khi Probe trả về HTTP 200 trở lại.
Tình huống sử dụng:
Ứng dụng Spring Boot mất 45 giây để nạp dữ liệu cache vào bộ nhớ khi mới khởi động.
Ứng dụng đang bị nghẽn tải tạm thời, cần tạm ngừng nhận request mới để xử lý hết hàng đợi.

Liveness Probe: "Tôi còn sống không hay đã bị Deadlock?"

Hành động khi FAIL: K8s sẽ thẳng tay KILL container và khởi động lại container mới theo chính sách restartPolicy.
Tình huống sử dụng:
Ứng dụng bị Deadlock ở thread xử lý, tiến trình vẫn tồn tại nhưng không thể phục vụ bất kỳ request nào nữa.

2. Cạm bẫy kinh điển: Đặt Liveness Probe trỏ vào Database

Hãy tưởng tượng bạn viết một hàm kiểm tra sức khỏe:

GET /healthz ➔ Kiểm tra kết nối tới MySQL Database

Và bạn dùng endpoint này cho cả Liveness Probe!

Kịch bản thảm hoạ:

Cơ sở dữ liệu MySQL bị quá tải và chậm phản hồi trong 10 giây.
Liveness Probe của tất cả 50 Pod đồng loạt thất bại!
Kubelet trên các node đồng loạt KILL và RESTART toàn bộ 50 Pod.
50 Pod vừa hồi sinh lại đồng loạt kết nối vào MySQL để khởi tạo connection pool.
MySQL sập hoàn toàn ➔ Toàn bộ hệ sinh thái chết đứng!

Quy tắc chuẩn:

Liveness Probe: Chỉ kiểm tra sức khỏe nội tại của tiến trình (Internal State), tuyệt đối không kiểm tra dependency bên ngoài như DB, Redis hay API bên thứ 3.
Readiness Probe: Có thể kiểm tra kết nối DB để tạm ngắt nhận request nếu DB chưa sẵn sàng.

3. Cấu hình mẫu chuẩn Production

spec:
  containers:
  - name: my-app
    image: myapp:v1.2.0
    ports:
    - containerPort: 8080

    # Chờ app ấm máy trước khi đưa khách vào
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 3

    # Kiểm tra kẹt deadlock
    livenessProbe:
      httpGet:
        path: /live
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      failureThreshold: 3
      timeoutSeconds: 2