Cách hoạt động của Kubernetes Probes: Hướng dẫn chi tiết từ cơ bản đến nâng cao

Kubernetes probes là công cụ kiểm tra sức khỏe container giúp ứng dụng của bạn hoạt động ổn định và tránh các sự cố nghiêm trọng như vòng lặp khởi động lại kéo dài hoặc mất request trong quá trình rollout.

Bài viết này sẽ hướng dẫn bạn ba loại probe chính trong Kubernetes (startup, readiness, liveness), cách cấu hình và kết hợp chúng một cách hiệu quả. Bạn sẽ thấy rõ các lỗi cấu hình điển hình khiến hệ thống sập, và cách probes ảnh hưởng trực tiếp đến tốc độ triển khai Deployment.

Pod không có probes — vấn đề cơ bản

Khi bạn chạy một Pod đơn giản với container my-app:latest, ứng dụng cần vài giây để khởi tạo trước khi lắng nghe trên cổng 8080. Tuy nhiên, Kubernetes mặc định coi container là Ready ngay khi nó bắt đầu chạy, dù ứng dụng bên trong chưa sẵn sàng nhận traffic.

Điều này gây ra lỗi: nếu bạn khởi động lại container trong khi request đang được gửi tới, request đó sẽ thất bại, mặc dù Kubernetes vẫn coi container là sẵn sàng.

Khi container crash, Kubernetes sẽ khởi động lại ngay. Sau lần crash thứ hai, hệ thống áp dụng CrashLoopBackOff với thời gian chờ tăng dần: mặc định 10 giây, nhân đôi sau mỗi lần crash, tối đa 5 phút.

Ba loại probe trong Kubernetes

Kubernetes cung cấp ba loại probe để giải quyết vấn đề trên:

• Startup probe: Xác định ứng dụng trong container đã khởi động xong hay chưa
• Readiness probe: Xác định ứng dụng đã sẵn sàng nhận traffic hay chưa
• Liveness probe: Xác định ứng dụng có cần khởi động lại hay không

Probes có thể sử dụng các phương thức kiểm tra: httpGet, tcpSocket, exec, hoặc grpc. Trong hầu hết các trường hợp, httpGet là lựa chọn phổ biến nhất.

Startup probes: Kiểm tra quá trình khởi động

Startup probe gửi yêu cầu HTTP tới một endpoint cụ thể trên container. Các mã trạng thái 200-399 được coi là thành công.

startupProbe:
  httpGet:
    path: "/startup"
    port: 8080
  periodSeconds: 1
  failureThreshold: 5

Với cấu hình trên, container có khoảng 5 giây (periodSeconds × failureThreshold) để hoàn tất khởi động. Nếu không kịp, Kubernetes sẽ kill container và khởi động lại.

Lưu ý quan trọng: Khi container chưa qua startup probe, nó sẽ ở trạng thái NotReady. Tuy nhiên, nếu các service khác gửi request trực tiếp đến IP của pod, traffic vẫn sẽ đến và thất bại.

Kết hợp với ReplicaSet và Service

Để giải quyết triệt để, bạn cần sử dụng ReplicaSet (chạy nhiều bản sao) và Service (load balancing). Kubernetes dựa vào trạng thái Ready để đưa pod vào hoặc loại pod khỏi danh sách nhận traffic của Service.

# replica-set-a.yaml
apiVersion: "apps/v1"
kind: "ReplicaSet"
metadata:
  name: "replica-set-a"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: "pod-a"
  template:
    metadata:
      labels:
        app: "pod-a"
    spec:
      containers:
        - name: "app"
          image: "my-app:latest"
          startupProbe:
            httpGet:
              path: "/startup"
              port: 8080
            periodSeconds: 1
            failureThreshold: 5

Khi một pod chưa Ready, Service sẽ không gửi traffic tới nó. Traffic sẽ được chuyển hướng sang các pod còn lại.

Graceful termination: Xóa pod đúng cách

Thay vì crash đột ngột, bạn nên xóa pod (delete) để ReplicaSet tạo pod mới thay thế. Khi pod bị xóa:

1. Kubernetes gửi tín hiệu SIGTERM cho container
2. Container có thời gian terminationGracePeriodSeconds (mặc định 30 giây) để hoàn tất các request đang xử lý
3. Pod bị chuyển sang trạng thái Terminating và bị loại khỏi Service ngay lập tức

Điều này giúp không có request nào bị rơi trong quá trình thay thế pod. Hãy chắc chắn thời gian graceful period đủ dài cho các request có thời gian xử lý lâu nhất.

Lỗi cấu hình startup probe thường gặp

Vấn đề phổ biến nhất là đặt failureThreshold quá thấp. Nếu thời gian khởi động của ứng dụng lâu hơn tổng thời gian cho phép (periodSeconds × failureThreshold), container sẽ bị kill liên tục và rơi vào CrashLoopBackOff.

Trong thực tế, hãy chọn giá trị dựa trên thời gian khởi động tệ nhất của ứng dụng, cộng thêm một chút dư địa an toàn.

Readiness probes: Kiểm tra trạng thái sẵn sàng

