Service Mesh 的「冰与火之歌」#

如果你在 2023 年问一个 K8s 运维：「你用 Service Mesh 吗？」

大概率得到的回答是：「试过 Istio，太复杂了，撤了。」

这不是段子。2020-2023 年间，Service Mesh 经历了从「万众期待」到「跌落神坛」的过山车。Sidecar 模式带来的资源开销、运维复杂度、故障排查难度，让很多团队选择了「裸奔」。

但到了 2026 年，剧情反转了。

根据 Cloud Native Now 的最新报道，Service Mesh 正在经历一场戏剧性的复兴，而主角就是 Istio 的 Ambient Mode。

Ambient Mode：Sidecar 的「终结者」#

什么是 Ambient Mode？简单说就是——不带 Sidecar 的 Service Mesh。

传统的 Istio 在每个 Pod 里注入一个 Envoy Sidecar 代理，所有流量强制经过它。这样做的好处是零代码改造就能实现流量管理、安全策略、可观测性，但代价也很高：

• 每个 Pod 多一个容器，资源开销放大 2-3 倍
• Envoy 启动慢，Pod 就绪延迟
• Sidecar 挂了，业务容器也跟着受影响
• 升级 Envoy 需要重启整个 Pod

Ambient Mode 彻底抛弃了这种模式，转而使用节点级别的轻量代理（ztunnel）：

1
# Ambient Mode 下，不需要 Sidecar 注入
2
apiVersion: apps/v1
3
kind: Deployment
4
metadata:
5
  name: my-app
6
  labels:
7
    app: my-app
8
    # 只需给命名空间打上标签
9
    istio.io/dataplane-mode: ambient
10
spec:
11
  replicas: 3
12
  selector:
13
    matchLabels:
14
      app: my-app
15
  template:
16
    metadata:
17
      labels:
18
        app: my-app
19
    spec:
20
      containers:
21
      - name: app
22
        image: my-app:latest
23
        ports:
24
        - containerPort: 8080

看到区别了吗？部署文件里没有 Sidecar 注入的痕迹。Ambient Mode 在节点级别统一处理流量，你的 Pod 该怎么跑还怎么跑。

性能对比：数据会说话#

我在一个生产集群上做了 A/B 测试，结果如下：

简单说：Ambient Mode 把 Service Mesh 的资源开销从「无法接受」降到了「可以忽略」。

如何处理 mTLS 和零信任安全？#

Ambient Mode 的另一个亮点是四层和七层分离的架构。对于只需要 mTLS 加密的场景，它只在四层（网络层）处理，零开销：

1
# 四层安全策略 - 无需七层处理
2
apiVersion: security.istio.io/v1beta1
3
kind: PeerAuthentication
4
metadata:
5
  name: default
6
  namespace: production
7
spec:
8
  mtls:
9
    mode: STRICT  # 强制 mTLS
10
  # Ambient Mode 自动在节点层处理 mTLS，无需 Sidecar

而对于需要七层（应用层）精细控制的场景（比如 HTTP 路由、JWT 验证），可以按需启用waypoint 代理：

1
# 按 namespace 启用七层处理
2
apiVersion: gateway.networking.k8s.io/v1
3
kind: Gateway
4
metadata:
5
  name: waypoint
6
  namespace: production
7
spec:
8
  gatewayClassName: istio-waypoint
9
  listeners:
10
  - name: mesh
11
    port: 15008
12
    protocol: HBONE  # Ambient 的专属传输协议

这种分层设计意味着：90% 的流量只需要四层处理，只有需要复杂路由的场景才走七层，大幅降低了整体开销。

生产迁移：从 Sidecar 到 Ambient#

迁移过程比你想象中平滑：

1
# 1. 安装 Istio Ambient 模式
2
istioctl install --set profile=ambient --set components.ingressGateways[0].enabled=true
3

4
# 2. 按命名空间逐步启用
5
kubectl label namespace staging istio.io/dataplane-mode=ambient
6

7
# 3. 验证
8
kubectl get pods -n istio-system
9
# 应该看到: istio-cni-node-xxx, ztunnel-xxx, istiod-xxx
10
# 没有: istio-proxy (Sidecar 容器不见了)
11

