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

问题背景

在Kubernetes集群中使用External-DNS组件与OpenStack Designate服务集成时，可能会遇到一个典型的协议兼容性问题：External-DNS尝试通过HTTP协议访问配置为HTTPS的Designate服务端点。这种现象通常表现为日志中出现类似"Failed to do run once: Get "http://endpoint:port/..."的错误信息，而实际服务端点配置为HTTPS协议。

问题现象分析

当External-DNS（v0.14.1版本）与OpenStack Designate服务集成时，系统会经历以下典型流程：

1. 成功通过HTTPS连接到Keystone身份服务（如https://srv01.loutres.internal:5000/v3/）
2. 正确发现Designate服务端点（显示为HTTPS协议）
3. 在获取zone信息时使用HTTPS协议成功连接
4. 但在获取recordsets记录集时意外降级为HTTP协议

通过抓包工具（如Wireshark）可以确认，实际网络请求确实使用了HTTP协议而非配置的HTTPS，这会导致连接被拒绝或返回EOF错误。

根本原因

经过深入分析，这个问题通常源于以下两种场景：

1. 中间代理配置问题：当OpenStack环境中存在SSL反向代理时，Designate服务返回的分页URL可能被改写为HTTP协议。这是因为某些代理配置会修改后端服务返回的链接，特别是在处理分页请求时。

2. 服务端点注册不一致：虽然OpenStack端点列表显示所有接口（admin/internal/public）都配置为HTTPS，但服务内部可能仍然生成HTTP链接。

解决方案

针对这个问题，推荐采用以下解决方案：

1. 直接HTTPS连接方案：

   • 在Designate服务端直接配置SSL/TLS支持
   • 移除中间的SSL代理层
   • 确保所有服务端点统一使用HTTPS协议

2. 代理环境适配方案：

   • 如果必须使用SSL代理，确保代理配置正确处理协议转换
   • 配置代理保留原始HTTPS链接
   • 检查X-Forwarded-Proto等HTTP头设置

最佳实践建议

1. 环境检查清单：

   • 使用openstack endpoint list命令验证所有服务端点协议
   • 检查Designate服务的API配置（/etc/designate/designate.conf）
   • 验证网络拓扑中的代理配置

2. 调试技巧：

   • 启用External-DNS的详细日志（--log-level=debug）
   • 使用tcpdump或Wireshark捕获实际网络流量
   • 检查Designate服务的访问日志

3. 版本兼容性：

   • 确保External-DNS版本与OpenStack版本兼容
   • 考虑升级到External-DNS最新稳定版本

经验总结

这个案例展示了在混合云环境中协议一致性维护的重要性。虽然问题最终发现是环境配置导致，但它提醒我们：

1. 中间代理可能引入意外的协议转换
2. 服务发现链中的每个环节都需要验证
3. 网络抓包是诊断此类问题的有效手段

对于OpenStack和Kubernetes集成环境，建议建立完整的协议审计机制，确保从服务注册到实际请求的整个链路保持协议一致性。