Lộ trình
Cloud Native Computing FoundationAssociateTuần 1: Nền tảngBài 3 / 30

Ngày 3: Multi-container Pod

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

Thiết kế Multi-container Pod với sidecar/adapter và shared volume: lifecycle, container contract, file permissions, logs riêng và failure isolation.

đọ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

Thiết kế Multi-container Pod với sidecar/adapter và shared volume: lifecycle, container contract, file permissions, logs riêng và failure isolation.

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

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

  • Học Sidecar pattern
  • Thực hành tạo Pod có 2 container chia sẻ volume
Instructor walkthrough

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

Scenario xuyên suốt

Hai container trong một Pod chia sẻ network và có thể chia sẻ volume nhưng không tự động có cùng lifecycle hay dữ liệu đúng. Bài học thực hành log sidecar/adapter, xác định writer-reader contract và debug khi một container healthy còn container kia crash.

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ế
  • Pod là đơn vị scheduling: các container chia sẻ network namespace và có thể chia sẻ volume, nhưng mỗi container có image/process/log/health state riêng.
  • Sidecar hỗ trợ container chính như log shipping/proxy/adapter; cần contract rõ về file path, format, readiness và khi nào sidecar được phép fail.
  • emptyDir có lifecycle theo Pod, không phải persistent storage; mount cùng volume nhưng subPath/permissions/ordering có thể làm reader không thấy dữ liệu.
  • Container status/readiness và Pod phase cần đọc riêng; một sidecar restart hoặc readiness fail có thể ảnh hưởng Pod/traffic dù app chính vẫn chạy.

Multi-container là một contract

Pod chia sẻ network và volume nhưng container vẫn có process/lifecycle/status riêng. Định nghĩa rõ: app ghi file nào/format nào, sidecar đọc khi nào/xuất gì, volume emptyDir sống bao lâu, permission/user ra sao và readiness tính thế nào.

Debug theo container

Dùng get/describe để xem Pod, status từng container, rồi logs -c/exec -c đúng target. Sai mountPath, permission hoặc sidecar command là failure riêng; đừng restart/xóa Pod trước khi giữ evidence. emptyDir mất khi Pod bị xóa/recreate, không thay thế PV/PVC.

Bài tập

Tạo app + sidecar chia sẻ emptyDir, verify file/outputs/logs, mô phỏng sai mount/permission/sidecar exit và sửa. Tạo variant readOnly hoặc đổi writer timing, rồi cleanup và ghi data-lifecycle caveat.

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-day3 -o wide
kubectl describe pod POD_NAME -n ckad-day3
kubectl logs POD_NAME -n ckad-day3 -c app --tail=100
kubectl logs POD_NAME -n ckad-day3 -c sidecar --tail=100
kubectl get pod POD_NAME -n ckad-day3 -o jsonpath="{.status.containerStatuses[*].name} {.status.containerStatuses[*].restartCount}{"\n"}"
kubectl exec POD_NAME -n ckad-day3 -c sidecar -- ls -la /shared
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `ckad-day3`; viết Pod gồm `app` tạo file log/response marker và `sidecar` đọc/transform từ emptyDir rồi expose output qua shared path. Gắn labels/owner và ghi expected state.
  2. Khai báo volume/mount rõ ở cả container, command/args, resources và security/permission assumption; dùng `kubectl logs -c CONTAINER` để tách output.
  3. Verify Pod/container statuses, shared file content, restart counts và logs; kiểm tra sidecar có đọc dữ liệu mới theo contract, không coi volume mount thành communication protocol tự động.
  4. Tạo failure variants: sai mountPath/permission, sidecar command exit, app writer chậm và volume readOnly; dùng describe/events/logs/exec trong lab để xác định container nào sai.
  5. Cleanup Pod/namespace và volume artifacts; ghi emptyDir loss khi Pod bị xóa, không dùng hostPath hay shared writable path production để che thiết kế sai.
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:

  • Container roles/contract/volume path được mô tả.
  • Cả container status, logs và shared data có evidence riêng.
  • Phân biệt Pod lifecycle với container lifecycle.
  • Có failure variant về mount/permission/process và sửa đúng lớp.
  • Cleanup chứng minh emptyDir không bị hiểu nhầm là persistent data.
Transfer to exam / production

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

CKAD multi-container task thường chấm đúng container name, volumeMount và command. Khi debug, thêm `-c`, xem từng status/log; container chính chạy không chứng minh sidecar contract hoặc Pod Ready.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Pod có app container Running nhưng sidecar CrashLoopBackOff. Cách debug đầu tiên phù hợp là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2