Azure Cloud Service Web角色微服务迁移至AKS的Windows容器联网配置咨询

两类适配方案的落地性判断 #

方案1：容器复用主机nginx完成流量路由 #

该方案完全可行，且是适配现有架构约束的最优选择

• 核心实现逻辑完全匹配现有环境约束：
  • 所有域名解析规则的变更仅作用于容器内部，完全不触碰主机hosts、Azure托管DNS的现有配置，也不修改主机上正在运行的nginx对Azure Emulator的原有路由逻辑，主机上的旧版Web Role应用的访问链路不会受任何影响。具体实现可在docker-compose配置中通过extra_hosts字段，将所有业务域名（myapp.mydomain.dev、identity.mydomain.dev、api.mydomain.dev）的指向，调整为Windows容器NAT网络对应的宿主机网关地址（通常为172.25.0.1，可通过docker network inspect nat命令查询确认）。容器内部对这些域名的请求会直接路由到宿主机的网络接口，到达运行在宿主机上的nginx服务。
  • 无需调整主机nginx的现有路由规则，仅需在现有配置块中新增对应当前docker-compose服务的端口映射即可。由于容器发起的请求携带完整的原始Host头（即原业务域名），nginx现有的按域名匹配路由的逻辑可直接生效，将流量转发到对应容器映射到宿主机的端口，完全满足OAuth2/OIDC对完整调用URL、重定向URL的校验要求。
• 避坑提示：不要给Windows容器直接配置host网络模式共享宿主机回环，该模式下容器会直接占用宿主机的端口空间，容易和现有Azure Emulator的预留端口产生冲突，反而破坏新旧环境共存的稳定性。

方案2：容器内置nginx完成域名别名路由 #

该方案技术上可跑通，但长期维护成本极高，不推荐作为长期适配方案

• 可实现的基础逻辑：在每个Windows容器启动时，通过容器内的nginx配置添加对应业务域名的路由规则，将请求转发到docker-compose网络内其他容器的动态IP，实现不依赖固定IP的域名互通。
• 存在的硬伤：
  • docker-compose默认网络的容器IP为动态分配，每次容器重启后IP可能变更，内置的nginx配置无法自动感知IP变化，需要额外嵌入服务发现逻辑才能保持路由有效性，开发复杂度陡增。
  • 集中式SSL offloading的优势完全丢失：所有容器需要单独分发SSL证书，证书轮转时需要同步修改所有容器的nginx配置，运维成本远高于集中在宿主机统一管理证书的模式。
  • OAuth2校验存在隐蔽故障风险：容器内部的nginx转发请求时如果未正确传递原始Host头，会导致IdP服务校验重定向URL时出现域名不匹配的错误，排障难度远高于集中式路由的模式。
  • 与现有Azure Emulator环境共存的配置复杂度极高：需要在每个容器的nginx中额外配置规则，将指向旧版Web Role服务的流量转发回宿主机的nginx入口，本质是将宿主机nginx的路由逻辑完全复制到每一个容器中，没有任何架构上的简化。

AKS生产环境的同类问题预判 #

生产环境不会出现本地开发环境的回环解析故障，但需要对齐等效的域名路由逻辑

• 不会触发同类故障的核心原因：本地环境的解析问题根源是Azure DNS将业务域名指向127.0.0.1，而AKS生产环境中，所有业务域名的Azure DNS记录指向的是应用网关（实现SSL offloading的统一入口）的可路由地址，不存在指向回环地址的配置，因此从根源上避免了容器内解析到自身回环、导致路由失败的问题。
• 生产环境需要提前适配的等效配置：
  • 为保持OAuth2/OIDC对完整业务域名的要求，可在AKS中配置内部私有DNS区域，将所有业务域名（myapp.mydomain.dev、identity.mydomain.dev、api.mydomain.dev）指向内部应用网关的IP地址。这样所有集群内的Pod发起的带完整域名的服务间调用，都会统一走到应用网关完成SSL卸载、路由转发，和本地开发环境的nginx逻辑完全对齐，不需要修改应用侧的硬编码调用URL。
  • 集群内CoreDNS默认配置不会出现将业务域名解析到容器自身回环的问题，只要不手动配置错误的hosts映射、不将生产环境的DNS记录指向回环地址，就不会出现和本地开发环境一致的解析类故障。

内容的提问来源于stack exchange，提问作者James Legan