Ai cũng có thể học kubectl qua tutorial, nhưng xử lý sự cố thực tế đòi hỏi hiểu sâu cách các thành phần tương tác — nhà tuyển dụng dùng câu hỏi troubleshooting để phân biệt người vận hành thật với người chỉ biết lý thuyết.
"Pod bị trạng thái CrashLoopBackOff, bạn debug thế nào?" — Quy trình chuẩn: kubectl describe pod xem Events để biết lý do restart, kubectl logs <pod> --previous xem log của lần chạy trước khi crash (log hiện tại có thể chưa kịp ghi gì). Nguyên nhân phổ biến: lỗi ứng dụng khi khởi động, thiếu biến môi trường/config, health check probe sai cấu hình.
"Pod bị Pending mãi không chạy, nguyên nhân có thể là gì?" — kubectl describe pod phần Events thường chỉ rõ: không đủ tài nguyên (CPU/memory request vượt quá capacity node), không có node nào thoả mãn nodeSelector/affinity, hoặc PersistentVolumeClaim chưa bind được.
"Service không route được traffic tới Pod, bạn kiểm tra theo thứ tự nào?" — Kiểm tra label selector của Service có khớp label của Pod không (lỗi phổ biến nhất), Pod có đang Ready không (readinessProbe fail sẽ khiến Pod bị loại khỏi Service endpoint dù đang Running), và endpoint có được tạo đúng không (kubectl get endpoints).
Liveness vs Readiness probe: Liveness probe fail → Kubernetes restart container (nghĩ rằng nó đã "chết"). Readiness probe fail → Kubernetes chỉ ngừng gửi traffic tới Pod đó (không restart) — nhầm lẫn 2 khái niệm này là lỗi phổ biến khiến hệ thống restart loop không cần thiết.
Resource requests vs limits: Request là tài nguyên đảm bảo cho Pod (dùng để scheduler quyết định đặt Pod vào node nào), limit là mức tối đa Pod được dùng — Pod vượt limit memory sẽ bị OOMKilled, vượt limit CPU chỉ bị throttle (giảm tốc, không bị kill).
"Rolling update bị gián đoạn traffic dù đã cấu hình đúng, có thể do đâu?" — Thường do thiếu preStop hook hoặc terminationGracePeriodSeconds quá ngắn khiến Pod bị kill trước khi xử lý xong request đang chạy, hoặc readinessProbe chưa kịp fail trước khi traffic mới vẫn được route tới Pod đang shutdown.
Kể lại 1 sự cố thật (production incident) đã xử lý: triệu chứng ban đầu, các bước debug theo thứ tự logic, nguyên nhân gốc rễ tìm ra, và thay đổi để tránh lặp lại (không chỉ fix tạm thời) — đây là cách trình bày mà nhà tuyển dụng DevOps đánh giá cao nhất.