SiamCafe.net Blog
Technology

Linkerd Service Mesh Best Practices ที่ต้องรู้

linkerd service mesh best practices ทตองร
Linkerd Service Mesh Best Practices ที่ต้องรู้ | SiamCafe Blog
2025-07-13· อ. บอม — SiamCafe.net· 11,088 คำ

Linkerd คืออะไร

Linkerd เป็น Lightweight Service Mesh สำหรับ Kubernetes ที่พัฒนาโดย Buoyant เป็น CNCF Graduated Project เช่นเดียวกับ Kubernetes และ Prometheus จุดเด่นคือความเรียบง่าย ประสิทธิภาพสูง และ Setup ง่าย ใช้ Rust-based Proxy (linkerd2-proxy) ที่เบาและเร็วกว่า Envoy Proxy ที่ Istio ใช้

Linkerd ให้ Feature หลักที่ Service Mesh ต้องมี ได้แก่ Automatic mTLS สำหรับเข้ารหัส Traffic ทั้งหมด, Golden Metrics (Success Rate, Latency, Throughput) สำหรับทุก Service, Traffic Split สำหรับ Canary Deployment, Retry และ Timeout Policy และ Multi-cluster Communication

การติดตั้ง Linkerd

# ติดตั้ง Linkerd CLI
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
export PATH=$HOME/.linkerd2/bin:$PATH

# ตรวจสอบ Prerequisites
linkerd check --pre

# ติดตั้ง Linkerd CRDs
linkerd install --crds | kubectl apply -f -

# ติดตั้ง Linkerd Control Plane
linkerd install \
  --set proxyInit.runAsRoot=false \
  --set identity.externalCA=false \
  | kubectl apply -f -

# ตรวจสอบการติดตั้ง
linkerd check
# Status check results are √

# ติดตั้ง Viz Extension (Dashboard + Metrics)
linkerd viz install | kubectl apply -f -
linkerd viz check

# เปิด Dashboard
linkerd viz dashboard &

# ติดตั้งด้วย Helm (แนะนำสำหรับ Production)
helm repo add linkerd https://helm.linkerd.io/stable
helm repo update

# ติดตั้ง CRDs
helm install linkerd-crds linkerd/linkerd-crds -n linkerd --create-namespace

# สร้าง Trust Anchor Certificate สำหรับ mTLS
step certificate create root.linkerd.cluster.local ca.crt ca.key \
  --profile root-ca --no-password --insecure
step certificate create identity.linkerd.cluster.local issuer.crt issuer.key \
  --profile intermediate-ca --not-after 8760h --no-password --insecure \
  --ca ca.crt --ca-key ca.key

# ติดตั้ง Control Plane ด้วย Helm
helm install linkerd-control-plane linkerd/linkerd-control-plane \
  -n linkerd \
  --set identityTrustAnchorsPEM="$(cat ca.crt)" \
  --set identity.issuer.tls.crtPEM="$(cat issuer.crt)" \
  --set identity.issuer.tls.keyPEM="$(cat issuer.key)" \
  --set proxy.resources.cpu.request=100m \
  --set proxy.resources.memory.request=64Mi \
  --set proxy.resources.memory.limit=256Mi

# ติดตั้ง Viz
helm install linkerd-viz linkerd/linkerd-viz -n linkerd-viz --create-namespace

Mesh Application — Inject Sidecar Proxy

# วิธีที่ 1: Annotate Namespace (แนะนำ)
kubectl annotate namespace default linkerd.io/inject=enabled

# ทุก Pod ใน Namespace นี้จะได้ Linkerd Proxy อัตโนมัติ
kubectl rollout restart deployment -n default

# วิธีที่ 2: Annotate เฉพาะ Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  annotations:
    linkerd.io/inject: enabled
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      annotations:
        linkerd.io/inject: enabled
        config.linkerd.io/proxy-cpu-request: "100m"
        config.linkerd.io/proxy-memory-request: "64Mi"
        config.linkerd.io/proxy-memory-limit: "256Mi"
        config.linkerd.io/proxy-log-level: "warn"
    spec:
      containers:
        - name: web
          image: nginx:alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 200m
              memory: 128Mi

---
# ตรวจสอบว่า Proxy Inject แล้ว
kubectl get pods -o jsonpath='{.items[*].spec.containers[*].name}' | tr ' ' '\n' | sort | uniq -c
#   3 linkerd-proxy
#   3 web

# ตรวจสอบ mTLS Status
linkerd viz edges deployment -n default
# SRC          DST          SRC_NS    DST_NS    SECURED
# web-app      api-server   default   default   √
# api-server   database     default   default   √

# ตรวจสอบ Golden Metrics
linkerd viz stat deployment -n default
# NAME         MESHED   SUCCESS   RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
# web-app      3/3      100.00%   45    2ms           5ms           10ms
# api-server   2/2      99.85%    120   3ms           8ms           15ms

Traffic Management — Canary Deployment

# Traffic Split สำหรับ Canary Deployment
# ต้องติดตั้ง SMI Extension: linkerd smi install | kubectl apply -f -

# สร้าง Service สำหรับ Canary
apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web-app
  ports:
    - port: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-canary
spec:
  selector:
    app: web-app
    version: canary
  ports:
    - port: 80

---
# TrafficSplit — ส่ง 90% ไป Stable, 10% ไป Canary
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: web-app-split
spec:
  service: web-app
  backends:
    - service: web-app
      weight: 900    # 90%
    - service: web-app-canary
      weight: 100    # 10%

