在近期整理服务网格数据平面的几种部署模式时，我关注到了徐中虎在 KubeCon China 2024 的分享《Istio 数据平面的新选择：全新性能体验的架构创新》。该分享介绍了 Kmesh，它利用 eBPF 和内核增强技术，消除了 Sidecar，并提出了双引擎模式，是一种创新性的服务网格解决方案。去年我已听闻 Kmesh，借此契机我深入研究了 Kmesh，撰写此博客与大家分享。

背景

像 Istio 这样的服务网格已成为管理复杂微服务架构的核心，提供流量管理、安全性和可观测性等功能。Sidecar 模型，即在每个服务实例旁运行一个代理，已成为主要方法。虽然功能有效，但这种架构引入了显著的延迟和资源开销。

传统 Sidecar 架构的局限性

1. 延迟开销：增加 Sidecar 代理会导致网络跳数和上下文切换增加，每次服务调用引入额外 2 至 3 毫秒 的延迟。对于对延迟敏感的应用，这种延迟是不可接受的。

2. 资源消耗：每个 Sidecar 都会消耗 CPU 和内存资源。在拥有数千个服务的大规模部署中，累积的资源开销巨大，虽然可以通过一定的技术手段进行优化，但依然降低了部署密度并增加了运营成本。

Istio 的性能测量显示，即使没有流量分发，仍存在约 3 毫秒的固有延迟开销。随着连接数量的增长，延迟相应增加，这突显了 Sidecar 模型在高性能应用中的低效。

行业应对挑战的尝试

已经提出了多种解决方案来缓解 Sidecar 架构的缺点：

Cilium 服务网格

• 方法：将 eBPF 与 Envoy 相结合，创建一个无 Sidecar 的服务网格。
• 机制：
  • L4 流量：使用 eBPF 进行高效的内核级数据路由。
  • L7 流量：依赖 Envoy 进行应用层解析。
• 局限性：
  • L7 额外跳数：通过 Envoy 进行 L7 管理引入了额外的网络跳数。
  • 故障隔离：在确保治理故障隔离方面存在挑战。

Istio Ambient Mesh

• 方法：使用 ztunnel 和 waypoint 代理，引入无 Sidecar 的架构。
• 机制：
  • 用户空间处理：所有流量拦截和管理都在用户空间进行。
• 局限性：
  • 复杂的流量拦截：用户空间的拦截增加了复杂性。
  • 跳数增加：L7 连接涉及多个网络跳数，增加了延迟。

这些解决方案虽然创新，但并未完全解决 Sidecar 架构固有的延迟和资源开销问题。

更多详细信息可以参考我的另一篇文章：数据平面的几种部署模式。

介绍 Kmesh：一种内核原生的方法

Kmesh 通过将流量治理直接集成到操作系统内核，定义了一种新的服务网格数据平面。利用 eBPF（扩展伯克利数据包过滤器）和内核增强，Kmesh 提供高性能、低延迟和资源高效的服务网格能力。

技术架构

下图展示了 Kmesh 的架构。

核心组件：

• Kmesh-Daemon：每个节点的管理组件，负责：

  • 管理 eBPF 程序。
  • 从控制平面（如 Istiod）订阅 xDS 配置。
  • 处理可观测性和指标收集。

• eBPF 编排：在内核级实现流量拦截和管理，支持：

  • L4 负载均衡。
  • 流量加密和解密。
  • 监控和简单的 L7 动态路由。

• Waypoint Proxy（双引擎模式下可选）：处理高级 L7 流量治理，可按命名空间或服务进行部署。

关键优势

该分享中指出 Kmesh 具有以下优势，尤其是性能和资源利用率上：

1. 高性能：

   • 延迟降低：与传统 Sidecar 架构相比，内核原生的 L7 管理将转发延迟降低了超过 60%。
   • 应用启动改进：由于消除了 Sidecar 初始化，应用启动时间提升了 40%。

2. 低资源开销：

   • 资源效率：无需 Sidecar 代理，资源消耗减少了超过 70%。

3. 高可用性：

   • 无缝升级：内核级流量管理确保升级或重启 Kmesh 组件不会中断现有的服务连接。

4. 安全隔离：

   • 增强的安全性：利用基于 BPF 的虚拟机安全和 cgroup 级别的治理隔离，确保安全的多租户环境。

5. 灵活的治理模型：

   • 部署模式：提供内核原生模式以实现最大性能，和双引擎模式以获得部署灵活性。

6. 无缝兼容性：

   • 控制平面集成：完全兼容 xDS 协议，允许与 Istio 控制平面集成，支持 Istio API 和 Gateway API。

Kmesh vs Ambient vs Cilium mesh

通过上文中对 Kmesh 的介绍，你会发现它与 Istio Ambient 模式及 Cilium mesh 有很多相似性，下表将从多个维度对比它们之间的区别。

总结：

• Kmesh：通过将流量治理下沉到内核，实现高性能和低延迟，适用于对性能和资源效率要求极高的应用。但需要特定的内核支持，部署时需考虑兼容性。

• Istio Ambient Mesh：消除了 Sidecar，改进了性能，保留了 Istio 的丰富功能，但用户空间处理可能带来新的复杂性和延迟。

• Cilium Mesh：利用 eBPF 提高 L4 性能，但 L7 流量处理依赖 Envoy，可能增加复杂性和延迟。适合已经使用 Cilium 的环境，提供强大的网络策略和安全功能。

Kmesh 的两种运行模式

Kmesh 提供两种运行模式，以满足不同的部署需求：

内核原生模式

概述：

