Lộ trình
Cloud Native Computing FoundationAssociateTuần 3: Kiến trúc & bảo mậtBài 16 / 30

Ngày 16: Startup Probe

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
ckadngày 16
hoàn thành16 / 30 bài
Bối cảnh bài học

Dùng Startup Probe cho ứng dụng khởi động chậm và phối hợp cả startup/readiness/liveness để tránh false restart nhưng vẫn phát hiện hung process sau khi app đã sẵn sàng.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Dùng Startup Probe cho ứng dụng khởi động chậm và phối hợp cả startup/readiness/liveness để tránh false restart nhưng vẫn phát hiện hung process sau khi app đã sẵn sàng.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Học use case Startup Probe cho ứng dụng khởi động chậm
  • Thực hành cấu hình kết hợp cả 3 loại probe
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

App Java/migration/cache warm-up cần vài phút; liveness chạy quá sớm làm kubelet restart vô hạn, còn bỏ probe thì app hung vẫn nhận traffic. Bài học thiết kế startup window, chuyển quyền kiểm soát sang liveness/readiness và kiểm chứng timing.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Startup probe chạy trong giai đoạn khởi động; khi chưa thành công, liveness/readiness chưa quyết định theo cách thông thường, giúp bảo vệ app slow-start.
  • failureThreshold × periodSeconds tạo startup budget; budget phải dựa trên p95/p99 startup và failure mode, không đặt vô hạn hoặc quá ngắn.
  • Sau startup success, liveness phát hiện process hung và readiness điều khiển traffic; ba probe có mục tiêu khác nhau dù có thể dùng endpoint chung.
  • Startup probe không sửa dependency/config/image lỗi; nếu app không bao giờ healthy, events/logs phải dẫn tới remediation chứ không tăng timeout vô hạn.

Startup là cửa sổ khởi động

Startup probe bảo vệ app chậm trong giai đoạn đầu; khi pass, readiness quyết định traffic và liveness theo dõi hung process. Tính startup budget: failureThreshold × periodSeconds (cộng timeout/overhead), dựa trên startup distribution và SLO.

Debug theo timeline

  • Startup fail: app chưa qua gate, xem events/logs/command/path và dependency.
  • Startup pass nhưng readiness fail: app chưa đủ điều kiện nhận traffic.
  • Startup pass nhưng liveness fail: process đã khởi động nhưng hung/unhealthy, có thể restart.

Không tăng budget vô hạn để che image/config/dependency failure; verify conditions, EndpointSlice, restart count và rollout.

Bài tập

Dựng app slow-start với cả ba probe, đo state timeline, mô phỏng startup over-budget/hung/readiness failure, chỉnh config và tạo variant. Ghi SLO, rollback và cleanup proof.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
kubectl get pod -n ckad-day16 -o wide
kubectl describe pod POD_NAME -n ckad-day16
kubectl get pod POD_NAME -n ckad-day16 -o jsonpath="{.status.conditions} {.status.containerStatuses[*].restartCount}{"\n"}"
kubectl get endpointslice -n ckad-day16 -o wide
kubectl get events -n ckad-day16 --sort-by=.lastTimestamp
kubectl logs POD_NAME -n ckad-day16 --tail=100
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `ckad-day16`, app mock có startup delay rồi `/healthz`/`/ready`; cấu hình startup + readiness + liveness với budget tính được và ghi expected state transition.
  2. Quan sát Pod conditions, events, restart count, EndpointSlice và logs theo timeline: startup pending → startup success → readiness/traffic → liveness monitoring.
  3. Mô phỏng startup vượt budget, process hung sau startup và readiness dependency fail; phân biệt events/restart/endpoint behavior, không chỉ tăng `failureThreshold` để che lỗi.
  4. Điều chỉnh period/threshold/initial delay, tạo variant startup nhanh/chậm và so sánh detection window/false positive; verify rollout/Available sau mỗi change.
  5. Restore safe probe config, cleanup Deployment/Service/namespace và ghi startup SLO/rollback; không expose admin/debug endpoint qua Service public.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Vai trò/thứ tự tương tác của ba probe đúng.
  • Startup budget có công thức/rationale và evidence timing.
  • Phân biệt startup failure, hung process và readiness dependency.
  • Probe variant có restart/endpoint/availability evidence.
  • Recovery/rollback/cleanup an toàn.
Transfer to exam / production

Bẫy thường gặp và trade-off

Startup probe bảo vệ app chậm khởi động, không phải cách trì hoãn vô hạn. Tính budget bằng period × threshold, sau startup kiểm tra readiness/liveness, events và restart count.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Ứng dụng khởi động 90 giây nhưng liveness bắt đầu kiểm tra sau 10 giây và restart liên tục. Remediation hợp lý nhất là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2