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

Ngày 5: Ambassador & Adapter pattern

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

So sánh Ambassador và Adapter pattern trong Multi-container Pod: proxy/local gateway, chuẩn hóa output, shared contract, network path và khi nào chọn từng pattern.

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

So sánh Ambassador và Adapter pattern trong Multi-container Pod: proxy/local gateway, chuẩn hóa output, shared contract, network path và khi nào chọn từng pattern.

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

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

  • Học 2 pattern còn lại trong multi-container design
  • So sánh khi nào dùng pattern nào
Instructor walkthrough

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

Scenario xuyên suốt

Người học biết tên pattern nhưng thêm sidecar proxy hoặc adapter vào mọi Pod mà không xác định boundary. Bài này đặt hai pattern vào cùng một request/data flow, chỉ ra coupling, failure mode, readiness và chi phí vận hành để chọn có lý do.

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ế
  • Ambassador đứng cạnh app để đại diện giao tiếp ra ngoài như local proxy, retry/connection policy hoặc protocol gateway; app nói với localhost nhưng dependency vẫn cần health/timeout contract.
  • Adapter biến đổi interface/output của app để phù hợp consumer như format log/metrics/protocol; nó không tự làm app reliable hay thay thế validation schema.
  • Cả hai container chia sẻ network/volume trong Pod nhưng không chia sẻ process; localhost/port, mount path, permissions và lifecycle phải khai báo rõ.
  • Sidecar failure có thể làm Pod NotReady hoặc silently drop data; readiness, liveness, backpressure, timeout và graceful shutdown cần được thiết kế.

Chọn pattern theo boundary

  • Ambassador: app gọi local proxy/gateway; sidecar đại diện cho outbound protocol, connection policy hoặc dependency access. Debug request path và timeout từ app → localhost → dependency.
  • Adapter: sidecar đọc/nhận output rồi chuyển format/interface cho consumer. Debug data path, schema, file/port và backpressure.

Không lạm dụng sidecar

Pod-level locality có giá trị khi lifecycle/scale/coupling đi cùng nhau. Nếu proxy/adapter cần scale độc lập, có security boundary khác hoặc ownership khác, Service/Deployment riêng có thể phù hợp hơn. Cả hai pattern đều cần readiness, timeout, resource limits, graceful shutdown và failure policy; không tự tạo persistence/reliability.

Bài tập

Dựng Ambassador và Adapter riêng, verify request/data path, mô phỏng timeout/port/schema/permission failure, rồi lập matrix so sánh pattern với separate Service. Chọn một phương án cho case mới và bảo vệ quyết định bằng evidence/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 pod,svc -n ckad-day5 -o wide
kubectl describe pod POD_NAME -n ckad-day5
kubectl logs POD_NAME -n ckad-day5 -c ambassador --tail=100
kubectl logs POD_NAME -n ckad-day5 -c adapter --tail=100
kubectl exec POD_NAME -n ckad-day5 -c app -- wget -qO- http://127.0.0.1:PORT/health
kubectl get events -n ckad-day5 --sort-by=.lastTimestamp
Hands-on lab

Thực hành theo scenario

  1. Tạo namespace `ckad-day5`; dựng app mock và hai biến thể: Ambassador proxy chuyển request tới dependency mock, Adapter đọc output app từ emptyDir và chuẩn hóa thành file/endpoint. Ghi owner, ports, volume contract và expected path.
  2. Chạy từng pattern riêng, kiểm tra request từ app qua localhost, dependency response, adapter output, logs từng container, readiness và restart count; không gộp hai pattern vào một manifest ngay từ đầu.
  3. Mô phỏng dependency timeout, proxy port sai, adapter schema/file permission sai và consumer đọc output chậm; thu events/logs/status rồi sửa timeout/port/mount/readiness đúng lớp.
  4. Lập decision matrix Ambassador vs Adapter vs separate Service: boundary, latency, scaling, failure isolation, security, ownership và operational cost. Tạo variant đổi protocol/output để kiểm tra pattern transfer.
  5. Cleanup Pod/Service/ConfigMap/emptyDir lab; ghi rõ pattern không cung cấp persistence, retry vô hạn hay secret safety tự động.
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:

  • Giải thích đúng Ambassador và Adapter theo data/request boundary.
  • Có manifest thực tế với container/port/volume contract và evidence.
  • Debug được proxy/adapter failure qua logs/events/readiness.
  • Decision matrix có trade-off và lựa chọn alternative.
  • Variant và cleanup/data/security caveat đầy đủ.
Transfer to exam / production

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

CKAD có thể yêu cầu sidecar với port/volume cụ thể; hãy xác định pattern từ hướng dữ liệu trước khi viết YAML. Kiểm tra localhost port, container name, mount và readiness riêng cho từng container.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Ứng dụng cần gửi request tới dependency qua local proxy để thống nhất timeout và protocol. Pattern phù hợp nhất là gì?

Kết thúc bài

Checklist trước khi sang Ngày 2