• 极致性能：在 L4 和 L7 流量中实现最低的延迟，无额外的网络跳数。
• 机制：
  • 内核增强：使用 eBPF 和内核模块（ko）增强内核。
  • 伪造的 TCP 连接：在内核中利用“伪建链”来管理复杂的应用层流量。
  • 流量管理：在客户端发起通信时直接管理流量，消除不必要的上下文切换和数据拷贝。

优势：

• 延迟降低：转发延迟减少超过 60%。
• 无需用户空间代理：整个流量管理在内核内完成。

考虑因素：

• 内核版本要求：可能需要特定的内核版本或增强，这可能影响部署的灵活性。

双引擎模式

概述：

• 灵活治理：在性能和更广泛的兼容性之间取得平衡。
• 机制：
  • 内核级拦截：使用 eBPF 在内核空间拦截流量。
  • Waypoint Proxy：部署远程的 Waypoint Proxy 来处理复杂的 L7 流量管理。
  • 层次分离：将 L4 和 L7 的治理在内核空间（eBPF）和用户空间（Waypoint）之间分离。

优势：

• 延迟降低：相比 Istio 的 Ambient Mesh，延迟减少了 30%。
• 简化的流量拦截：内核空间的拦截比用户空间更安全、更简单。
• 降低采用门槛：减少对特定内核版本的依赖，便于用户采用。

与 Ambient Mesh 的比较：

• 更少的网络跳数：Kmesh 对于 L7 连接仅增加一个额外跳数，而 Ambient Mesh 可能增加多达三个。
• 更简单的架构：内核级拦截避免了用户空间拦截机制的复杂性。

深入了解 Kmesh 的技术

eBPF 和内核增强

eBPF（扩展伯克利数据包过滤器） 是一种强大的技术，允许安全高效地将自定义代码注入到 Linux 内核。Kmesh 利用 eBPF 来：

• 拦截网络流量：将 eBPF 程序附加到网络事件，实现对数据包的实时拦截和操作。
• 实现负载均衡：根据策略将流量导向合适的服务实例。
• 执行流量加密：在内核中处理 mTLS 加解密（开发中，计划 2024 年底支持），降低开销。
• 收集可观测性数据：在不影响应用性能的情况下收集指标和遥测数据。

流量拦截和管理

在内核原生模式中：

• 伪造的连接：Kmesh 在内核中创建伪造的 TCP 连接，避免涉及用户空间代理来管理流量。
• 直接的数据包操作：在内核级拦截和重定向数据包，消除在用户空间和内核空间之间移动数据包时的上下文切换和数据拷贝。

在双引擎模式中：

• eBPF 拦截：eBPF 程序处理初始的流量拦截和基本的 L4 管理。
• Waypoint Proxy：对于路由、重试和头部操作等高级 L7 功能，流量被转发到按服务或命名空间部署的 Waypoint Proxy。

安全和隔离

• BPF 虚拟机安全：eBPF 在内核中的受限虚拟机中运行，确保注入的代码不会破坏内核稳定性。
• cgroup 级别隔离：在 cgroup 级别应用治理策略，为不同的服务和工作负载提供隔离。
• mTLS 支持：计划在内核中实现双向 TLS，提供零信任安全，而无需用户空间的加密开销。

性能分析

测试设置：

• 基准工具：使用 Fortio 生成负载并测量延迟。
• 比较对象：在四种配置下测量性能：
  1. 基线：没有任何服务网格的直接通信。
  2. Istio Sidecar：传统的 Sidecar 部署。
  3. Istio Ambient Mesh：使用 ztunnel 和 Waypoint 的无 Sidecar 部署。
  4. Kmesh：包括内核原生模式和双引擎模式。

结果：

• 延迟：
  • Kmesh 内核原生模式：相比 Istio Sidecar，转发延迟降低了超过 60%。
  • Kmesh 双引擎模式：相比 Istio Ambient Mesh，延迟减少了 30%。
• 资源消耗：
  • CPU 和内存：Kmesh 将资源开销降低了超过 70%，因为无需 Sidecar 代理。
• 应用启动时间：
  • 提高了 40%，因为应用不再需要等待 Sidecar 初始化。

解读：

• Kmesh 接近基线性能，使服务网格的开销可以忽略不计。
• 消除上下文切换和数据拷贝对性能提升贡献显著。
• 内核原生方法确保即使服务数量增加，性能也能保持一致。

云原生集成与兼容性

• Kubernetes 原生：Kmesh 无缝运行在 Kubernetes 上，管理 Pod 的进出流量，无需更改应用代码。
• 控制平面集成：
  • xDS 协议支持：从 Istiod 订阅 xDS 配置，确保与 Istio 控制平面兼容。
  • Istio API 兼容性：支持现有的 Istio API，允许用户使用熟悉的配置和策略。
• Gateway API 支持：兼容 Gateway API，支持更灵活和丰富的流量管理。
• 可观测性：
  • 集成 Prometheus 进行指标收集。
  • 利用 eBPF 高效地收集数据，不影响性能。
• 安全策略：
  • 支持现有的 Istio 安全策略，包括认证和授权。

结论

Kmesh 通过将流量管理移入内核，代表了服务网格技术的范式转变。利用 eBPF 和内核增强，它解决了传统 Sidecar 架构中延迟和资源开销的关键问题。Kmesh 为现代云原生应用提供了灵活、高性能的解决方案，特别适用于需要低延迟和高吞吐量的场景。

主要收获：

• 性能：通过消除不必要的开销，实现接近基线的性能。
• 资源效率：降低 CPU 和内存消耗，提升部署密度。
• 灵活性：提供多种运行模式，适应不同的部署场景。
• 安全性：通过内核级的执行和隔离机制增强安全性。
• 兼容性：与包括 Kubernetes 和 Istio 在内的现有云原生生态系统无缝集成。

参考

• IstioCon 2023 要点总结
• Istio 数据平面的新选择：全新性能体验的架构创新