Cilium Gateway API 中 TLSRoute CRD 缺失导致的问题分析

在 Kubernetes 网络领域，Cilium 作为一款基于 eBPF 技术的高性能网络方案，其 Gateway API 实现为服务网格提供了强大的入口流量管理能力。然而，近期社区报告了一个值得注意的问题：当集群中未安装实验性 TLSRoute CRD 时，即使仅使用 HTTP 路由功能，Cilium 的网关控制器也会出现故障。

问题现象

用户在使用 Cilium 1.17.2 及以上版本时发现，当仅安装标准通道的 Gateway API CRD（不包含 TLSRoute）并创建基于 cilium GatewayClass 的网关资源时，会出现以下异常情况：

1. 网关状态持续显示为"Waiting for controller"
2. 控制器日志中报错"Unable to list TLSRoutes"
3. 网关资源无法正常分配地址和进入可用状态

技术背景

Gateway API 是 Kubernetes 官方推出的下一代入口流量管理标准，相比传统的 Ingress 资源提供了更丰富的路由能力和更清晰的职责分离。Cilium 作为实现者之一，通过其控制平面组件提供了完整的 Gateway API 支持。

标准通道的 Gateway API CRD 包含 GatewayClass、Gateway、HTTPRoute 等核心资源，而 TLSRoute 等高级功能目前仍处于实验阶段，需要单独安装实验性 CRD 包。

问题根源分析

通过代码审查发现，问题出在 Cilium 操作器的网关协调逻辑中。无论用户是否实际使用 TLS 路由功能，控制器都会尝试列出集群中的所有 TLSRoute 资源：

// 网关协调逻辑片段
tlsRouteList := &v1alpha2.TLSRouteList{}
if err := r.Client.List(ctx, tlsRouteList); err != nil {
    return fmt.Errorf("Unable to list TLSRoutes: %w", err)
}

这段代码存在两个关键问题：

1. 缺乏条件检查：没有先验证 TLSRoute CRD 是否已安装就直接尝试操作
2. 错误处理不足：当 CRD 不存在时返回的错误导致整个协调过程中断

解决方案与最佳实践

目前社区已提出以下解决方案：

1. 临时解决方案：安装实验性 CRD 包，包含 TLSRoute 资源定义
2. 根本解决方案：修改协调逻辑，优雅处理 CRD 不存在的情况

对于生产环境，建议采取以下最佳实践：

1. 即使不使用 TLS 路由功能，也安装完整的实验性 CRD 包以确保兼容性
2. 关注 Cilium 版本更新，该问题预计在后续版本中得到修复
3. 在 Helm 部署时明确设置 gatewayAPI.gatewayClass.create=true 确保必要资源就绪

技术启示

这一案例为我们提供了几个重要的技术启示：

1. API 兼容性设计：控制器应对可选依赖进行健壮性处理
2. 文档准确性：功能文档应明确标注隐式依赖关系
3. 渐进式功能发布：实验性功能与稳定功能的隔离需要更清晰的边界

随着 Cilium 在服务网格领域的深入应用，这类边界条件问题的处理将变得越来越重要，也体现了云原生网络组件在复杂环境下的健壮性挑战。