Cilium Agent启动时高开销的CiliumEndpoint列表查询问题分析

在Cilium网络方案的实际生产部署中，我们发现了一个影响大规模集群稳定性的性能问题：当Cilium Agent启动时，会向Kubernetes API Server发起两个代价高昂的CiliumEndpoint全量列表查询请求。这个问题在v1.16.8至v1.17.0之前的版本中存在，尤其对拥有上万个端点的集群影响显著。

问题现象

通过监控数据可以观察到，Agent启动时会向API Server发起以下请求：

/apis/cilium.io/v2/ciliumendpoints?limit=500&resourceVersion=0

这种请求有两个关键特征：

1. 设置了resourceVersion=0参数
2. 虽然指定了limit=500的分页限制，但实际上会被API Server忽略

在大型集群中，这类请求会导致：

• API Server负载急剧上升
• 请求延迟显著增加（从正常的毫秒级上升到秒级）
• 大规模Agent滚动更新时可能引发API Server过载

技术背景

CiliumEndpoint是Cilium用来跟踪和管理网络端点状态的CRD资源。在KVStore模式下，理论上Agent应该只从etcd等键值存储中获取端点信息，但实际代码中存在两个会触发全量CEP列表查询的逻辑路径。

根本原因分析

原因一：过早的CEP Watcher初始化

在k8s/watchers/cilium_endpoint.go中，CEP Watcher作为KVStore不可用时的回退机制被预先启动。这个设计存在两个问题：

1. 在KVStore模式启用时，这个回退机制实际上是不必要的
2. Watcher初始化时会立即执行全量列表操作，而不等待KVStore连接状态确认

原因二：端点清理机制的全量扫描

endpointcleanup组件负责清理与已不存在Pod关联的CEP对象。该组件在启动时会扫描集群中所有CEP资源，而不考虑节点本地性。

分页失效机制

Kubernetes客户端默认配置会导致分页失效：

• limit=500是client-go的默认值
• resourceVersion=0会使API Server忽略分页限制
• 这种组合导致无论集群规模多大，都会获取全量数据

解决方案

该问题已在后续版本中通过以下改进得到解决：

1. 延迟CEP Watcher的初始化，仅在确认KVStore不可用时才启用
2. 优化端点清理逻辑，减少不必要的全量扫描
3. 改进列表查询的参数设置，确保分页机制生效

运维建议

对于仍在使用受影响版本的用户，可以考虑以下临时缓解措施：

1. 评估是否真正需要--disable-endpoint-crd=false参数
2. 考虑禁用--enable-stale-cilium-endpoint-cleanup选项（需评估CEP泄漏风险）
3. 在大型集群中，避免大规模同时重启Agent

架构思考

这个案例反映了分布式系统设计中几个值得注意的原则：

1. 回退机制应该是有条件触发的，而不是预先执行的
2. 全量列表操作在大规模系统中应该尽量避免
3. 默认参数配置需要针对大规模场景进行特别考虑

通过这个问题的分析和解决，Cilium在大型集群中的稳定性和性能得到了显著提升，特别是在API Server负载敏感的环境中。