Lesson 70 — Service Mesh

Ba module tương tác: (1) kiến trúc sidecar + control plane đẩy config, (2) canary traffic shifting, (3) bắt tay mTLS giữa hai sidecar. Mở README (nút 📖 góc phải) để đọc lý thuyết đầy đủ.

1. Kiến trúc Sidecar + Control plane

App chỉ gọi http://checkout. iptables chuyển hướng qua Envoy sidecar (data plane). Istiod (control plane) đẩy config xuống mọi Envoy — không nằm trên đường đi của request.

🧠 Control plane — Istiod
↓ đẩy config (route, mTLS, retry) — KHÔNG xử lý traffic ↓

Pod: cart

app cart
↕ localhost
Envoy sidecar
══ mTLS ══▶

Pod: checkout

Envoy sidecar
↕ localhost
app checkout
Bấm "Gửi request" để xem gói tin đi qua app → Envoy → mTLS → Envoy → app. Bấm "Istiod đẩy config" để thấy control plane cập nhật proxy mà không đụng tới traffic.

2. Canary traffic shifting

Kéo slider để đặt % traffic sang v2 (canary). Bấm "Gửi 100 request" để xem phân phối thực tế. Đây chính là sửa weight trong VirtualService — không deploy lại app.

v1 (ổn định) v2 (canary)
0
tới v1
0
tới v2
Mỗi request chọn phiên bản theo trọng số. Tỷ lệ thực tế xấp xỉ % bạn đặt (sai số do ngẫu nhiên). Quy trình canary: 10% → quan sát metric → 50% → 100%, rollback = đặt lại 0%.

3. Bắt tay mTLS giữa hai sidecar

mTLS = mutual TLS: cả client lẫn server đều trình cert và verify lẫn nhau. Bật/tắt cert của client để xem mesh chấp nhận hay từ chối (zero-trust).

🛒 Envoy cart (client)

spiffe://…/sa/cart
cert: cart-cert ✅

💳 Envoy checkout (server)

spiffe://…/sa/checkout
cert: checkout-cert ✅
Bấm "Chạy bắt tay mTLS" để xem từng bước verify hai chiều...
Khác TLS web (chỉ client verify server): ở mTLS server cũng verify client. Pod lạ không có cert do CA mesh cấp sẽ bị từ chối ngay tầng kết nối — chưa chạm logic nghiệp vụ.