Cilium 的核心优势和价值（高性能的 L3/L4 网络、安全、可观测性以及基本的 L7 路由）完全不依赖 xDS。它用 eBPF 和 Kubernetes 原生 API 构建了一套更高效、更简单的数据平面。

为了填补生态空白，提供最丰富、最成熟的 L7 应用层功能，Cilium 选择性地集成并充当了 xDS Server，以此来驱动一个可选的、集中式的 Envoy 代理。

Cilium 代表了服务网格和数据平面的一个演进方向：从通用的、笨重的用户态代理向专用的、高效的内核态原语演进。xDS 作为上一代代理架构的核心协议，其重要性正在被以 eBPF 为代表的操作系统原生能力所稀释。未来的协议可能更偏向于描述“要什么策略”，而不是“代理该如何一步步执行”，具体的执行则由内核或智能网卡来完成。

在cilium新一代服务网格技术下，grpc应用会出现两种可能的模式：

• gRPC 应用“去 xDS”模式：
  • 场景：当你只使用 Cilium 提供的基本到中级的流量治理功能（如负载均衡、基于权重的金丝雀发布、基于路径的路由、网络层熔断）时。
  • 实现：gRPC 客户端无需内嵌 xDS 客户端，也无需连接任何 xDS 服务器。它只需使用其内置的、简单的负载均衡器（如 round_robin），目标是 Kubernetes Service 的 DNS 名称。
  • 谁来干活：Cilium 的 eBPF 数据平面会拦截流量，并在 TCP/IP 层甚至 HTTP 层（借助 eBPF 解析 HTTP）​ 执行所有配置好的路由和策略。这对 gRPC 应用是完全透明的。
• gRPC 应用“仍需 xDS”模式：
  • 场景：当你需要非常高级的、应用层特有的流量治理功能时，而这些功能是网络层无法或不宜实现的。例如：
    • gRPC 方法级的路由和超时：将 /package.Service/MethodA路由到 v1 版本，/package.Service/MethodB路由到 v2 版本。
    • 复杂的请求/响应体内容修改。
    • 与 gRPC 协议深度耦合的故障注入和治理。
  • 实现：此时，你可能仍需采用 Envoy Proxy 作为 Sidecar 或门卫代理。gRPC 应用可以通过 xDS 与 Envoy 交互，或者，Cilium 自身也可以作为一个 xDS 服务器，向其管理的 Envoy 代理（如果存在）下发更细粒度的配置。或者，应用内嵌的 gRPC xDS 客户端可以直接与 Cilium 提供的 xDS 服务通信。

上一篇 « 下一篇 »