Home » Service Mesh: Istio, Envoy, Linkerd, Sidecar Proxy, mTLS และ Observability
Service Mesh: Istio, Envoy, Linkerd, Sidecar Proxy, mTLS และ Observability
Service Mesh: Istio, Envoy, Linkerd, Sidecar Proxy, mTLS และ Observability
Service Mesh เป็น infrastructure layer ที่จัดการ service-to-service communication ใน microservices Istio เป็น service mesh ที่ popular ที่สุด, Envoy เป็น high-performance proxy ที่เป็นหัวใจของ Istio, Linkerd เป็น lightweight alternative ที่ง่ายกว่า, Sidecar Proxy inject ข้าง container ทุกตัวเพื่อ intercept traffic, mTLS encrypt ทุก service communication อัตโนมัติ และ Observability ให้ metrics, traces, logs สำหรับทุก request
เมื่อ application แตกเป็น หลายร้อย microservices ปัญหาด้าน networking เพิ่มขึ้นแบบ exponential: service discovery (หา service อื่นอย่างไร?), load balancing (กระจาย traffic อย่างไร?), encryption (encrypt ทุก service pair?), observability (trace request ข้าม 20 services?), retry/timeout (handle failure?) Service mesh แก้ทุกปัญหานี้ที่ infrastructure level โดย developers ไม่ต้องเขียน code
Service Mesh Architecture
| Component |
Role |
Example |
| Data Plane |
Sidecar proxies ที่ intercept ทุก request ระหว่าง services |
Envoy (Istio), linkerd2-proxy (Linkerd) |
| Control Plane |
Configure + manage data plane proxies (policies, certs, routes) |
Istiod (Istio), linkerd-destination (Linkerd) |
Istio
| Feature |
รายละเอียด |
| คืออะไร |
Most popular service mesh — Google/IBM/Lyft originated, CNCF project |
| Data Plane |
Envoy sidecar proxies (auto-injected ใน every pod) |
| Control Plane |
Istiod (single binary: Pilot + Citadel + Galley combined) |
| Traffic Management |
VirtualService, DestinationRule → canary, A/B testing, traffic shifting |
| Security |
Auto mTLS, authorization policies (who can call whom), JWT validation |
| Observability |
Metrics (Prometheus), traces (Jaeger/Zipkin), access logs → without code changes |
| Ambient Mesh |
New sidecar-less mode (ztunnel + waypoint proxy) — lower overhead |
Envoy Proxy
| Feature |
รายละเอียด |
| คืออะไร |
High-performance L4/L7 proxy — designed for cloud-native (CNCF graduated) |
| Performance |
C++ built, sub-millisecond latency, handles millions of connections |
| L7 Protocols |
HTTP/1.1, HTTP/2, gRPC, TCP, MongoDB, Redis, MySQL |
| Load Balancing |
Round robin, least request, ring hash, random, weighted |
| Observability |
Built-in stats, distributed tracing, access logging |
| xDS API |
Dynamic configuration via gRPC API (control plane pushes config) |
| Used By |
Istio, AWS App Mesh, Consul Connect, many API gateways |
Linkerd
| Feature |
Istio |
Linkerd |
| Complexity |
Complex (many features, steep learning curve) |
Simple (focused, easy to install and operate) |
| Proxy |
Envoy (C++, feature-rich, heavy) |
linkerd2-proxy (Rust, ultralight, purpose-built) |
| Resource Usage |
Higher (Envoy is heavier) |
Lower (Rust proxy is ~10MB memory) |
| mTLS |
Auto mTLS |
Auto mTLS (on by default) |
| Traffic Management |
Advanced (VirtualService, DestinationRule) |
Basic (traffic split, retries) |
| Multi-Cluster |
Yes (complex setup) |
Yes (simpler multi-cluster) |
| Best For |
Complex environments, advanced traffic control |
Teams wanting simplicity + reliability |
Sidecar Proxy Pattern
| Feature |
รายละเอียด |
| How |
Proxy container inject ข้าง application container ใน same pod |
| Intercept |
iptables rules redirect ทุก inbound/outbound traffic ผ่าน sidecar proxy |
| Transparent |
Application ไม่รู้ว่ามี proxy อยู่ (no code changes needed) |
| Overhead |
~10-20ms latency per hop, ~50-100MB memory per sidecar |
| Sidecar-less |
Istio Ambient mode, Cilium service mesh (eBPF) — reduce overhead |
mTLS in Service Mesh
| Feature |
Without Mesh |
With Service Mesh |
| Certificate Management |
Manual cert deployment per service |
Auto cert issuance + rotation (control plane manages) |
| Encryption |
Developer must implement TLS |
Auto mTLS between all services (transparent) |
| Identity |
IP-based (unreliable in Kubernetes) |
SPIFFE identity (cryptographic service identity) |
| Rotation |
Manual cert renewal |
Auto rotation (every 24h default in Istio) |
| Zero Trust |
Difficult to implement |
Built-in (every service verifies peer identity) |
Observability Features
| Pillar |
What |
Tools |
| Metrics |
Request rate, error rate, latency (RED metrics) per service |
Prometheus + Grafana (dashboards auto-generated) |
| Distributed Tracing |
Trace request path across services (end-to-end latency breakdown) |
Jaeger, Zipkin, Tempo |
| Access Logs |
Log every request (source, dest, status, latency, headers) |
Envoy access logs → ELK/Loki |
| Service Graph |
Visualize service dependencies + traffic flow |
Kiali (Istio), Linkerd Dashboard |
Traffic Management
| Feature |
Use Case |
| Canary Deployment |
Route 5% traffic ไป new version → monitor → gradually increase |
| A/B Testing |
Route traffic ตาม header (e.g., user-group: beta → v2) |
| Traffic Mirroring |
Copy production traffic ไป test environment (shadow testing) |
| Circuit Breaking |
ถ้า service fail → stop sending requests (prevent cascade failure) |
| Retry + Timeout |
Auto retry failed requests + enforce timeouts (ป้องกัน hanging) |
| Rate Limiting |
Limit requests per service/user → protect from overload |
ทิ้งท้าย: Service Mesh = Networking for Microservices
Service Mesh Architecture: data plane (sidecar proxies) + control plane (manage proxies) Istio: most popular, Envoy proxy, advanced traffic management, auto mTLS, ambient mode Envoy: C++ high-performance proxy, L4/L7, xDS API, used by Istio/AWS/Consul Linkerd: simpler alternative, Rust proxy (ultralight), easy to operate, auto mTLS mTLS: auto cert issuance + rotation, SPIFFE identity, transparent encryption Observability: metrics (Prometheus), traces (Jaeger), logs, service graph (Kiali) — zero code change Traffic: canary, A/B testing, mirroring, circuit breaking, retry/timeout, rate limiting Key: service mesh moves networking complexity from application code to infrastructure
อ่านเพิ่มเติมเกี่ยวกับ Container Networking Docker Kubernetes CNI และ API Gateway Kong Apigee ที่ siamlancard.com หรือจาก icafeforex.com และ siam2r.com
