Họ đang đo gì
Bạn có quy trình không, và có biết --previous để đọc log của lần chạy đã chết.
Trả lời ngắn~30 giây
Thứ tự mình dùng: kubectl describe pod để xem Last State và Exit Code — 137 là bị giết vì OOM, 143 là SIGTERM, 1 là ứng dụng tự thoát. Rồi kubectl logs --previous để đọc log của lần chạy TRƯỚC, vì container hiện tại có thể chưa kịp in gì. Sau đó phân biệt: lỗi cấu hình (thiếu biến môi trường, secret không tồn tại), lỗi phụ thuộc (không kết nối được database), OOM, hay liveness probe quá gắt khiến container bị giết trong lúc còn đang khởi động.
Giải thích sâu
Nguyên nhân thứ tư đáng nói riêng vì nó tự gây ra và rất hay bị chẩn đoán nhầm: ứng dụng cần 40 giây để khởi động, liveness probe có initialDelaySeconds: 10 và failureThreshold: 3, nên nó bị giết trước khi kịp sẵn sàng — mãi mãi. Log không có lỗi nào cả, và mọi người đi tìm bug trong code. Đây chính là lý do startupProbe tồn tại: nó hoãn liveness và readiness cho tới khi ứng dụng báo đã khởi động xong, nên bạn không phải chọn giữa phát hiện nhanh và khởi động chậm.
Với exit code 137, đừng dừng ở “tăng memory limit”. Câu hỏi tiếp theo là bộ nhớ đi đâu. Với JVM trong container, thủ phạm kinh điển là heap được đặt lớn hơn limit của container — JVM hiện đại tự nhận limit của cgroup, nhưng nếu ai đó đặt -Xmx cứng thì nó không quan tâm và kernel sẽ giết tiến trình. Với Node thì tương tự với --max-old-space-size.
Còn một chi tiết vận hành đáng biết: BackOff nghĩa là Kubernetes đang tăng dần thời gian chờ giữa các lần khởi động lại, tới tối đa 5 phút. Nghĩa là nếu bạn sửa cấu hình mà pod không lên ngay thì có thể nó chỉ đang chờ hết backoff — xoá pod để nó khởi động lại ngay thay vì ngồi nghi ngờ bản sửa của mình.
kubectl describe pod $POD | sed -n '/Last State/,/Ready/p'
kubectl logs $POD --previous # log của lần chạy đã chết
kubectl get events --sort-by=.lastTimestamp | tail -20
kubectl debug $POD -it --image=busybox --target=app # khi image không có shellCâu hỏi tiếp theo họ sẽ hỏi
?Pod ở Pending mãi thì sao?
Đó là vấn đề lập lịch chứ không phải ứng dụng: không đủ tài nguyên trên node nào, PVC chưa gắn được, hoặc taint/toleration không khớp. kubectl describe sẽ ghi rõ lý do trong phần Events — đây là một trong ít trường hợp Kubernetes nói thẳng vấn đề là gì.
Trả lời thế này là mất điểm
- Đọc
kubectl logsmà không có--previousrồi kết luận “không có log”. Container hiện tại chưa chạy đủ lâu để in gì. - Tăng limit cho tới khi hết crash. Nó che một rò rỉ bộ nhớ và bạn sẽ gặp lại nó với hoá đơn to hơn.