Service Mesh: Istio, Linkerd

1）什麼是Service Mesh以及何時需要

Service Mesh是網絡數據/控制平面的一層，可在服務之間提供端到端mTLS，路由，容錯和可觀察性，而無需重寫代碼。

目標是：

默認安全性（零信任、服務標識、訪問策略）。
交通管理（金絲雀/藍綠色，A/B，影子）。
可靠性（retrai，taymout，電路突破）。
可觀察性（度量，logi，traces）。
操作標準化（策略為代碼，GitOps）。

何時采取mesh：

許多具有多語言性和mTLS需求的微服務。
需要高級路由/實驗腳本而無需更改應用程序。
網絡級別有審計/策略要求。

2）Istio vs Linkerd-簡短比較

一個方面	Istio	Linkerd
代理人	Envoy (L7)	rust-proxy (L7 для http/grpc) + minimalist
安裝	IstioOperator/helm	`linkerd install`/helm
安全性	mTLS, AuthorizationPolicy, PeerAuthentication, WASM-фильтры	mTLS默認,簡單策略（「policy」,「server」和「serverauthorization」）
交通-管理	VirtualService, DestinationRule, Gateway, EnvoyFilter	ServiceProfile, TrafficSplit (SMI), retries/timeouts
可觀察性	Prometheus, Telemetry API, Envoy access logs, OpenTelemetry	「linkerd viz」（tap/edges/routes）, Prometheus, OTEL集成
多重集群	Native multi-cluster, east-west gateway	`linkerd multicluster` (gateways + service mirror)
部署模型	Sidecar и Ambient Mesh (ztunnel + waypoint)	Sidecar
復雜性	功能豐富，更復雜	更簡單、更簡約、更少overhead
可擴展性	WASM/EnvoyFilter,外部授權程序	更有限，但更可預測

3）部署架構和模式

3.1 Sidecar mesh（經典）

每個Pod都獲得代理副駕駛。
優點：成熟度,完整L7控制。
缺點：CPU/RAM開銷,解密/調試復雜化。

3.2 Istio Ambient Mesh

根據需要,在節點+waypoint proxies （L7）上使用ztunnel （L4）。
優點：成本和復雜性較低,逐漸包括L7。
缺點：更新，並非所有L7案例都可以在沒有waypoint的情況下獲得。

4）身份和mTLS（零信任）

4.1 SPIFFE/SPIRE和認證

每個workload都分配了SPIFFE ID： 'spiffe： //cluster。local/ns/NS/sa/SA`.

身份驗證：服務之間的互惠TLS。
鍵輪換是自動的（短TTL）。

4.2 Istio (PeerAuthentication + DestinationRule)

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4.3 Linkerd-默認的mTLS

在「linkerd install」+「linkerd inject」之後啟用。
集群是自己的信任錨點，輪換是自動的。

5）交通-管理

5.1 Istio： VirtualService（路線,金絲雀）

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

DestinationRule (LB/CB):

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5.2 Linkerd: ServiceProfile + TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6） Ingress/Egress和API網關

Istio Gateway （ingress/egress）-管理傳入/傳出流量,TLS終端,mTLS passthrough。
Linkerd與現有的ingress控制器（NGINX/Contour/Traefik）一起工作；egress-通過NetworkPolicy/egress-gateway模式。
Egress政策：白色域名列表，SNI政策，禁止直接互聯網。

7）授權和政策

7.1 Istio AuthorizationPolicy (RBAC/ABAC)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7.2 Linkerd policy (server + serverauthorization)

yaml apiVersion: policy. linkerd. io/v1beta3 kind: Server metadata: { name: payments-server, namespace: payments }
spec:
podSelector: { matchLabels: { app: payments } }
port: 8080 apiVersion: policy. linkerd. io/v1beta3 kind: ServerAuthorization metadata: { name: allow-gateway, namespace: payments }
spec:
server: { name: payments-server }
client:
meshTLS:
identities: [".ns. api. serviceaccount. identity. linkerd. cluster. local"]

8）可觀測性和遙測

8.1個指標

Istio Telemetry API → Prometheus: `istio_requests_total`, `istio_request_duration_milliseconds_bucket`, `istio_tcp_received_bytes_total`.

Linkerd viz: `request_total`, latency p50/p95/p99, `success_rate`.

8.2 Traces and Logies

打孔W3C Trace Context。
Istio/Envoy → OTLP в OpenTelemetry Collector;Linkerd-通過sidecar-logger/app-SDK。

