Service Mesh — เครือข่ายชั้นสูงระหว่าง service
mTLS, traffic routing, observability โดยไม่แตะโค้ดแอป
พื้นฐานที่ควรรู้: เมื่อระบบเรามี Microservices จำนวนหลายสิบหรือหลายร้อยตัว การจะตามเก็บข้อมูลว่าตัวไหนคุยกับตัวไหนบ้าง หรือจะเข้ารหัสข้อมูลระหว่างกันทุกเส้นทาง จะกลายเป็นเรื่องยุ่งยากมากหากต้องให้โปรแกรมเมอร์เขียนโค้ดจัดการทีละจุด
Service mesh เหมือนติดตั้ง "ผู้ช่วยส่วนตัว" (sidecar) ข้าง service ทุกตัว ที่คอยจัดการเรื่องเครือข่ายให้ — เข้ารหัส, ลองใหม่เมื่อพลาด, บันทึกสถิติ — โดยที่ตัว service ไม่ต้องเขียนโค้ดพวกนี้เอง
พอ microservices เยอะขึ้น การจัดการเรื่อง security/reliability/observability ระหว่าง service กลายเป็นภาระ · Service mesh (เช่น Istio, Linkerd) แทรก sidecar proxy ข้างทุก Pod เพื่อคุม traffic ระหว่างกันจากส่วนกลาง
- mTLS อัตโนมัติ — เข้ารหัส traffic ระหว่าง service ทุกคู่โดยไม่แก้โค้ด
- Traffic management — canary/blue-green, แบ่ง traffic 90/10, retry, timeout, circuit breaking
- Observability — เก็บ metrics/trace ของทุก request ระหว่าง service ให้ฟรี
สรุป Key Takeaways
- Service mesh แทรก sidecar proxy คุมเครือข่ายระหว่าง service จากส่วนกลาง
- ได้ mTLS อัตโนมัติ, traffic routing (canary), observability โดยไม่แก้โค้ด
- มี overhead/ความซับซ้อน — ใส่เมื่อจำเป็นจริง (Linkerd เบากว่า Istio)
คำถามที่พบบ่อย
Service mesh ให้อะไรที่ K8s เปล่าๆ ไม่ให้
สามกลุ่ม: ความปลอดภัย (mTLS ระหว่างทุก service อัตโนมัติ), การคุม traffic (canary แบ่งเปอร์เซ็นต์, retry, timeout, circuit breaker โดยไม่แก้โค้ด), และ observability (metrics/trace ของทุกการเรียกข้าม service) — ทำงานผ่าน sidecar proxy หรือโหมด ambient ที่ไม่ต้องมี sidecar
ควรใช้ service mesh เมื่อไหร่ อย่าเพิ่งใช้เมื่อไหร่
ยังไม่ควรถ้า service ไม่กี่ตัว — mesh เพิ่ม latency, resource และความซับซ้อนอีกชั้น เริ่มคุ้มเมื่อ microservices หลายสิบตัว ต้องการ mTLS ทั่วทั้งระบบ หรือ traffic shaping ละเอียด — ก่อนถึงจุดนั้น Ingress + NetworkPolicy มักพอ