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
- Golden Metrics: ติดตาม Success Rate, Request Rate (RPS), Latency (P50/P95/P99) สำหรับทุก Service ด้วย
linkerd viz stat - Service Topology: ใช้ Linkerd Dashboard ดู Service-to-Service Communication ว่าใครคุยกับใคร
- Live Traffic: ใช้
linkerd viz tapดู Request/Response แบบ Real-time สำหรับ Debugging - Prometheus Integration: Export Metrics ไป Prometheus/Grafana สำหรับ Long-term Storage และ Custom Dashboard
- mTLS Verification: ใช้
linkerd viz edgesตรวจสอบว่า Traffic ระหว่าง Pod ถูกเข้ารหัสทั้งหมด - Per-route Metrics: ใช้ ServiceProfile กำหนด Route Patterns เพื่อดู Metrics แยกตาม Endpoint
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
