Pod lifecycle, probes và termination
Pod là scheduling unit chứa một hoặc nhiều container cùng chia sẻ network namespace và có thể chia sẻ volumes. Pod là ephemeral: kubelet có thể restart container bên trong cùng Pod, nhưng khi cần thay một Pod đã mất thì controller như Deployment/ReplicaSet mới tạo Pod mới để duy trì desired replica.
1. Pod Lifecycle
Một Pod được scheduler bind vào một node và chỉ được schedule một lần trong lifetime. Trên node đó, kubelet reconcile Pod spec với trạng thái thật: chuẩn bị sandbox/network, mount volumes, pull image, chạy init containers theo thứ tự, sau đó chạy application containers và các sidecar phù hợp với spec.
restartPolicy điều khiển việc kubelet restart container trong cùng Pod (Always, OnFailure, Never). Nó không biến Pod thành durable object: nếu node chết hoặc controller quyết định replace replica, workload thường được phục hồi bằng Pod mới với UID mới.
2. Startup
Đường đi điển hình là: scheduler bind Pod → kubelet chuẩn bị volume và runtime sandbox/network → init containers chạy tuần tự → application/sidecar containers khởi động → startup/readiness/liveness probes bắt đầu theo cấu hình.
Với ứng dụng startup chậm, startup probe tạo một failure window riêng. Khi startup probe được cấu hình, kubelet chưa chạy liveness và readiness cho đến khi startup probe thành công. Nếu startup probe thất bại quá failureThreshold, container bị kill và được xử lý theo restart policy.
Budget startup gần đúng là failureThreshold × periodSeconds (cộng thêm chi tiết timing/timeout của từng probe). Ví dụ 30 lần, mỗi 10 giây cho phép khoảng 300 giây trước khi startup bị coi là thất bại.
3. Probe semantics
| Probe | Nó trả lời câu hỏi gì? | Khi fail | Dùng cho |
|---|---|---|---|
| startup | Ứng dụng đã khởi động xong chưa? | Sau threshold, kubelet restart container theo restart policy. | Slow startup, warm-up dài, tránh liveness giết app quá sớm. |
| readiness | Container hiện tại có nên nhận traffic không? | Container vẫn chạy, nhưng Pod không Ready và endpoint không nhận regular Service traffic. | Warm-up, overload tạm thời, dependency tạm mất, maintenance/draining signal. |
| liveness | Process có rơi vào trạng thái local unrecoverable cần restart không? | Sau threshold, kubelet restart container. | Deadlock/stuck state mà restart process thực sự có khả năng chữa. |
Kết quả probe có thể là Success, Failure hoặc Unknown. Với readiness failure, kubelet tiếp tục chạy container và tiếp tục probe; với startup/liveness failure đạt threshold, kubelet tiến tới restart container.
Các tham số vận hành chính gồm initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold và successThreshold. Liveness/startup yêu cầu successThreshold=1. Cơ chế probe phổ biến là HTTP, TCP, gRPC hoặc exec.
exec) hoặc gọi chain dependency dài có thể tự tạo CPU/network pressure. Liveness nên ưu tiên signal nội bộ của process; readiness có thể nghiêm ngặt hơn nếu traffic thực sự không thể phục vụ.4. Termination
Khi Pod bị delete, grace period bắt đầu. Pod được đánh dấu terminating; endpoint tương ứng được cập nhật để không còn nhận regular traffic. Nếu có preStop, hook đó chạy trong cùng termination grace budget; sau đó runtime gửi SIGTERM cho process trong container. Khi grace period hết mà process vẫn còn, runtime buộc dừng bằng SIGKILL.
preStop không phải delay miễn phí. Thời gian hook tiêu vào cùng terminationGracePeriodSeconds. Ứng dụng nên bắt SIGTERM, ngừng nhận request mới, drain connection/request đang xử lý trong một thời gian bounded, flush state cần thiết rồi exit trước deadline.
Terminating endpoints có ready=false để regular load balancer không tiếp tục chọn chúng. Tuy nhiên connection đã tồn tại hoặc các thành phần ngoài Kubernetes có thể vẫn cần thời gian drain, vì vậy shutdown logic ở app/proxy vẫn phải đúng.
Probe-level terminationGracePeriodSeconds có thể override Pod-level grace cho liveness/startup probe; readiness probe không dùng override này. Kubernetes documentation hiện tại ghi feature này stable từ v1.28.
5. States and evidence
Pod phase là tập nhỏ gồm Pending, Running, Succeeded, Failed (và Unknown trong một số quan sát API cũ/edge cases). Các chuỗi như CrashLoopBackOff hoặc ImagePullBackOff là container waiting reasons/backoff được CLI hiển thị, không phải Pod phase.
Khi debug, đọc evidence theo thứ tự thay vì chỉ nhìn cột STATUS:
- Pod conditions:
Ready,ContainersReady, scheduling/network-related conditions khi có. - Current và last container state, reason, exit code, signal, started/finished timestamp.
restartCountđể nhận biết crash/restart trend.- Events để tìm scheduling, image pull, mount, probe failure, eviction hoặc sandbox/network error.
- Current logs và
kubectl logs --previouskhi container vừa restart.
Pod Ready chỉ nói readiness conditions hiện tại đạt yêu cầu; nó không chứng minh toàn bộ user journey, downstream dependency hay business transaction đều healthy. Production monitoring vẫn cần request success/latency, saturation, dependency signals và end-to-end checks.
6. Production signals và capacity
| Signal | Điều cần phân biệt | Rủi ro |
|---|---|---|
| Restart rate / CrashLoopBackOff | App crash, liveness false positive, OOMKilled, config/secret lỗi | Capacity tụt, reconnect storm, cache cold |
| NotReady duration / Ready replicas | Warm-up, dependency outage, overload, probe timeout | Service còn quá ít endpoints để gánh traffic |
| Startup latency | Image pull, mount, init container, app initialization | Rollout/scale-out không bắt kịp spike |
| Termination duration | Drain bình thường hay process treo không exit | Forced SIGKILL, request loss, deploy chậm |
| Probe latency/failure | App thật sự lỗi hay node/probe overhead | False restart hoặc false traffic removal |
Giữ headroom để rollout hoặc node failure không làm tất cả remaining Pods quá tải rồi readiness/liveness cùng fail. Probe threshold không thể thay cho capacity planning: nếu mỗi Pod chỉ còn vài phần trăm spare CPU và một replica mất, cascading failure vẫn có thể xảy ra dù probe “đúng”.
7. Security, rollback và recovery
Health endpoint không nên leak secret, config chi tiết, stack trace hoặc dependency credentials. Nếu endpoint được expose ra ngoài Pod/network boundary, áp dụng network policy/auth phù hợp với architecture; kubelet vẫn phải có đường thực hiện probe như spec yêu cầu.
Khi thay probe trong production, rollout theo canary và quan sát restart/NotReady/latency trước khi mở rộng. Nếu probe mới gây false positive, rollback manifest nhanh hơn việc tăng threshold mù quáng. Sau incident do liveness storm, recovery nên ưu tiên ổn định capacity: rollback probe/config, giảm concurrent rollout/restart, rồi mới phân tích root cause.