深色模式
服务网格概述与 Istio 架构
摘要：本文面向生产 SRE / 平台工程师，解释服务网格（Service Mesh）的本质、Istio 的控制面与数据面架构、sidecar 与 ambient 两种模式，以及 Istio 与 Linkerd 的差异。覆盖版本：Istio 1.31（截至 2026-10 最新稳定线 1.31.x；旧版如 1.2x 的差异见文中标注）。
背景与问题
在微服务架构中，服务间（east-west）通信面临三类非功能性需求：流量治理（重试、超时、灰度、熔断）、安全（加密与身份认证、授权）、可观测性（指标、链路、日志）。传统做法把这些逻辑塞进应用 SDK（如 Hystrix、各类语言客户端），导致跨语言不一致、升级成本高、业务与基础设施耦合。
服务网格的核心思想：把网络通信逻辑从应用进程里抽出来，下沉到一个与语言无关的 Sidecar 代理中，由统一的控制面下发配置。应用只管业务逻辑，网络治理对应用透明。
一句话定义
服务网格 = 一组部署在应用旁边的网络代理（数据面）+ 一个集中式的控制面，统一管理服务间通信的路由、安全与遥测。
核心概念：数据面 / 控制面二分法
服务网格普遍采用**数据面（Data Plane）+ 控制面（Control Plane）**分离架构：
- 数据面：一组网络代理（Istio 用 Envoy），以 Sidecar 或节点级代理形式存在，拦截并处理所有进出应用的流量。它处于请求热路径上，负责实际的路由、mTLS、指标采集。
- 控制面：负责服务发现、配置翻译、证书签发与分发，并通过 xDS 协议把配置推送给数据面。控制面不在请求热路径上——一旦 Envoy 收到配置，即使
istiod短暂宕机，已有连接仍可正常工作，仅新的策略变更与证书轮换会停滞。这一设计是 Istio 生产韧性的关键。
Istio 架构详解（Istio 1.31）
Istio 由 Google、IBM、Lyft 于 2017 年创立，2023-07 从 CNCF 毕业（Incubating 于 2022-09）。其控制面在 1.5（2020）合并为单一二进制 istiod，整合了原先的 Pilot（流量管理）、Citadel（证书）、Galley（校验）。
istiod 的三大职责：
- Pilot 子系统：监听 K8s Service/EndpointSlice、Istio CRD（VirtualService、DestinationRule、Gateway）与 Gateway API 资源，翻译成 Envoy 的 xDS（LDS/RDS/CDS/EDS）配置，通过 gRPC 流式推送给数据面。
- Citadel 子系统：作为 CA，为每个工作负载签发基于 SPIFFE 的短期 X.509 证书（默认 24 小时生命周期并自动轮换），身份格式为
spiffe://cluster.local/ns/<namespace>/sa/<serviceaccount>。 - Galley 功能：配置校验与准入 Webhook。
两种数据面模式
| 维度 | Sidecar 模式 | Ambient 模式（1.24 GA） |
|---|---|---|
| 代理形态 | 每 Pod 一个 Envoy 容器 | 节点级 ztunnel（Rust，L4+mTLS）+ 按需的 waypoint（Envoy，L7） |
| 资源开销 | 高（每 Pod 一个完整 Envoy） | 低（共享节点代理，仅需要时部署 L7 waypoint） |
| 接入方式 | 注入 Sidecar 需重启 Pod | 标记命名空间即可，无需重启 Pod |
| 成熟度 | 多年生产锤炼 | GA 后逐步成熟，新集群推荐 |
istio-cni节点代理负责流量重定向（iptables/nftables），ambient 模式必需，sidecar 模式下可选。
选型边界
若团队没有平台工程产能、需求 mainstream（mTLS + 重试/超时 + 基础可观测），Linkerd 通常更省心；若需要高级 L7 路由、流量镜像、细粒度零信任授权、多集群联邦、WASM 扩展，则 Istio 更合适。两者不应在同一集群混部（见下文对比）。
Istio 与 Linkerd 差异
| 维度 | Istio | Linkerd |
|---|---|---|
| CNCF 状态 | Graduated（2023-07） | Graduated |
| 数据面代理 | Envoy（C++）/ ztunnel（Rust，仅 ambient） | linkerd2-proxy（Rust 微代理） |
| 部署形态 | Sidecar 或 sidecarless ambient | Sidecar（极小的 Rust 代理） |
| mTLS | 默认 PERMISSIVE（需手动转 STRICT） | 默认开启、零配置 |
| 授权模型 | 细粒度 L7 授权（AuthorizationPolicy） | 更简单的策略模型 |
| 资源开销 | sidecar 模式较高；ambient 显著降低 | 极低（每 Pod 内存远低于 Envoy） |
| 运维复杂度 | 高（CRD 多、旋钮多） | 低（概念少、上手快） |
| 多集群 | 成熟灵活 | 支持但范围更聚焦 |
关于开销基准
第三方基准（如 2026 年部分测评）称 Istio sidecar 每 Pod 内存开销约为 Linkerd 的数倍。该数字依赖节点规格、CNI、并发与负载，本文未独立实测，请按 ::: danger 级别对待——以你自己的压测为准，切勿直接引用为承诺值。标记为 [未实测]。
迁移最佳实践与副作用
落地路径（生产推荐）
- 先开 PERMISSIVE：默认模式同时接受明文与 mTLS，便于逐步将服务纳入网格而不中断未注入 Sidecar 的服务。
- 按命名空间注入：
kubectl label namespace <ns> istio-injection=enabled，新 Pod 自动注入；存量 Pod 需滚动重启。 - 使用修订（revision）灰度升级控制面：避免
istiod一次性全量升级导致全局抖动。 - 逐步收紧到 STRICT（见 mTLS 专文）。
常见副作用（必须提前评估）
- 延迟：sidecar 模式下，每次调用多一跳代理，p99 增加通常个位数毫秒量级，但取决于请求体与配置复杂度（具体数字见各专文
[未实测]）。 - 资源：每 Pod 一个 Envoy 会显著增加内存/CPU 占用；ambient 模式通过节点级共享大幅缓解，但引入了 ztunnel/waypoint 自身的运维对象。
- 调试复杂度：Envoy 配置调试偏难，需熟悉
istioctl proxy-config与 xDS。 - 升级：控制面升级需关注 Gateway API CRD 版本、revision 兼容。
生产危险
kubectl label namespace <ns> istio-injection=enabled 仅对新 Pod 生效；已运行 Pod 不会自动注入 Sidecar，需要滚动重启（如 kubectl rollout restart deployment -n <ns>）。重启会中断存量连接，请在低峰期、配合 PDB 与优雅终止（preStop + terminationGracePeriodSeconds）执行。
可观测性与下一步
Istio 数据面天然输出指标、访问日志与链路 span，配合 Prometheus、Grafana、Jaeger/Tempo 与 Kiali（专文讲解）构建可观测性栈。建议下一步阅读本分类的流量管理、灰度/镜像、mTLS、Kiali 四篇。