Kubernetes CrashLoopBackOff: Quy Trình Cứu Hoả 4 Bước Chuẩn SRE

CrashLoopBackOff không phải là một lỗi cụ thể. Nó là một cơ chế tự bảo vệ của Kubernetes: khi một container bị sập liên tục, Kubelet sẽ trì hoãn thời gian khởi động lại theo hàm mũ (10s, 20s, 40s... tối đa 5 phút) để tránh làm sập cả Node máy chủ.

Dưới đây là runbook chuẩn hóa 4 bước để xử lý triệt để sự cố CrashLoopBackOff trong vòng 5 phút.

---

Bước 1: Kiểm tra Events của Pod với kubectl describe

kubectl describe pod <pod-name> -n <namespace>

Cuộn xuống phần Last State và phần Events:
- Reason: OOMKilled ➔ Chạm trần Memory Limit (Exit Code 137).
- Reason: Error ➔ Ứng dụng tự crash (Exit Code 1, 2...).
- Back-off restarting failed container ➔ Kubelet đang áp dụng khoảng nghỉ trừng phạt.

---

Bước 2: Xem log của Container TRƯỚC KHI bị chết (--previous)

Khi Pod bị restart, lệnh kubectl logs mặc định sẽ hiển thị log của container MỚI sinh ra (vốn có thể chưa kịp ghi gì). Để đọc log của lần chạy bị sập trước đó:

kubectl logs <pod-name> -n <namespace> --previous

Đây là chìa khóa vàng giúp bạn tìm thấy Stacktrace ngoại lệ (Exception) của ứng dụng.

---

Bước 3: Kiểm tra Init Containers & Liveness Probe

• Nếu Pod kẹt ở trạng thái Init:0/1: Init container chưa hoàn thành (thường do không kết nối được tới Database hoặc Migration fail). Xem log init container:
  bash kubectl logs <pod-name> -c <init-container-name>
• Nếu log ứng dụng hoàn toàn bình thường nhưng Pod vẫn bị restart định kỳ mỗi 3 phút: Kiểm tra lại cấu hình Liveness Probe (initialDelaySeconds quá ngắn khiến app chưa khởi động xong đã bị Kubelet bắn hạ).

---

Bước 4: Khám nghiệm hiện trường với Ephemeral Debug Container

Với Kubernetes v1.23+, bạn có thể gắn một container debug chứa sẵn công cụ (curl, netcat, strace) vào thẳng Pod đang lỗi:

kubectl debug -it <pod-name> --image=nicolaka/netshoot --target=<container-name>