Service Mesh คืออะไร? เปรียบเทียบ Istio vs Linkerd สำหรับ Kubernetes 2026

เมื่อ Microservices ใน Kubernetes มีจำนวนมากขึ้น การจัดการ Communication ระหว่าง Services กลายเป็นปัญหาซับซ้อน: Observability, Security (mTLS), Traffic Management, Retry/Timeout/Circuit Breaker ทั้งหมดนี้ Service Mesh ช่วยจัดการให้โดยไม่ต้องแก้ Code ใน App

ทำไมต้อง Service Mesh?

Sidecar Proxy Pattern

Service Mesh ใช้ Sidecar Proxy Pattern: ทุก Pod จะมี Proxy Container เพิ่มเข้ามาอัตโนมัติ (Inject) ทุก Network Traffic จะผ่าน Proxy นี้ก่อน

# ก่อน Service Mesh:
# App A ---HTTP---> App B

# หลัง Service Mesh:
# App A --> Sidecar Proxy A ---mTLS---> Sidecar Proxy B --> App B
#
# Sidecar Proxy ทำหน้าที่:
# 1. Encrypt/Decrypt Traffic (mTLS)
# 2. Collect Metrics (Latency, Error Rate, RPS)
# 3. Retry Failed Requests
# 4. Circuit Breaker
# 5. Load Balancing
# 6. Traffic Routing (Canary, A/B)
# 7. Access Control (Authorization Policy)
#
# App ไม่ต้องรู้อะไรเลย! ทำงานปกติ
# Proxy จัดการทุกอย่างให้

Istio

Istio เป็น Service Mesh ที่นิยมที่สุด สร้างโดย Google, IBM, Lyft ใช้ Envoy Proxy เป็น Data Plane

Istio Architecture

# Istio Components:
#
# Control Plane (istiod):
# - Pilot: Traffic Management, Service Discovery
# - Citadel: Certificate Management (mTLS)
# - Galley: Configuration Management
# (ปี 2026 รวมเป็น istiod ตัวเดียว)
#
# Data Plane:
# - Envoy Proxy (Sidecar ในทุก Pod)
#
# ติดตั้ง Istio:
istioctl install --set profile=default
kubectl label namespace production istio-injection=enabled
# → ทุก Pod ใน namespace production จะมี Envoy Sidecar อัตโนมัติ

Istio Traffic Management

# VirtualService — กำหนดเส้นทาง Traffic:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app
  http:
  - route:
    - destination:
        host: my-app
        subset: v1
      weight: 90          # 90% ไป v1
    - destination:
        host: my-app
        subset: v2
      weight: 10          # 10% ไป v2 (Canary)

# DestinationRule — กำหนด Subsets + Load Balancing:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s     # Circuit Breaker
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Istio mTLS + Authorization

# Auto mTLS (Default ใน Istio):
# ทุก Service-to-Service Communication เข้ารหัสอัตโนมัติ
# ไม่ต้อง Config อะไร!

# PeerAuthentication — บังคับ mTLS:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT          # บังคับ mTLS ทุก Connection

# AuthorizationPolicy — Access Control:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend-api
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]

Istio Fault Injection

# ทดสอบ Resilience ด้วย Fault Injection:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app
  http:
  - fault:
      delay:
        percentage:
          value: 10           # 10% ของ Requests
        fixedDelay: 5s        # Delay 5 วินาที
      abort:
        percentage:
          value: 5            # 5% ของ Requests
        httpStatus: 500       # Return 500 Error
    route:
    - destination:
        host: my-app

Linkerd

Linkerd เป็น Service Mesh ที่เน้น ความเรียบง่ายและ Performance ใช้ Proxy ที่เขียนด้วย Rust (linkerd2-proxy) เบากว่า Envoy มาก

Linkerd vs Istio

# ติดตั้ง Linkerd:
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check

# Inject Sidecar:
kubectl get deploy -n production -o yaml | linkerd inject - | kubectl apply -f -
# หรือ
kubectl annotate namespace production linkerd.io/inject=enabled

# Linkerd Dashboard:
linkerd viz install | kubectl apply -f -
linkerd viz dashboard

Ambient Mesh — Istio ไม่มี Sidecar

Istio Ambient Mesh คือ Mode ใหม่ที่ ไม่ใช้ Sidecar Proxy แต่ใช้ Node-level Proxy (ztunnel) แทน ลด Resource Overhead มาก

# Ambient Mesh Architecture:
# แทนที่ Sidecar per Pod → ztunnel per Node
#
# ข้อดี:
# - ไม่ต้อง Inject Sidecar
# - Resource Usage ลดลงมาก
# - ไม่ต้อง Restart Pod เมื่อ Upgrade Mesh
# - Compatible กับ Workload ที่ Sidecar ใส่ไม่ได้
#
# ข้อเสีย:
# - ยังเป็น Beta (ปี 2026 เริ่ม Stable)
# - L7 Features ต้องใช้ Waypoint Proxy เพิ่ม

# ติดตั้ง Ambient Mode:
istioctl install --set profile=ambient
kubectl label namespace production istio.io/dataplane-mode=ambient

Cilium Service Mesh (eBPF)

Cilium ใช้ eBPF (extended Berkeley Packet Filter) ทำ Service Mesh ที่ Kernel Level ไม่ต้องใช้ Sidecar หรือ User-space Proxy เลย

# Cilium Architecture:
# eBPF Programs ทำงานใน Linux Kernel
# → Network Policy, mTLS, Load Balancing ทั้งหมดอยู่ใน Kernel
# → Performance ดีที่สุด (ไม่มี Proxy Overhead)
#
# ข้อดี:
# - Performance สูงสุด (Kernel-level)
# - ไม่มี Sidecar
# - Networking + Security + Observability ในตัวเดียว
#
# ข้อเสีย:
# - ต้องใช้ Linux Kernel 5.4+
# - L7 Features จำกัดกว่า Istio
# - Learning Curve สำหรับ eBPF

เมื่อไรต้องใช้ Service Mesh?

Service Mesh Overhead

# Resource Overhead ต่อ Pod:
#
# Istio (Envoy Sidecar):
# CPU: 100-500m
# Memory: 40-100MB
# Latency: 1-3ms per hop
#
# Linkerd (linkerd2-proxy):
# CPU: 10-100m
# Memory: 10-20MB
# Latency: 0.5-1ms per hop
#
# Istio Ambient (ztunnel):
# CPU: Shared per Node
# Memory: 20-50MB per Node
# Latency: 0.5-2ms per hop
#
# Cilium (eBPF):
# CPU: Minimal (Kernel-level)
# Memory: Minimal
# Latency: < 0.5ms per hop
#
# ตัวอย่าง: 100 Pods
# Istio: +5-50 CPU cores, +4-10GB Memory
# Linkerd: +1-10 CPU cores, +1-2GB Memory
# Ambient: +1-5 CPU cores per Node
# → ต้องคิด Cost เพิ่มด้วย!

แนะนำ: เริ่มต้นยังไง?

สรุป

Service Mesh เป็นเครื่องมือสำคัญสำหรับ Kubernetes ที่มี Microservices จำนวนมาก ช่วยจัดการ Observability, Security, Traffic Management โดยไม่ต้องแก้ Code ใน App เลือกระหว่าง Istio (ฟีเจอร์ครบ), Linkerd (เรียบง่าย ประหยัด), หรือ Cilium (Performance สูงสุด) ตามความต้องการของทีมและโปรเจกต์ของคุณ