Argo Rollouts 在 HTTPS 环境下的 Canary 服务流量路由问题解析

问题背景

在 Kubernetes 环境中使用 Argo Rollouts 进行渐进式交付时，当服务需要 HTTPS 协议支持时，会出现一个关键问题：通过 Ambassador 进行流量路由时，生成的 Canary 服务映射文件会丢失原有的 HTTPS 协议前缀。

技术细节分析

在标准的 Argo Rollouts Canary 部署策略中，当配置了 Ambassador 作为流量路由器时，系统会基于稳定版本的 Mapping 配置自动创建一个 Canary 版本的 Mapping。问题出在这个自动创建的过程中，系统直接将稳定服务的 Mapping 中的 spec.service 值替换为 Rollout 资源中定义的 canaryService 名称，而没有保留原有的协议前缀（如 https://）。

影响范围

这个问题主要影响以下场景：

1. 使用 HTTPS 协议的后端服务
2. 采用 Ambassador 作为流量路由器的 Argo Rollouts 部署
3. 使用 Canary 发布策略进行渐进式交付

解决方案

从技术实现角度看，解决方案需要修改 Argo Rollouts 的 Ambassador 流量路由逻辑，使其在克隆 Mapping 配置时能够：

1. 识别原始 Mapping 中的协议前缀
2. 在生成 Canary Mapping 时保留这个协议前缀
3. 仅替换服务名称部分

最佳实践建议

对于遇到此问题的用户，在官方修复发布前可以考虑以下临时解决方案：

1. 使用自定义的 Mapping 模板，明确指定 Canary 服务的完整 URL（包含协议）
2. 考虑使用注解或其他元数据来标记需要保留协议的服务
3. 在 CI/CD 流程中添加后处理步骤，自动修正生成的 Canary Mapping

技术实现考量

从架构设计角度看，这个问题反映了流量路由组件在处理协议感知服务时需要更加智能。理想的实现应该：

1. 解析原始服务地址时区分协议、主机和端口
2. 提供配置选项允许用户指定是否保留协议
3. 考虑支持多种协议类型（HTTP、HTTPS、gRPC等）

总结

Argo Rollouts 作为一款强大的渐进式交付工具，在复杂网络环境下的协议支持方面仍有改进空间。这个特定的 HTTPS 协议支持问题提醒我们，在实际生产环境中部署时，需要全面考虑网络协议栈的各个层面，确保流量路由的准确性和完整性。