Kubernetes External-DNS 同步模式下 DNS 记录管理问题解析与解决方案

问题背景

在使用 Kubernetes External-DNS 进行 DNS 记录管理时，用户发现当 Kubernetes 资源（如 Service 或 Ingress）被删除或更新时，对应的 DNS 记录未能被正确清理或更新。具体表现为：

1. 删除 Kubernetes Service 或 Ingress 后，DNS 记录仍然存在
2. 更新 Kubernetes Service 或 Ingress 时，会创建新的 DNS 记录而非更新现有记录
3. 手动删除 DNS 记录后，External-DNS 会在下次同步时重新创建

环境配置

用户使用的是 External-DNS v0.14.0 版本，通过 RFC2136 协议与 PowerDNS 集成。主要配置参数包括：

• 同步策略设置为 sync
• 数据源为 ingress 和 service
• 使用注解过滤器 managed.by=external-dns
• 设置了 TXT 记录的所有者标识和前缀

问题分析

从日志分析可以看出，External-DNS 只执行了创建操作（Create），而没有触发更新（Update）或删除（Delete）操作。这表明系统在计算 DNS 记录变更计划时，未能正确识别需要删除或更新的记录。

深入分析后发现，问题的根本原因在于 AXFR（区域传输）功能未正确配置：

1. External-DNS 需要 AXFR 功能来获取当前 DNS 区域的完整记录集
2. 只有通过 AXFR 获取当前状态，才能准确计算需要删除或更新的记录
3. 用户最初配置的 TSIG 密钥仅具有 DYNUPDATE 权限，缺少 AXFR 权限

解决方案

要解决此问题，需要进行以下配置调整：

1. TSIG 密钥配置：

   • 为 TSIG 密钥添加 AXFR 权限
   • 确保密钥具有足够的权限执行区域传输操作

2. External-DNS 配置：

   • 启用 rfc2136-tsig-axfr 标志
   • 确保 External-DNS 能够执行完整的区域传输

配置示例：

args:
- --rfc2136-tsig-axfr=true
- --policy=sync
- --source=ingress
- --source=service

实现原理

External-DNS 的工作流程大致如下：

1. 收集期望状态：从 Kubernetes API 获取所有配置了相应注解的 Service 和 Ingress 资源
2. 获取当前状态：通过 DNS 提供商的 API 获取当前 DNS 记录
3. 计算差异：比较期望状态和当前状态，生成变更计划
4. 执行变更：根据变更计划创建、更新或删除 DNS 记录

当 AXFR 功能未启用时，External-DNS 无法准确获取当前 DNS 记录状态，导致无法正确计算需要删除或更新的记录。

最佳实践建议

1. 权限配置：

   • 确保 TSIG 密钥同时具有 DYNUPDATE 和 AXFR 权限
   • 遵循最小权限原则，仅授予必要的权限

2. 监控与日志：

   • 启用 External-DNS 的调试日志级别
   • 定期检查变更计划中的操作类型（Create/Update/Delete）

3. 测试验证：

   • 在非生产环境验证配置变更
   • 测试删除和更新操作是否按预期工作

总结

Kubernetes External-DNS 是一个强大的工具，可以自动管理 DNS 记录与 Kubernetes 资源的同步。然而，正确的配置是确保其正常工作的关键。通过启用 AXFR 功能并配置适当的权限，可以解决 DNS 记录删除和更新失败的问题，实现完整的 DNS 记录生命周期管理。

对于使用 RFC2136 协议与 PowerDNS 或其他 DNS 服务集成的场景，务必确保区域传输功能正确配置，这是 External-DNS 能够准确计算和执行 DNS 记录变更的基础。