跳至主要內容

服务网格与东西向流量治理工具

一次服务调用返回 200，并不等于服务网格已经正确工作。请求可能根本没有进入代理，身份可能沿用了旧证书，授权策略可能只存在于控制面，版本路由也可能因为端口协议识别错误而从未生效。等到故障发生，团队只看到 Pod Ready 和一张有连线的拓扑图，却无法回答请求经过哪个数据面、使用哪个身份、命中哪版配置、由谁返回状态码。

服务网格交付的不是“给每个 Pod 加一个容器”，而是一条可验证、可演进、可退出的服务间通信链。流量接管、工作负载身份、mTLS、授权、路由、重试、出口和遥测分别拥有状态与故障模式；把这些对象压成一个绿色状态，会让最危险的错误静默存在。工具选择也不能从功能表开始，而要先确定网络、身份、控制面、故障域和团队责任怎样组合。

服务网格控制面数据面工作负载身份流量策略观测升级退出知识海报
服务网格与东西向流量治理工具链从工作负载纳管、身份与策略，到真实请求、观测、容量、升级和安全退出高清原图

先把一条请求拆成七个状态

服务 A 调用服务 B 时，至少有七个状态需要分别证明：

  1. 工作负载被选中。 namespace、Pod label、ServiceAccount、VM 注册或节点配置把它纳入目标集合。
  2. 流量被真实接管。 iptables、CNI、eBPF、sidecar、ztunnel、waypoint 或节点 Envoy 位于实际路径，而不是只创建了资源。
  3. 端点与路由已收敛。 控制面发现正确实例，数据面装载目标配置版本，协议识别与端口语义一致。
  4. 双方身份有效。 源和目标使用预期工作负载身份、信任域与证书，时钟和根信任允许握手。
  5. 策略在正确执行点判定。 L4/L7 授权、租户约束、版本路由、超时和重试落在真实路径上。
  6. 应用产生权威结果。 代理本地 403、503 与上游业务 4xx/5xx 被区分，重试不会掩盖首次失败。
  7. 证据能够关联。 request ID、身份、端点、策略结论、配置版本、日志、指标和 Trace 指向同一次调用。

网格请求证据模型与选型把这七段状态压成可执行的正反实验。当你需要比较不同数据面或审核一次网格变更时，先用这组判据排除假阳性：控制面 Ready、代理容器存在、mTLS=true、拓扑图连线和单个成功响应都只是局部证据。

这也是后续文章的阅读顺序。先建立无网格基线与请求证据，再处理纳管、身份、授权和流量策略；随后进入出口、观测、多集群与容量；最后才讨论升级和退出。直接从某个产品的安装命令开始，容易在控制面安装成功后误以为通信能力已经交付。

决策顺序先回答的问题对应入口
请求事实请求是否真的经过预期数据面，状态码由谁产生网格请求证据模型与选型
纳管边界哪些 Pod、namespace、VM 和端口被接管，哪些仍能旁路工作负载纳管与流量接管
信任与权限谁签发身份，mTLS 在哪段成立，策略在哪个执行点拒绝网格身份、mTLS 与证书轮换、网格授权、租户与策略治理
流量行为路由、超时、重试、出口和遥测如何共同改变请求网格流量路由与韧性、网格出口与外部服务
长期运行故障域、容量、升级事务和退出路径是否可承担多集群、性能与容量治理、网格升级、迁移、弃用与退出治理

数据面形态决定成本和故障方式

每工作负载代理

Istio Sidecar、Linkerd、Consul 和 Kuma 的常见 Kubernetes 路径，会在每个被纳管的 Pod 附近运行代理。请求的 L4/L7 状态、身份、策略和遥测能够贴近工作负载，但代理版本、CPU、内存、启动顺序、注入、端口捕获和滚动重建也与应用生命周期耦合。

sidecar 并不天然意味着更安全。未注入 Pod、hostNetwork、排除端口、错误探针重写、应用自行绑定 loopback、UDP 或不受支持协议都可能绕过预期路径。验证必须同时包含已纳管、未纳管和错误配置工作负载。

每节点安全覆盖与按需七层代理

Istio Ambient Mesh用每节点 ztunnel 提供 L4 身份和 HBONE 安全覆盖，目标服务需要 HTTP 路由、L7 授权或丰富遥测时，再经过 waypoint。业务 Pod 没有 sidecar，不代表没有代理；只是代理从 Pod 生命周期移到了节点和 namespace/service 的策略选择上。

