OpenYurt 中基于 Cilium-CNI 实现节点池流量拓扑的实践指南

背景介绍

在边缘计算场景下，OpenYurt 作为 Kubernetes 的扩展解决方案，提供了节点池（NodePool）和服务拓扑（ServiceTopology）功能，能够实现流量的本地闭环。然而，当使用 Cilium 作为 CNI 插件时，由于其基于 eBPF 的数据平面实现，传统的流量拓扑功能可能会失效。本文将详细介绍如何在 OpenYurt 环境中适配 Cilium-CNI，实现节点池级别的流量拓扑功能。

核心问题分析

OpenYurt 原生的流量拓扑功能依赖于 kube-proxy 的 iptables 规则和 yurt-hub 的端点过滤机制。但在 Cilium 环境中，服务流量会被 eBPF 程序直接转发，绕过了传统的 iptables 规则，导致以下问题：

1. 容器内访问 ClusterIP 时无法实现节点池级别的流量闭环
2. Cilium 默认会获取集群所有端点（Endpoints），不受节点池限制
3. 边缘节点和云端节点的流量行为不一致

解决方案设计

方案一：Cilium 边缘组件改造

参考 KubeEdge 社区的实践，我们可以将 Cilium 拆分为两个组件：

1. cilium-edge：专为边缘节点设计，连接 yurt-hub 获取过滤后的端点信息
2. cilium：云端组件，保持原有功能

关键改造点包括：

• 修改 KUBERNETES_SERVICE_HOST 和 KUBERNETES_SERVICE_PORT 环境变量，指向 yurt-hub
• 设置节点亲和性，确保组件部署到正确的节点类型
• 调整启动参数，确保与 yurt-hub 的兼容性

方案二：yurt-hub 数据过滤

通过配置 yurt-hub 的 ConfigMap，让 Cilium 也能受益于端点过滤功能：

apiVersion: v1
data:
  servicetopology: cilium,cilium-agent
kind: ConfigMap

这种方法无需拆分 Cilium 组件，但需要确保：

• yurt-hub 已正确配置服务拓扑功能
• Cilium 组件能够正确处理过滤后的端点信息

实施步骤详解

环境准备

1. 确保 Kubernetes 版本 ≥ 1.21（无需特别处理 EndpointSlice）
2. 配置 kube-proxy 使用集群内设置连接 yurt-hub
3. 确认 yurt-hub 和 yurt-manager 正常运行
4. 创建节点池并将节点加入相应池中

测试验证

1. 创建带有拓扑注解的服务：

apiVersion: v1
kind: Service
metadata:
  annotations:
    openyurt.io/topologyKeys: openyurt.io/nodepool
  name: busy-box-svc
spec:
  ports:
  - port: 3000
    targetPort: 3000
  selector:
    app: busy-box

2. 使用 YurtAppSet 创建工作负载，分布在多个节点池

3. 验证流量行为：

• 宿主机上 telnet ClusterIP 应实现节点池内闭环
• 容器内访问应同样遵循拓扑规则

技术原理深入

OpenYurt 流量拓扑机制

OpenYurt 通过以下组件协同工作实现流量拓扑：

1. yurt-hub：过滤端点信息，只返回本节点池的端点
2. kube-proxy：基于过滤后的端点生成 iptables 规则
3. 节点池标签：提供拓扑域划分依据

Cilium 的特殊性

Cilium 的 eBPF 数据平面带来以下特性：

1. 直接处理服务流量，绕过 kube-proxy
2. 维护自己的服务映射表
3. 需要特殊处理才能感知拓扑限制

最佳实践建议

1. 对于混合环境：

• 云端节点使用标准 Cilium 组件
• 边缘节点使用改造后的 cilium-edge

2. 监控与调试：

• 使用 cilium-dbg service list 验证服务端点
• 检查 yurt-hub 日志确保过滤正常
• 对比不同节点的端点视图

3. 性能考量：

• eBPF 转发效率高于 iptables
• 端点过滤减少了边缘节点的数据量
• 需要平衡控制平面和数据平面的开销

总结

通过本文介绍的两种方案，我们成功在 OpenYurt 的 Cilium-CNI 环境中实现了节点池级别的流量拓扑功能。这种集成既保留了 Cilium 强大的网络策略和观测能力，又满足了边缘场景下流量闭环的核心需求，为构建高效、可靠的边缘计算平台提供了重要基础。

实际部署时，建议根据集群规模和性能需求选择合适的方案。对于大规模边缘集群，方案二的统一过滤机制可能更为简洁；而对于需要精细化控制的场景，方案一的组件拆分提供了更大的灵活性。