在太多受监管的技术组织中，一个熟悉的项目仍在不断上演。成立一个平台团队来“拥有 Kubernetes”。再拨款一个工作流来“工业化 Istio”。路线图跨越多个财年。董事会听取有关成熟度模型、金丝雀路径和控制平面所有权的汇报，而产品团队仍在等待命名空间、证书和东西向策略——这些能力竞争对手早已作为产品直接消费。不舒服的事实并非 Istio 能力不足，而是市场早已将相同能力产品化，而你却在为不再带来差异化的重建工作买单。
Kubernetes 多年前就已不再是前沿技术。CNCF 2025 年度调查显示，82% 使用容器的组织已在生产环境中运行 Kubernetes。服务网格也经历了同样的轨迹：从开创性的 Sidecar 集群，到 CNCF 毕业的项目、Ambient 模式和 eBPF 数据平面、企业发行版以及 hyperscaler 附加组件。将其中任何一项视为多年期的登月计划已不再是谨慎之举，而是一种昂贵的习惯。
问题：将商品化基础设施当作登月计划
Istio 仍然是一个强大的服务网格。它于 2023 年 7 月在 CNCF 毕业。Ambient 模式随 Istio 1.24 于 2024 年 11 月达到正式可用，将每个 Pod 的 Envoy Sidecar 开销替换为节点级的 ztunnel（用于 L4），并可选使用 waypoint 代理（用于 L7）。这些都无法解决组织层面的问题。能力并不意味着你必须重新发明运营模式。许多公司仍在组建大型平台项目，来重建 Google Cloud Service Mesh（前身为 Anthos Service Mesh）、AKS Istio 附加组件、商业多区域网格以及开源替代方案——这些方案已随支持合同、升级路径和记录在案的爆炸半径控制一起交付。
成本很少体现在开源许可上，因为通常根本没有许可费用。真正的成本是多年的平台工程、升级时的值班剧场、证书和身份胶水代码，以及在网格“成熟”期间延迟的产品工作。关于自建内部开发者平台的独立评论反复发现，运营人力和机会成本远超计算资源。《The New Stack》对自建平台的分析显示，当诚实地将各成本中心的薪酬计入时，完整的企业平台每年成本可达数千万美元。即使是方向性数字也不如模式重要：你正在将稀缺的工程师用于行业早已作为商品出售的基础设施。
为什么 Istio 成为默认选择，以及为什么这不再是定论
Istio 凭借清晰的原因赢得了早期领先地位。Envoy 作为数据平面、丰富的 L7 策略以及来自 Google 和 IBM 的影响力，使其成为会议走廊和架构评审中的默认答案。在一段时间内，选择 Istio 看起来就像选择了市场本身。这一历史在招聘和评估基于相同 API 的托管产品时仍然重要。但这并不意味着每家银行都应资助一个永久的 Istio 构建项目。
Ambient 模式降低了使 Istio 以内存和升级频繁而闻名的 Sidecar 开销。官方 Istio 性能材料和供应商基准测试显示，当 L4 在 ztunnel 中运行且仅在需要 waypoint 时才支付 L7 开销时，资源节省显著。这是一项真正的改进。但它并未消除控制平面复杂性、多集群联邦工作、策略编写规范，或在凌晨 2 点流量策略出错时理解故障模式所需的人员。现在，服务网格是一种你可直接消费的能力。在公司内部发明一个对大多数受监管的多云环境而言是错误的默认选择。
市场早已构建了替代方案
开源货架以一种有益的方式变得拥挤。Istio（Sidecar 和 Ambient）、采用 Rust 微代理的 Linkerd、基于 Cilium 的 eBPF 服务网格、HashiCorp Consul 和 Kuma 都以不同的权衡解决了连接、双向 TLS 和流量策略问题。Linkerd 仍是仅 Kubernetes 环境追求自动 mTLS 和金丝雀指标且操作面狭窄的简洁基准。当 Cilium 已是集群 CNI 且 eBPF 可在不引入第二个控制平面的情况下覆盖身份、策略和可观测性时，它通常是理性的选择。Consul 仍适合深度使用 HashiCorp 技术栈且有多数据中心需求的组织。
企业和多区域产品构建在这一基础之上。Kong Mesh 基于 Kuma 和 Envoy，提供多区域控制、通过 Envoy 的 BoringSSL 模式实现的 FIPS 140-2 支持、内嵌 Open Policy Agent（MeshOPA）以使 Rego 随数据平面一起运行而非再建一个 Sidecar 集群、面向审计的控制措施，以及与 Kong Gateway 的集成，适合希望将南北向和东西向策略置于单一供应商关系下的运营商。这种组合清晰地映射到混合 Kubernetes 与 VM 的环境，并需要一个受支持的跨区域和跨云的全局控制平面。
Hyperscaler 也将 Istio 运维产品化。Google Cloud Service Mesh 为 GKE 集群管理控制平面生命周期。微软针对 AKS 的 Istio-based 服务网格附加组件提供经过测试的版本兼容性、托管控制平面扩展和官方 Azure 支持。在 Amazon EKS 上，模式更多由市场驱动：来自专业供应商的附加组件和发行版，而非像 Azure 那样的单一第一方托管 Istio 控制平面。对于受监管的多云环境，“广泛可用”现在意味着你可以在每个主要云上购买受支持的网格能力，使用带商业支持的开源，或运行一个跨 Kubernetes 和 VM 的多区域产品，而无需假装每个工作负载都位于一个全新的单一集群中。
如何在不进行选美比赛的情况下评估选项
从数据平面开始。Sidecar Envoy 仍是成熟的 L7 工作马。Ambient 模式和 Cilium 的 eBPF 路径降低了每个 Pod 的开销。Linkerd 的 Rust 代理保留了 Sidecar 模型，但缩小了二进制体积和功能面。没有哪一个在所有场景下都绝对优越；每个方案都会改变内存、升级中断以及在不额外附加组件的情况下可表达的 L7 策略量。
然后是范围。仅 Kubernetes 的网格（经典 Linkerd、许多 Ambient Istio 部署、集群上的 Cilium）在资产真正仅为 Kubernetes 上的容器时表现良好。当你仍在运行 VM、需要跨区域的身份且拒绝在每个云上采用不同的网格方案时，像基于 Kuma 的 Kong Mesh 这样的多区域产品就很重要。当你已标准化于单一云并希望微软或 Google 负责控制平面升级时，Hyperscaler 托管的 Istio 非常出色。当策略文档强调多云且审计团队询问如何在 Azure、AWS 和私有 Kubernetes 上证明相同的策略图时，它就成了较弱的答案。
运维和治理完成整个框架。询问升级节奏和爆炸半径需要多少平台工程师。询问双向 TLS、工作负载身份、策略即代码和审计轨迹是作为产品特性交付，还是作为一个为期两年的内部项目。商业支持并非道德缺陷。对于受监管的运营商而言，这是将开源能力转化为可在审计时为控制失效辩护的东西的方式。
什么真正适合银行和保险公司
混合和多云是常态，而非未来状态。工作负载分布在多个 hyperscaler 上，加上私有 Kubernetes 和大量不会因为平台幻灯片写着“云原生”就消失的顽固 VM。零信任东西向流量、加密的工作负载身份以及面向审计的证据是基本要求。纯绿地单一集群是烧钱的幻想。
这种模式倾向于选择一个可跨区域的受支持控制平面，而不是必须在每个其他平台上重新解释的单云网格。Kong Mesh 和类似的多区域产品正契合这一现实：策略和身份可跨 Kubernetes 和 VM 流动、面向 FIPS 的加密选项、内嵌 OPA 以提供授权证据，以及商业支持路径。它们不是魔法。它们是一次性购买而非按云重建的基础设施。
在有界场景中，本地选择仍会胜出。当问题是纯 Kubernetes 环境、团队希望最小的 Day-2 负担且已预算 Buoyant Enterprise 支持时（从 2024 年初开始，大型组织的稳定发布工件已移至该订阅模式），Linkerd 通常更好。当 Cilium 已是 CNI 且 eBPF 可在不引入 Istio 完整表面的情况下覆盖所需的 mTLS 和策略深度时，它仍是更好的本地选择。当你深度使用 GKE 或 AKS、愿意让该提供商拥有控制平面且不试图在三个云上以不变的方式运行相同的网格控制方案时，Hyperscaler 托管的 Istio 附加组件仍是更好的本地选择。公平选择胜过品牌忠诚。
从零构建 Kubernetes 和 Istio 的隐形成本
平台人力是可见的成本线。值班轮换、升级剧场、证书颁发机构运维、Sidecar 或 Ambient rollout 失败，以及“让网格更安全”的永久待办事项票据则是 quieter 的成本。关于 Istio 总拥有成本的行业报告一致发现，对于中等规模的环境，运维开销超过 Sidecar 计算成本；昂贵的部分是当系统行为异常时理解它的人员。自建 Kubernetes 平台在网络、入口、可观测性和安全工具方面放大了同样的算术。
机会成本更糟。每一位调试注入失败或起草又一个内部 Istio Operator 的工程师，都没有在交付风险模型、客户旅程、理赔自动化或能改善损益表的韧性工作。《The New Stack》对自建平台的批评直白地指出了速度差距：供应商持续交付，而你的构建项目在追逐一个不断移动的目标，通常落后于商业路线图一年或更长时间。最伤人的锁定不是供应商标志，而是锁定在你自己未完成平台中的配置、操作手册和部落知识——当原始团队离开时，只有在你自己的栈内有效，且无人会支持。
解放开发人员
在托管或受支持的发行版足够好的地方购买商品化 Kubernetes。根据资产形态购买受支持的网格：在混合和多云策略必须一次性应用时选择 Kong Mesh 等多区域产品；在本地边界清晰且范围较窄时选择 Linkerd、Cilium 或 Hyperscaler 托管的 Istio。将工程时间投入到策略设计、数据分类、客户旅程以及业务韧性上，而不是重新发明 Envoy 配置管理。
CTO 或 CIO 本季度即可做出简短的一组决策。首先，在技术策略中宣布 Kubernetes 和服务网格为商品化基础设施，并明确禁止新的多年重建项目，除非有书面例外。其次，清点哪些地方需要网格来实现零信任东西向，哪些是 cargo cult。第三，选择默认方案：对跨云和混合 VM 的领域采用多区域受支持网格；对有界的 Kubernetes 孤岛采用托管 Istio、Linkerd 或 Cilium。第四，将策略即代码、身份和审计证据作为平台产品来资助，而不是“更多 Istio YAML”。第五，将平台成功衡量为受治理工作负载的交付时间和跨云的策略恢复时间，而不是内部控制平面代码的行数。
停止重建网格。行业早已在出售管道。购买它们的银行和保险公司将在未来几年专注于真正带来差异化的问题。而那些继续将 Istio 和 Kubernetes 视为登月计划的机构，将继续为基础设施配备人员并称之为战略。