Kubernetes External-DNS与OpenStack Designate集成时的HTTPS协议问题解析

问题背景

在使用Kubernetes External-DNS组件(v0.14.1)与OpenStack Designate(DNS服务)集成时，发现组件尝试通过HTTP协议访问HTTPS端点。具体表现为：当查询记录集(recordsets)时，External-DNS向Designate发送了HTTP请求而非预期的HTTPS请求，导致连接失败。

现象分析

从日志中可以看到两个关键现象：

1. 服务发现阶段成功识别了HTTPS端点("Found OpenStack Designate service at https://srv01.loutres.internal:9001/")
2. 实际查询记录集时却使用了HTTP协议("Get "http://srv01.loutres.internal:9001/v2/zones/...")

通过WireShark抓包确认，确实存在HTTP明文请求。值得注意的是，获取zone列表的请求是正常的HTTPS连接，只有查询recordsets时出现了协议降级。

根本原因

深入调查后发现，这个问题源于OpenStack Designate服务的分页响应机制。当查询结果需要分页时，Designate会在响应中包含下一页的URL。在这个案例中：

1. 环境中存在SSL代理中间层
2. Designate服务返回的分页URL被代理改写为HTTP协议
3. External-DNS直接使用这个URL发起后续请求

解决方案

最终解决方案是：

1. 移除SSL代理中间层
2. 直接在Designate服务上配置SSL/TLS
3. 确保Designate生成的分页URL保持HTTPS协议

经验总结

在云原生环境中集成不同组件时，需要特别注意：

1. 端到端的协议一致性，特别是存在代理或负载均衡时
2. 服务返回的URL应该与原始请求保持相同协议
3. 对于分页API，要验证后续请求的URL是否符合预期

这个问题虽然表现为External-DNS的行为异常，但根源在于基础设施配置。这也提醒我们在排查类似问题时，需要全面考虑整个调用链路的各个环节。