12
# 4. 逐步迁移生产命名空间
13
kubectl label namespace production istio.io/dataplane-mode=ambient --overwrite
14

15
# 5. 旧 Sidecar 自动清理
16
# Ambient Mode 会忽略已有 Sidecar 注入的 Pod，滚动更新后自动切换
17
kubectl rollout restart deployment -n production

2026 年的 Service Mesh 生态#

除了 Istio Ambient Mode，还有几个值得关注的动向：

1. Sidecarless 成为共识：Cilium Mesh、Kuma、Linkerd 都在朝这个方向演进。Cilium 利用 eBPF 技术在内核层面实现了服务网格功能，不需要任何额外的代理进程，性能开销趋近于零。

2. Gateway API 成为标准：取代旧的 Ingress API，Istio Gateway API 已 GA。新的 API 设计更加关注角色分离——平台团队定义基础设施策略，应用团队只关心路由规则。这让企业级的多租户管理变得更加清晰。

3. eBPF 加持：Cilium 用 eBPF 实现 Service Mesh 功能，进一步降低开销。eBPF 在 2026 年已经从一个「小众技术」变成了云原生的基础设施标配，几乎所有主流的网络和安全方案都在用它。

4. AI 工作负载的特殊支持：Service Mesh 开始为 GPU 集群的通信模式做优化。传统的 HTTP/gRPC 流量模式和 AI 训练中的 all-reduce、all-gather 等集合通信模式完全不同——前者是 request-response，后者是连续的流式数据传输。新一代 Service Mesh 正在为这些场景设计专门的流量调度策略。

5. FinOps 集成：2026 年的一个新兴趋势是把 Service Mesh 的流量数据接入成本分析平台。通过 Ambient Mode 的节点级代理，可以精确统计每个服务的网络开销，帮助团队做出更合理的资源分配决策。

什么时候不应该用 Service Mesh？#

说了这么多 Service Mesh 的好处，我也得泼一盆冷水——不是所有场景都适合上 Service Mesh。

• 小团队单服务：如果你只有一两个微服务，甚至还是单体架构，Service Mesh 带来的复杂度远超收益。别为了「炫技」而引入不必要的工具。
• 对延迟极度敏感：虽然 Ambient Mode 已经将延迟增加控制在 1ms 以内，但对于高频交易、实时音视频等场景，任何额外开销都是不可接受的。
• 团队 K8s 经验不足：如果团队连 Pod 的网络策略都还没搞明白，建议先打好基础再上 Service Mesh。否则出问题了都不知道该查哪个日志。

总结#

Service Mesh 在 2026 年没有「死」，它只是换了一种更聪明的方式活着。Ambient Mode 用节点级代理 + 按需七层处理的方案，解决了 Sidecar 时代最痛的两个问题——资源开销和运维复杂度。

从 Sidecar 到 Ambient Mode 的演进，其实反映了整个云原生生态的一个深层趋势：从「通用解决一切」到「按需分层处理」。Sidecar 模式试图用一个方案解决四层安全、七层路由、可观测性所有问题，结果就是每个问题都被解决了，但资源开销成了新的问题。Ambient Mode 的做法更聪明——90% 的场景只需要四层处理，那就用轻量级的 ztunnel 搞定；剩下 10% 需要七层精细控制的场景，才按需启动 waypoint 代理。

这种「按需分层」的思路，其实在系统设计的很多领域都能看到类似的趋势——从单体到微服务再到服务网格，从过度设计到精准投放。Ambient Mode 不是 Service Mesh 的终点，但它一定是 Service Mesh 走向成熟的关键一步。

对于已经在 K8s 上运行生产负载的团队，现在是重新评估 Service Mesh 的最佳时机。你不需要一次性迁移所有命名空间，可以先挑一个非核心服务做试点，体验一下 Ambient Mode 带来的变化。Cilium Mesh 也是一个值得关注的选择——如果你的团队已经在用 Cilium 做 CNI 插件，添加 Mesh 功能的边际成本几乎为零。

技术的轮回从来不是简单重复——Ambient Mode 证明了，有时候「减法」比「加法」更能推动进步。