ambient 会改变升级和故障域。sidecar canary 可以按 workload 重建，ztunnel 与 CNI 升级则影响节点上的一批连接；waypoint 的容量也可能成为多个服务共享的 L7 瓶颈。选型时要把节点滚动、连接排空和 waypoint 故障纳入预算。

waypoint 也不是“创建后自动覆盖所有流量”。它按目标资源选择，未显式绑定的 Service 或 workload 不会经过它；当前实现中，网格外来源可能直接到达目标而绕过 waypoint。需要 L7 强制策略时，必须同时证明来源已纳管、目标绑定正确、waypoint 类型覆盖原始目标类型，并用未纳管来源做拒绝反证。

eBPF 与 Envoy 组合

Cilium Service Mesh把 L3/L4 网络、负载均衡、安全身份和流观测放在 Cilium agent 与 eBPF 路径中，L7 解析、策略或 Gateway API 流量仍会进入 Envoy。它减少 per-Pod sidecar，不会消除代理、节点特权、CNI 迁移和内核兼容责任。

Cilium 适合愿意把 CNI、网络安全、负载均衡和服务网格作为一个平台能力治理的团队。已有稳定 CNI、只希望增加成熟工作负载 mTLS 的环境，则要认真比较迁移风险，而不是只比较 Pod 资源开销。

Cilium 的流身份、网络策略、透明加密和 Mutual Authentication 不能混为一个开关。当前稳定文档仍将 Mutual Authentication 标为 Beta，并列出多集群统一信任域、外部 mTLS 互操作等限制；需要成熟跨集群工作负载 mTLS 时，这些限制属于选型否决项，而不是上线后再补的运维细节。

Kubernetes 与 VM 混合数据面

Consul Service Mesh和 Kuma都能跨 Kubernetes 与 VM/Universal 工作负载，但注册、身份、透明代理、网络可达性和升级责任随平台变化。VM 上没有 admission webhook 帮忙修正配置，服务注册、代理 bootstrap、证书目录、进程监督和退出清理都要显式完成。

Consul 还把 catalog、Connect CA、intentions、mesh gateway 与多数据中心状态结合起来；Kuma 通过 global/zone control plane 和 data plane proxy 支撑 multi-zone。它们适合混合基础设施，不代表跨网络、跨信任域和跨组织连接可以自动成立。

托管发行版与标准 API 各自解决什么

Red Hat OpenShift Service Mesh是带支持矩阵、Operator 生命周期和 downstream 组件版本的发行版。上游 Istio 的 Helm 命令、feature stage 和 conformance 不能直接替代 Red Hat 支持入口；Operator、OpenShift 版本、Istio、Envoy、CNI、Ztunnel、Kiali 和 Tempo 必须按 OpenShift Service Mesh 版本支持矩阵作为同一兼容事务核对。

Gateway API GAMMA让 HTTPRoute、GRPCRoute 等资源附着到 Kubernetes Service，统一部分东西向路由语义。它不是一个数据面，也没有统一所有身份、授权、mTLS、遥测和出口策略。Gateway API mesh overview把 Service attachment 与 Mesh Profile 分开说明：资源进入 Standard Channel，只说明 API 语义获得相应稳定性；目标实现、版本和扩展能力仍要看 conformance report 与运行状态。

路由对象的 Accepted、ResolvedRefs 与 observedGeneration 只能证明实现如何处理声明，不能证明代理已经装载或真实请求已经命中。Programmed 也不是所有 Route 都具备的通用状态；必须按具体 API 类型和实现核对 condition，再用数据面配置与请求计数闭环。

身份、授权和业务语义必须分层

工作负载纳管与流量接管先回答请求是否经过目标数据面；网格身份、mTLS 与证书轮换再证明双方是谁、信任谁、证书怎样轮换。两步都成立后，才有资格讨论策略。

网格授权、租户与策略治理处理传输身份到访问结论的映射。网格可以根据 ServiceAccount、SPIFFE ID、namespace、端口、方法或路径做基础设施授权，但订单归属、金额上限、数据行权限等业务规则仍由应用执行。把 mTLS 当作授权，会得到“身份真实但访问仍越权”的系统。

网格流量路由与韧性把版本选择、负载均衡、超时、重试、连接池、异常实例摘除和故障注入放进同一预算。客户端 SDK、sidecar、gateway 和上游若各重试三次，最坏尝试数会乘法增长；代理不能判断一次业务写操作能否安全重放，幂等键和权威结果仍属于业务协议。

出口和观测不能停在一张拓扑图

