K8s 服务网格：账单终将到来
微服务密集的 Kubernetes 环境越来越多地采用 Istio 和 Linkerd 之类的服务网格来提供 mTLS 加密、统一可观测性、流量整形和重试机制——但许多工程师质疑这些额外的复杂性、脆弱性和成本是否值得。评论者认为，对大多数组织来说，基础的 Kubernetes 网络、ingress 控制器或基于 SDN 的方案已经足够，而网格应被视为大型、复杂或高度受监管系统的专用工具，而不是默认选项。一个反复出现的主题是，架构选择往往既受组织失调和安全清单驱动，也受真实技术需求驱动。
讨论范围
- 重点是 Kubernetes 服务网格（Istio、Linkerd 等）、它们在实践中的使用方式，以及它们是否值得其带来的复杂性和成本。
- 许多评论将话题扩展到微服务 vs 单体、TLS/mTLS，以及组织因素。
微服务 vs 单体
- 微服务会增加集群内流量；这主要是架构本身带来的结果，而不是服务网格特有的结果。
- 支持微服务的观点：
- 一旦你到了“数百名工程师”或拥有多个产品的规模，它就能支持独立团队部署、版本控制和扩展。
- 让团队隔离相互冲突的依赖和运行时环境（例如 Python/pandas/numpy 版本冲突）。
- 怀疑论观点：
- 真正需要微服务的系统极少；很多时候它们是在弥补组织问题或虚荣心。
- 强烈建议从单体或“模块化单体（modulith）”开始，只有在规模或依赖冲突确实要求时才拆分。
服务网格承诺提供什么
- 常被提及的好处：
- 在不同语言和团队之间提供统一的指标和可观测性。
- 在整个集群范围内实现 mTLS 和“零信任”，而不必让每个团队都去学习 TLS/PKI。
- 流量整形：带预算的重试、超时、速率限制、金丝雀/蓝绿部署、细粒度路由。
- 更容易调试（按 Pod 捕获流量、L7 可见性）。
- 有人认为，网格是实现规模化 mTLS 的唯一实用途径（例如用于 FedRAMP 环境）。
复杂性、成本与过度设计
- 普遍强烈共识是，尤其是 Istio 非常复杂、资源消耗大、难以调试；一旦遇到生产问题，其文档也被认为很难理解。
- 有报告称网格每个节点会消耗相当可观的 CPU；在小型集群上，它们可能挤占工作负载资源。
- 许多人认为，Kubernetes 加上 ingress、NetworkPolicies，以及一个 CNI（通常再结合 eBPF 跟踪/可观测性）已经覆盖了大多数需求。
- 网格被认为更多是在解决组织问题（TLS/指标不一致），而不是解决硬性的技术约束。
流量、性能与协议
- Sidecar 代理会增加额外跳数，但通常只是真实网络跳数增加一次；其他副本是在同一节点上的内存中传输。
- 大多数真实环境仍然使用 HTTP/JSON；也有一些 gRPC、GraphQL、SOAP。
- 一些人指出，带宽很少是瓶颈；工程时间才是。
安全与 TLS/mTLS 争论
- 一派观点：每个服务都应该自己支持 TLS，并使用内部 PKI——一旦理解了，这样更简单，也避免了网格开销。
- 另一派观点：开发者经常错误配置 TLS（或者禁用验证）；在网格中集中管理证书并强制执行更安全，也更易维护。
- 对于集群内加密是否能真正缓解现实威胁，还是说更紧迫的是其他安全问题，存在分歧。
开发者体验与组织动态
- 应用开发者抱怨 YAML 过多，基础设施细节“渗入”他们的工作；他们想要一个简单的“部署这个应用”的流程。
- 基础设施/SRE 回应说，抽象天然会有泄漏；优秀团队会标准化平台，使一个“hello world”服务可以快速部署，但高可用、安全和合规带来的复杂性不会消失。
- 许多人警告不要默认采用 Kubernetes 和网格，也不要出于简历/“信仰”原因采用；它们应该是“有时才用”的工具，只有在明确需要其具体收益时才引入。