---
# ค่อยๆเพิ่ม Traffic ไป Canary
# 70/30
kubectl patch trafficsplit web-app-split --type=merge -p '
spec:
  backends:
    - service: web-app
      weight: 700
    - service: web-app-canary
      weight: 300
'

# 50/50
kubectl patch trafficsplit web-app-split --type=merge -p '
spec:
  backends:
    - service: web-app
      weight: 500
    - service: web-app-canary
      weight: 500
'

# 100% Canary (Promote)
kubectl patch trafficsplit web-app-split --type=merge -p '
spec:
  backends:
    - service: web-app
      weight: 0
    - service: web-app-canary
      weight: 1000
'

# ตรวจสอบ Traffic Split
linkerd viz stat trafficsplit -n default

Retry และ Timeout Policy

# ServiceProfile — กำหนด Retry, Timeout และ Route Metrics
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: api-server.default.svc.cluster.local
  namespace: default
spec:
  routes:
    - name: GET /api/users
      condition:
        method: GET
        pathRegex: /api/users
      responseClasses:
        - condition:
            status:
              min: 500
              max: 599
          isFailure: true
      isRetryable: true          # เปิด Retry สำหรับ Route นี้
      timeout: 3s                # Timeout 3 วินาที

    - name: POST /api/orders
      condition:
        method: POST
        pathRegex: /api/orders
      isRetryable: false         # ห้าม Retry สำหรับ POST (ไม่ Idempotent)
      timeout: 10s

    - name: GET /api/health
      condition:
        method: GET
        pathRegex: /api/health
      timeout: 1s

---
# HTTPRoute (Gateway API) — วิธีใหม่สำหรับ Linkerd 2.14+
apiVersion: policy.linkerd.io/v1beta3
kind: HTTPRoute
metadata:
  name: api-routes
  namespace: default
spec:
  parentRefs:
    - name: api-server
      kind: Service
      group: core
      port: 80
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/users
          method: GET
      timeouts:
        request: 3s
        backendRequest: 2s
    - matches:
        - path:
            type: PathPrefix
            value: /api/orders
          method: POST
      timeouts:
        request: 10s

---
# Retry Budget — จำกัดจำนวน Retry ทั้งหมด
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: api-server.default.svc.cluster.local
spec:
  retryBudget:
    retryRatio: 0.2       # Retry ไม่เกิน 20% ของ Total Requests
    minRetriesPerSecond: 10  # อย่างน้อย 10 retries/sec
    ttl: 10s

Observability Best Practices

Linkerd คืออะไรและต่างจาก Istio อย่างไร

Linkerd เป็น Lightweight Service Mesh สำหรับ Kubernetes เป็น CNCF Graduated Project ใช้ Rust Proxy ที่เบากว่า Envoy ต่างจาก Istio ที่มี Feature มากกว่าแต่ซับซ้อนกว่า Linkerd เน้นความเรียบง่าย Setup ง่าย ใช้ Memory น้อยกว่า และเพิ่ม Latency น้อยกว่า

Linkerd ทำ mTLS อัตโนมัติจริงหรือ

จริง Linkerd เปิด mTLS อัตโนมัติสำหรับทุก Meshed Pod โดยไม่ต้อง Config เพิ่ม ทุก Traffic ระหว่าง Pod ที่มี Linkerd Proxy จะถูกเข้ารหัสด้วย TLS พร้อม Certificate Rotation ทุก 24 ชั่วโมง ตรวจสอบได้ด้วย linkerd viz edges

Linkerd เพิ่ม Latency มากแค่ไหน

Linkerd เพิ่ม Latency ประมาณ 1-2 ms ต่อ Request (P99) น้อยมากเมื่อเทียบกับ Istio ที่เพิ่ม 3-7 ms เพราะ Linkerd ใช้ Rust Proxy ที่มีประสิทธิภาพสูง Memory Overhead ประมาณ 20-30 MB ต่อ Pod ซึ่งน้อยกว่า Envoy Sidecar

ควรใช้ Linkerd เมื่อไร

ใช้เมื่อต้องการ mTLS อัตโนมัติ, Observability (Golden Metrics), Traffic Split สำหรับ Canary และ Retry/Timeout Policy บน Kubernetes โดยไม่ต้องการความซับซ้อนของ Istio เหมาะกับทีมขนาดเล็กถึงกลางที่ต้องการ Service Mesh ที่ Setup ง่ายและ Maintain ง่าย

สรุปและแนวทางปฏิบัติ

Linkerd เป็น Service Mesh ที่เหมาะสำหรับทีมที่ต้องการ mTLS, Observability และ Traffic Management บน Kubernetes โดยไม่ต้องการความซับซ้อนของ Istio Best Practices คือติดตั้งด้วย Helm สำหรับ Production ใช้ Trust Anchor Certificate ที่สร้างเอง, Annotate Namespace แทน Deployment เพื่อ Mesh ทั้ง Namespace, ใช้ ServiceProfile กำหนด Route-level Metrics และ Retry Policy, ใช้ TrafficSplit สำหรับ Canary Deployment และ Monitor Golden Metrics อย่างสม่ำเสมอผ่าน Linkerd Dashboard หรือ Grafana

📖 บทความที่เกี่ยวข้อง

Linkerd Service Mesh Production Setup Guideอ่านบทความ → gRPC Protobuf Best Practices ที่ต้องรู้อ่านบทความ → LlamaIndex RAG Best Practices ที่ต้องรู้อ่านบทความ → Python FastAPI Best Practices ที่ต้องรู้อ่านบทความ → Weights Biases Best Practices ที่ต้องรู้อ่านบทความ →

📚 ดูบทความทั้งหมด →