网格出口与外部服务从 DNS、SNI、TLS、外部服务声明、集中出口和底层网络封口验证批准路径。只配置 egress gateway，却允许 Pod 直接访问公网 IP，得到的是可选审计路径，不是强制出口控制。

网格可观测与分层排障区分控制器状态、代理同步、访问日志、指标、Trace 和拓扑。主动制造 DNS 失败、策略拒绝、证书错误、无端点、上游 reset 和采集器不可达，才能证明每层证据真的可以分型。Trace 还依赖应用或入口传播上下文；代理能生成 span，不代表跨服务链会自动完整。

多集群、容量和生命周期决定能否长期使用

多集群、性能与容量治理把信任、寻址、服务发现、网络、故障域和控制面拓扑放在产品插件之前。共享根信任扩大证书泄露影响面，共享服务名可能把流量送入错误集群；网络分区时，还要明确本地端点优先、跨集群故障转移和连接排空的停止条件。

容量不能只测平均代理延迟。数据面 CPU/RSS、连接和队列，控制面 reconcile/xDS 推送、API QPS，遥测 active series、日志字节、Trace ingest 与查询成本必须一起测量。证书集中轮换、批量发布、节点滚动和远端控制面断连往往比稳定流量更容易暴露真实上限。

网格升级、迁移、弃用与退出治理把 CRD/API、控制面、CNI、节点代理、sidecar、waypoint、策略、证书、入口出口和遥测放进同一笔迁移事务中验证。退出顺序从撤销策略依赖、停止新注入、滚动业务、验证非网格路径开始，最后才删除控制面、CRD 和凭据。先删控制面，会留下失去管理的代理和无法解释的网络状态。

用一个隔离实验贯穿所有工具

统一实验使用独立 mesh-lab namespace、一个 client 和两个返回不同实例标识的 orders-v1、orders-v2。第一次请求不经过网格，保存 DNS、端点、响应和延迟基线；随后只增加一种数据面，并分别证明接管、身份、策略和遥测。

实验按以下顺序推进：

  1. 直接请求两个版本，确认应用与网络基线。
  2. 安装控制面或启用节点能力，记录精确版本、values、镜像 digest 与 CRD。
  3. 纳管一个工作负载，保留另一个未纳管工作负载作反例。
  4. 验证双方身份和 mTLS，再引入错误信任或明文客户端。
  5. 先允许，再默认拒绝，只放行目标 ServiceAccount 与路径。
  6. 进行 90/10 路由，保存足量样本和两端计数，不用单次请求判断权重。
  7. 注入慢响应、无端点、错误证书和控制面断连，区分已有连接与新连接。
  8. 回滚策略，将工作负载移出网格，删除隔离资源并检查残留。

所有命令都应在专用实验集群执行。共享或生产集群中的 CRD、webhook、CNI、根证书和控制面删除具有集群级影响，必须经过变更评审、备份、候选验证和停止条件，不能照抄实验清理动作。

选型先回答九个问题

  1. 现有 CNI 和 Kubernetes 版本是否允许目标数据面，升级由谁负责？
  2. 工作负载只在 Kubernetes，还是同时存在 VM、裸机与多集群？
  3. 需要 L4 身份与加密，还是确实需要 L7 路由、授权和遥测？
  4. sidecar 资源与滚动升级成本，和节点级故障域哪个更可接受？
  5. 身份由 ServiceAccount、SPIFFE/SPIRE、平台 PKI 还是外部 CA 签发？
  6. 控制面断连时，已有连接、新连接、端点变化、证书轮换和策略更新分别怎样退化？
  7. 出口能否用底层网络强制封口，还是只能提供可观测的推荐路径？
  8. 团队能否长期维护 CRD、代理版本、策略迁移、容量、证书和观测后端？
  9. 产品退出时，业务怎样恢复直连或迁到另一个实现，历史凭证、日志和成本怎样核销？

没有清晰答案时，先保持应用级超时、幂等、鉴权和基础网络策略，使用更小的工具闭环。服务网格可以统一通信能力，也会引入节点特权、控制面状态、策略语言、证书生命周期、遥测成本和跨团队职责；只有这些新增状态能被验证、回滚和维护时，它才真正提高研发效率。

以下任一条件成立，都应先停止产品比较：无法提供隔离集群验证 CNI、webhook 和 CRD 变更；无法确定工作负载身份与根信任 owner；无法从未纳管来源证明旁路会被拒绝；无法限制配置转储、访问日志和 Trace 中的敏感数据；无法给出控制面断连、证书过期和产品退出时的业务恢复路径。此时缺少的不是功能，而是让网格安全进入生产的组织能力。

跳到正文