Lộ trình
Cloud Native Computing FoundationAssociateTuần 4: Tối ưu & vận hànhBài 22 / 30

Ngày 22: Troubleshooting Pod

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

Troubleshoot Pod theo failure signature: Pending, ImagePullBackOff và CrashLoopBackOff bằng context, events, describe, logs và remediation có kiểm chứ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

Troubleshoot Pod theo failure signature: Pending, ImagePullBackOff và CrashLoopBackOff bằng context, events, describe, logs và remediation có kiểm chứng.

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

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

  • Luyện xử lý CrashLoopBackOff, ImagePullBackOff, Pending
  • Thực hành đọc Event và log để xác định nguyên nhân
Instructor walkthrough

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

Scenario xuyên suốt

Một Pod không chạy không có nghĩa nguyên nhân là image. Pending thường nằm ở scheduler/resources/taint/PVC, ImagePullBackOff nằm ở image/registry/credential, còn CrashLoopBackOff là container start rồi chết. Bài học luyện cách phân loại trước khi sửa và chứng minh recovery.

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ế
  • Pending là trạng thái chưa được schedule hoặc chưa đủ điều kiện start; đọc Pod conditions, scheduler events, node resources, taints/affinity và PVC trước khi scale hoặc đổi image.
  • ImagePullBackOff/ErrImagePull thường cần kiểm tra image reference/tag, registry reachability, imagePullSecrets, ServiceAccount và event message; không nhầm với app crash sau khi image đã pull.
  • CrashLoopBackOff là backoff giữa các lần container restart; cần xem current/previous logs, exit code, command/args, env/config/secret, probe và resource limit.
  • Pod Running không đồng nghĩa Ready; readiness/liveness/startup probe có thể tạo symptom khác nhau và cần phân biệt với process exit.

Bắt đầu từ failure signature

  • Pending: Pod chưa được bind node hoặc chưa qua dependency như PVC. Kiểm tra scheduler events, resources, taints/tolerations, affinity, topology và claim.
  • ImagePullBackOff/ErrImagePull: kubelet không lấy được image. Kiểm tra chính xác registry/image/tag, secret, ServiceAccount và network; image đã pull được thì không còn là nhóm lỗi này.
  • CrashLoopBackOff: container đã start nhưng liên tục thoát hoặc probe thất bại. Đọc logs hiện tại và --previous, exit code, command/args, config/secret, probe và resources.

Remediation loop

context → phase/reason → describe/events → logs/previous/conditions → hypothesis → minimal fix → observe → variant → cleanup. Không xóa evidence bằng restart vô thức. Running chỉ nói container process/state, còn Ready mới liên quan traffic; hãy kiểm tra cả hai.

Bài tập

Dựng bốn fixture lỗi trong namespace lab, tạo worksheet có symptom, evidence, hypothesis, expected state, command, fix, rollback và timestamp. Pass khi người khác đọc worksheet có thể phân biệt đúng failure và tái hiện variant.

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 pods -n cka-day22 -o wide
kubectl describe pod POD_NAME -n cka-day22
kubectl get events -n cka-day22 --sort-by=.lastTimestamp
kubectl logs POD_NAME -n cka-day22 --all-containers --tail=100
kubectl logs POD_NAME -n cka-day22 --previous --all-containers --tail=100
kubectl get pod POD_NAME -n cka-day22 -o jsonpath="{.status.containerStatuses[*].state} {.status.containerStatuses[*].lastState}{"\n"}"
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `cka-day22`, marker label/owner và xác nhận context; chuẩn bị bốn fixture lab: sai node selector/resource để Pending, sai image tag để ImagePullBackOff, command exit để CrashLoopBackOff và probe sai để Running nhưng NotReady.
  2. Với mỗi fixture, ghi expected state và chạy `kubectl get pod -o wide`, `describe pod`, events sort theo timestamp; chọn signal đầu tiên có giá trị thay vì restart/xóa Pod.
  3. Thu logs current và `--previous` khi container đã restart; kiểm tra exit code, reason, command/args, env/config/secret reference, probe, resources, ServiceAccount và node placement.
  4. Sửa đúng nguyên nhân trong lab, theo dõi state Pending→Scheduled/Running/Ready hoặc restart count giảm; tạo một variant (đổi tag, command, probe hoặc resource) để chứng minh diagnosis.
  5. Kết thúc bằng kiểm tra owner/rollout state, logs/events sau remediation, rồi xóa namespace lab; không xóa Pod production, không dùng `--force`, không chèn secret vào command/log.
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:

  • Phân loại đúng Pending, ImagePullBackOff, CrashLoopBackOff và Running/NotReady.
  • Mỗi failure có evidence từ describe/events/logs/conditions trước mutation.
  • Sửa đúng lớp nguyên nhân và chứng minh state recovery/rollout.
  • Có variant test và giải thích vì sao symptom tương tự nhưng remediation khác.
  • Cleanup lab đầy đủ, không để lộ secret hoặc dùng destructive command mù.
Transfer to exam / production

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

Trong CKA, `kubectl describe pod` và Events thường cho hướng đi nhanh nhất. Pending cần scheduler evidence; image pull cần image/registry/secret; crash cần `--previous` và exit code. Đừng chỉ nhìn phase hoặc restart Pod.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Pod ở CrashLoopBackOff. Evidence nào nên thu trước khi sửa image?

Kết thúc bài

Checklist trước khi sang Ngày 2