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的强制性标签）

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目