Sau khi startup probe thành công, readiness probe sẽ tiếp tục theo dõi container. Nếu probe thất bại đủ failureThreshold lần, container sẽ bị đánh dấu NotReady và bị loại khỏi Service.

readinessProbe:
  httpGet:
    path: "/ready"
    port: 8080
  periodSeconds: 3
  failureThreshold: 1
  successThreshold: 1

Mẹo thực tế: Không nên đặt failureThreshold: 1 vì một lỗi tạm thời cũng sẽ khiến pod bị loại khỏi Service. Giá trị mặc định 3 là hợp lý cho hầu hết trường hợp.

Tại sao cần cả startup và readiness probe?

Startup probe đảm bảo ứng dụng đã khởi động xong trước khi readiness và liveness probe bắt đầu. Điều này cho phép:

• Probing startup nhanh (mỗi giây) để phát hiện sớm, sau đó giảm tần suất readiness xuống (mỗi 5 giây) để giảm tải
• Khởi động lại container nếu startup bị kẹt — điều mà readiness probe không làm được

Liveness probes: Khởi động lại khi kẹt

Liveness probe hoạt động giống readiness, nhưng khi đạt failureThreshold, thay vì đánh dấu NotReady, Kubernetes sẽ kill container và áp dụng restartPolicy (mặc định là "Always" — luôn khởi động lại).

livenessProbe:
  httpGet:
    path: "/live"
    port: 8080
  periodSeconds: 2
  failureThreshold: 1

Probe này hữu ích khi container không thể tự phục hồi, ví dụ khi luồng chính bị deadlock hoặc một thread nền quan trọng bị chết.

Lỗi cấu hình liveness probe nghiêm trọng

Sai lầm lớn nhất: Kiểm tra sức khỏe của các dependency dùng chung như database trong liveness probe.

# CẤU HÌNH SAI — Không nên làm!
livenessProbe:
  httpGet:
    path: "/database-health"
    port: 8080

Nếu database gặp sự cố trong vài phút, tất cả container sẽ bị kill và rơi vào CrashLoopBackOff. Tệ hơn, khi database phục hồi, các client gửi retry sẽ tạo ra thundering herd — một luồng traffic khổng lồ khiến từng container vừa khởi động lại nhanh chóng bị quá tải và chết tiếp.

Nguyên tắc vàng: Chỉ fail liveness probe khi vấn đề là local (chỉ xảy ra trên một container) và việc khởi động lại có khả năng phục hồi được.

Probes ảnh hưởng đến Deployment như thế nào

Trong Kubernetes, hầu hết nội dung Pod spec là bất biến (immutable). Để cập nhật, bạn phải tạo pod mới và xóa pod cũ. Deployment quản lý quá trình thay thế này bằng chiến lược RollingUpdate.

strategy:
  type: "RollingUpdate"
  rollingUpdate:
    maxUnavailable: "25%"
    maxSurge: "25%"

• maxUnavailable: Số pod tối đa được phép không khả dụng (25% của 3 = 0, nghĩa là luôn phải giữ 3 pod hoạt động)
• maxSurge: Số pod tối đa được phép vượt quá replicas (25% của 3 = 1, nghĩa là tối đa 4 pod tồn tại đồng thời)

Tốc độ rollout phụ thuộc trực tiếp vào probes. Với startup probe chạy mỗi giây, rollout mất khoảng 11 giây. Nếu tăng periodSeconds lên 5 giây, thời gian tăng lên 19-20 giây. Nếu không có probes, rollout rất nhanh nhưng gây mất request do container chưa sẵn sàng.

Lời khuyên thiết kế probe endpoint

Startup probe

• Sử dụng khi thời gian khởi động chậm hoặc không ổn định
• Probe thường xuyên để phát hiện sớm, nhưng tăng failureThreshold tương ứng
• Tạo endpoint /startup riêng nếu có những kiểm tra đặc thù cho quá trình init

Readiness probe

• Giữ probe nhẹ và thận trọng
• Không fail dựa trên trạng thái database hoặc API bên thứ ba dùng chung
• Không fail khi CPU hoặc memory cao — có thể gây cascading failure

Liveness probe

• Chỉ fail khi chắc chắn container bị kẹt và restart sẽ giúp ích
• Không kiểm tra các dependency dùng chung
• Không fail vì tải cao

Tổng kết

Probes trong Kubernetes là công cụ mạnh mẽ nhưng dễ cấu hình sai. Hiểu rõ ba loại probe, cách kết hợp chúng và những lỗi điển hình sẽ giúp bạn:

• Tránh mất request trong quá trình rollout
• Ngăn chặn vòng lặp khởi động lại kéo dài
• Giảm thiểu ảnh hưởng của sự cố hạ tầng
• Tăng độ tin cậy tổng thể của ứng dụng

Hãy thử nghiệm trên môi trường staging trước, bắt đầu với các giá trị mặc định an toàn, và điều chỉnh dần dựa trên hành vi thực tế của ứng dụng. Với nhu cầu Kubernetes tại Việt Nam đang tăng mạnh, việc nắm vững probes là kỹ năng quan trọng cho bất kỳ DevOps engineer hay developer nào làm việc với hạ tầng container.