8.3個實例（Exemplars）

將「trace_id」添加到「jump-to-trace」的持續時間直方圖中。

9） Rate limits, WAF,定制過濾器

Istio：EnvoyFilter/WASM用於本地利率限制，eksternal-rate-limit服務（Redis）以及WAF邏輯（Lua/WASM）。
Linkerd：有限的本地支持；rate limit-在ingress/網關級別。

10）多元化

Istio： east-west gateway,通用PKI或trust-bundle,服務發現通過ServiceEntry, Federation。

Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

使用案例：資產區域，流量本地化，零信任聯邦化。

11）性能和成本

Sidecar mesh：每個Pod的CPU/RAM overhead，潛伏期增加（通常在steady-state的hop上+1-3 ms）。
環境（Istio）： L4、L7的消費量較少。
Linkerd：輕量級代理通常較少,但極端L7功能較少。
練習：測量p95/CPU前/之後，保持SLO門降級。

12）安全性

mTLS無處不在，TTL短，自動旋轉。
政策作為代碼（OPA/Gatekeeper，Kyverno）禁止使用「授權政策：ALLOW all」。
秘密-通過CSI/Vault，不在清單中。
Egress控制：deny-by-default，顯式allow lists。
環境的單獨信任域（prod/stage）。

13）與發行版和SLO遊戲集成

Canary/Blue-Green由mesh路線實現（請參見示例）。
Argo Rollouts AnalysisTemplate中的度量分析（Prometheus/SpanMetrics）是burn-rate/p95/5xx的搭檔/回滾。
Grafana中的版本註釋：「版本=stable'canary」的比較。

14）反模式

啟用mesh「無處不在」→基礎架構沖擊。
忽略TSDB/Loghcall過載→代理的基數/邏輯。
將mTLS留在PERMISSIVE/opaque模式中。
嘗試在EnvoyFilter而不是網關/應用程序中制造復雜的WAF/業務邏輯。
沒有egress策略-Internet泄漏/法規繞過。
代理「：15000」 debug向外打開。

15）實施清單（0-60天）

0-15天

模型選擇：Sidecar vs Ambient （Istio）/Linkerd在載荷配置文件中。
啟用mTLS STRICT, 1-2關鍵服務的基本授權策略。
基本路由（時間/路由），RED/SLO行車記錄儀。

16-30天

金絲雀/TrafficSplit，熱路上的直通車檢測/電路中斷。
OTEL集成：traces+Exemplars；burn-rate的變種。

Egress-gateways和白域列表；deny-by-default.

31-60天

多單元鏈接（如果需要的話）,federation trust.

Policy as Code на AuthorizationPolicy/ServerAuthorization.

遊戲日：模擬事件和回滾路線/策略。

16）成熟度量

mTLS覆蓋範圍（STRICT/auto-rotate）≥ 95％的服務。
通過金絲雀/漸進發行版的流量份額≥ 80％。
平均超頭p95比基線<+5％（優化後）。
0未經許可的開放式表格，100％的基本AuthZ服務。
RCA「從圖形到軌道」≤ 2分鐘（p50）。

17）「策略作為代碼」示例"

Gatekeeper（禁止銷售PERMISSIVE）

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

Kyverno（VS/DR的強制性標簽）

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18）操作提示

通過GitOps進行促銷活動，以驗證政策和路線（semver）。
代理可觀察性：單獨的「proxy saturation」行列板（CPU/heap，retries，429/503）。
基數預算：標記「route」，「code」，「destination」僅為模板。
Namespace級別的網絡限制/配額（NetworkPolicy/LimitRange）。
命令文檔：runbook 「如何回滾路線/策略/mTLS密鑰」。

19）結論

Istio和Linkerd解決了一個問題-標準化服務間通信的安全性，可靠性和可見性-但這樣做具有不同的深度和擁有成本。

需要豐富的L7功能和靈活的策略-采取Istio（考慮環境以減少開銷）。
需要簡單和輕微的超頭-采取Linkerd。

無論您選擇哪種方式：啟用默認的mTLS，將路由作為代碼進行管理，將度量標準鏈接到預告片，關閉egress，並在發行版中添加SLO登錄。然後，網絡層將不再是「黑匣子」，並且將成為穩定性和變化速度的可預測工具。

Service Mesh: Istio, Linkerd

16-30天

31-60天

Kyverno（VS/DR的強制性標簽）

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案