簡介
As the number of microservices increases, managing service-to-service communication becomes complex: mTLS, retry, circuit breaker, tracing, traffic splitting... Service Meshcation solves by taking all the networking app
1. 服務網格架構
1.1 概念
Service Mesh is a dedicated infrastructure layer that handles service-to-service communication through a network proxy (sidecar) injected into each pod:
Không có Service Mesh:
┌──────────┐ ┌──────────┐
│ Service A│ │ Service B│
│ │ │ │
│ ┌──────┐ │ HTTP/gRPC │ ┌──────┐ │
│ │ App │─┼───────────────────┼▶│ App │ │
│ │ Code │ │ │ │ Code │ │
│ │ │ │ Circuit breaker, │ │ │ │
│ │ +retry│ │ mTLS, tracing... │ │ │ │
│ │ +auth │ │ ← TRONG app code │ │ │ │
│ └──────┘ │ │ └──────┘ │
└──────────┘ └──────────┘
Có Service Mesh:
┌──────────────┐ ┌──────────────┐
│ Pod A │ │ Pod B │
│ │ │ │
│ ┌──────────┐ │ │ ┌──────────┐ │
│ │ App Code │ │ │ │ App Code │ │
│ │ (simple) │ │ │ │ (simple) │ │
│ └────┬─────┘ │ │ └────▲─────┘ │
│ │ │ │ │ │
│ ┌────▼─────┐ │ mTLS, retry │ ┌────┴─────┐ │
│ │ Sidecar │─┼───circuit brk──┼▶│ Sidecar │ │
│ │ Proxy │ │ tracing │ │ Proxy │ │
│ │ (Envoy) │ │ │ │ (Envoy) │ │
│ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘
1.2 資料平面與控制平面
┌─────────────────────────────────────────────────┐
│ Control Plane │
│ (Istiod / Linkerd Control Plane) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Config │ │ Cert │ │ Service │ │
│ │ Mgmt │ │ Authority│ │ Discovery │ │
│ │ │ │ (CA) │ │ │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ │ │
│ xDS API (push config) │
└──────────────────────┼───────────────────────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌───────▼──────┐┌──────▼──────┐┌──────▼──────┐
│ Envoy/Linkerd││ Envoy/Linkerd││ Envoy/Linkerd│ ← Data Plane
│ Proxy ││ Proxy ││ Proxy │
│┌────────────┐││┌────────────┐││┌────────────┐│
││ Service A ││││ Service B ││││ Service C ││
│└────────────┘││└────────────┘││└────────────┘│
└──────────────┘└──────────────┘└──────────────┘
資料平面：Sidecar 代理程式處理實際流量（路由、mTLS、指標） 控制平面：設定與管理資料平面代理程式（推送策略、憑證）
2.Istio
2.1 架構
┌─────────────────────────────────────────┐
│ Istiod (Control Plane) │
│ │
│ ┌─────────┐ ┌────────┐ ┌───────────┐ │
│ │ Pilot │ │Citadel │ │ Galley │ │
│ │ │ │ │ │ │ │
│ │ Service │ │ Cert │ │ Config │ │
│ │ Disc. │ │ Mgmt │ │ Validate │ │
│ │ Config │ │ mTLS │ │ Transform│ │
│ │ Push │ │ SPIFFE │ │ │ │
│ └─────────┘ └────────┘ └───────────┘ │
└────────────────────┬────────────────────┘
│ xDS/gRPC
┌──────────────┼──────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Envoy │ │ Envoy │ │ Envoy │
│ Sidecar │ │ Sidecar │ │ Sidecar │
└─────────┘ └─────────┘ └─────────┘
2.2 安裝
# Install Istio CLI
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
# Install Istio on cluster (demo profile for learning)
istioctl install --set profile=demo -y
# Production profile
istioctl install --set profile=default \
--set meshConfig.enableTracing=true \
--set meshConfig.defaultConfig.tracing.zipkin.address=jaeger:9411
# Enable sidecar injection for namespace
kubectl label namespace default istio-injection=enabled
# Verify
kubectl get pods -n istio-system
2.3 流量管理
VirtualService — 請求路由：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
# Canary: 90% v1, 10% v2
- route:
- destination:
host: order-service
subset: v1
weight: 90
- destination:
host: order-service
subset: v2
weight: 10
timeout: 5s
retries:
attempts: 3
perTryTimeout: 2s
retryOn: 5xx,reset,connect-failure
DestinationRule — 負載平衡與斷路器：
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order-service
spec:
host: order-service
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
http:
h2UpgradePolicy: DEFAULT
http1MaxPendingRequests: 100
http2MaxRequests: 1000
outlierDetection:
consecutive5xxErrors: 5
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
loadBalancer:
simple: LEAST_REQUEST
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
基于标头的路由（A/B 测试）：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
# Beta users → v2
- match:
- headers:
x-user-group:
exact: beta
route:
- destination:
host: order-service
subset: v2
# All others → v1
- route:
- destination:
host: order-service
subset: v1
2.4 故障注入（混沌測試）
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: payment-service
spec:
hosts:
- payment-service
http:
- fault:
# 10% requests bị delay 5s
delay:
percentage:
value: 10
fixedDelay: 5s
# 5% requests bị abort với 503
abort:
percentage:
value: 5
httpStatus: 503
route:
- destination:
host: payment-service
3.Linkerd
3.1 Architecture
Linkerd 使用 linkerd2-proxy （以 Rust 編寫）而不是 Envoy：
┌─────────────────────────────────┐
│ Linkerd Control Plane │
│ │
│ ┌────────────┐ ┌───────────┐ │
│ │ Destination│ │ Identity │ │
│ │ (discovery │ │ (mTLS │ │
│ │ + config) │ │ certs) │ │
│ └────────────┘ └───────────┘ │
│ ┌────────────┐ │
│ │ Proxy │ │
│ │ Injector │ │
│ └────────────┘ │
└─────────────────────────────────┘
│
┌──────┼──────┐
▼ ▼ ▼
┌──────┐┌──────┐┌──────┐
│linkerd││linkerd││linkerd│ ← linkerd2-proxy (Rust)
│proxy ││proxy ││proxy │
└──────┘└──────┘└──────┘
3.2 安裝與使用
# Install CLI
curl -sL https://run.linkerd.io/install | sh
export PATH=$HOME/.linkerd2/bin:$PATH
# Check cluster readiness
linkerd check --pre
# Install control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
# Verify
linkerd check
# Inject sidecar into existing deployment
kubectl get deploy order-service -o yaml \
| linkerd inject - \
| kubectl apply -f -
# Or annotate namespace for auto-injection
kubectl annotate namespace default linkerd.io/inject=enabled
# Linkerd dashboard
linkerd viz install | kubectl apply -f -
linkerd viz dashboard
3.3 流量分割（SMI）
# Service Mesh Interface (SMI) — standard API
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
name: order-service-split
spec:
service: order-service
backends:
- service: order-service-v1
weight: 900 # 90%
- service: order-service-v2
weight: 100 # 10%
4. Istio vs Linkerd
| 标准 | Istio | Linkerd |
|---|---|---|
| 代理人 | 特使 (C++) | linkerd2-代理程式 (Rust) |
| 資源使用 | High (~100MB/sidecar) | Low (~20MB/sidecar) |
| 延遲開銷 | ~3-5ms p99 | ~1-2ms p99 |
| 功能集 | 很豐富 | Core features, simple |
| Learning curve | 文檔 | 平均 |
| 交通管理 | 非常強大（VirtualService） | 基本（SMI TrafficSplit） |
| Multi-cluster | 好 | 好 |
| 社群 | Big (Google, IBM) | 好（有活力，CNCF 畢業） |
| 推薦 | 複雜用例，企業 | 簡單，效能敏感 |
When to choose what?
Cần traffic management phức tạp (A/B, canary, fault injection)?
→ Istio
Cần performance tối đa, resource constrained?
→ Linkerd
Team nhỏ, muốn adopt nhanh?
→ Linkerd
Enterprise, nhiều cluster, complex policies?
→ Istio
Chưa chắc cần service mesh?
→ Bắt đầu KHÔNG có mesh
→ Khi pain points rõ ràng → evaluate
5. 服務網格的可觀察性
服務網格自動提供黃金訊號，無需更改應用程式代碼：
Automatic Metrics (mỗi request):
├── Request rate (requests/sec)
├── Success rate (% non-5xx)
├── Latency distribution (p50, p95, p99)
├── Bytes in/out
└── Active connections
Automatic Distributed Tracing:
├── Span creation cho mỗi hop
├── Context propagation (B3/W3C headers)
├── Service dependency graph
└── Request flow visualization
Automatic mTLS Metrics:
├── Certificate expiry
├── Handshake success/failure
└── Protocol versions
# Linkerd: xem metrics real-time
linkerd viz stat deploy
linkerd viz top deploy/order-service
linkerd viz routes deploy/order-service
# Istio: Kiali dashboard
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml
istioctl dashboard kiali
總結
- Service Mesh 將網路邏輯與應用程式程式碼分離到 sidecar 代理程式中
- 資料平面（代理程式）處理流量； 控制平面 管理配置
- Istio：功能豐富，基於Envoy，適合企業複雜用例
- Linkerd：輕量級、基於 Rust、高效能、易於採用
- Service Mesh 自動提供 mTLS、可觀察性、流量管理
- 服務網格並不總是需要的—根據複雜性進行評估