External-DNS 在 Gateway API 中处理 HTTPRoute 状态不一致问题分析

问题背景

在 Kubernetes 网关生态系统中，External-DNS 作为自动管理 DNS 记录的关键组件，与 Gateway API 深度集成。近期发现一个值得注意的现象：当 HTTPRoute 资源的 parentRefs 字段更新时，External-DNS 会同时为旧网关和新网关创建 DNS 记录，导致 DNS 记录重复问题。

问题现象

具体表现为：当用户修改 HTTPRoute 资源中的 spec.parentRefs 字段，将网关引用从"external"改为"internal"后，External-DNS 不会如预期那样更新 DNS 记录，而是同时保留新旧两条记录。即使手动删除 DNS 记录，External-DNS 仍会重新创建这两条记录。

根本原因分析

通过深入分析 HTTPRoute 资源的状态字段(status)，我们发现问题的根源在于 External-DNS 的处理逻辑：

1. 状态与规格不一致：HTTPRoute 的 status.parents 字段会保留所有历史网关引用状态，而不仅仅是当前有效的引用
2. 缺乏世代检查：External-DNS 没有验证 status.parents 中的条件(conditions)是否与当前资源世代(metadata.generation)匹配
3. 过时状态处理：网关控制器可能不会立即清理过时的状态条目，导致 External-DNS 看到多个"有效"的网关引用

技术细节

HTTPRoute 的状态字段会记录所有曾经关联过的网关信息，每个条目都包含：

• 网关引用详情(name/namespace等)
• 状态条件(conditions)
• 观察到的世代(observedGeneration)

关键问题在于 External-DNS 的网关源(gateway source)实现没有检查 observedGeneration 是否与当前资源世代匹配，导致它处理了已经过时的网关引用。

解决方案

针对这一问题，社区提出了明确的修复方案：

1. 世代验证机制：在处理每个 status.parents 条目时，应先验证其 observedGeneration 是否等于当前资源的 metadata.generation
2. 日志增强：对于跳过的过时条目，应记录详细的调试信息，方便问题排查
3. 状态过滤：只处理那些世代匹配的网关引用，确保 DNS 记录与当前配置严格一致

修复代码的核心逻辑是添加世代检查，示例实现如下：

for _, rps := range rt.RouteStatus().Parents {
    if rps.Conditions[0].ObservedGeneration != meta.Generation {
        continue
    }
    // 正常处理逻辑...
}

临时解决方案

对于遇到此问题的用户，目前可采用的临时解决方案是：

1. 完全重建资源：删除并重新创建 HTTPRoute 资源，而非直接修改
2. 手动清理：在修改网关引用后，手动删除旧的 DNS 记录
3. 版本降级：回退到不受此问题影响的 External-DNS 版本

最佳实践建议

基于此问题的经验，我们建议在使用 Gateway API 与 External-DNS 集成时：

1. 监控 DNS 记录：建立对异常多记录情况的监控告警
2. 变更验证：修改网关引用后，验证 DNS 记录是否符合预期
3. 版本选择：关注 External-DNS 的版本更新，及时应用修复此问题的版本

总结

这个问题揭示了 Kubernetes 控制器在处理资源状态时的复杂性，特别是当多个控制器共同管理同一资源时。通过理解资源状态与规格的关系，以及控制器间的交互机制，我们可以更好地设计和实现可靠的云原生基础设施组件。对于 External-DNS 用户而言，了解这一问题的本质有助于更有效地使用 Gateway API 集成功能。