AKS单集群多命名空间下Ingress路由MVC应用异常咨询

该场景下的架构选型不存在本质错误：个人学习、技术PoC阶段用命名空间做环境隔离、单Ingress实例做流量拆分是性价比极高的选择，Ingress完全可以支撑这类环境分流需求。当前出现的路由404、跳转丢前缀、静态资源加载异常问题，和Ingress本身的能力边界无关，核心是路径前缀的处理逻辑没有在Ingress层和应用侧对齐。

添加nginx.ingress.kubernetes.io/rewrite-target: /注解后，Ingress会将所有/dev开头的请求路径直接剥离前缀，转发给开发环境的MVC应用。但MVC应用本身未感知到自己被挂载在/dev子路径下，生成的页面跳转链接、静态资源引用默认都以根路径/为基准，因此点击按钮、加载CSS/JS时请求会直接打到根路径对应的生产环境，和预期路由逻辑冲突。

按推荐优先级从高到低排列：

方案1：子域名做环境分流（首推，维护成本最低） #

这是业界通用的环境分流方案，可完全规避子路径路由带来的重写、前缀适配问题：

• 为开发环境分配独立二级域名，例如dev.09ab799fd5674c4594a5.centralus.aksapp.io，生产环境继续使用原有根域名
• 调整Ingress规则，直接基于host字段做流量匹配，无需配置任何路径重写规则：
  • 访问根域名的请求全部转发到生产环境对应Service
  • 访问dev二级域名的请求全部转发到开发环境对应Service
• 该方案下MVC应用不需要做特殊适配，所有链接、静态资源都基于当前域名的根路径生成，不会出现前缀丢失问题。后续新增测试、预发等环境时，仅需新增一条host对应规则即可，扩展成本极低。
  如果使用AKS自带的应用路由插件，配置完host规则后会自动完成DNS解析和证书签发，无需手动操作DNS资源。

方案2：保留子路径路由，对齐Ingress与应用配置 #

如果需要保留/dev子路径的分流方式，必须同时修改Ingress和应用侧配置，仅调整任意一端都无法彻底解决问题：

1. 修正Ingress重写规则，不要直接将所有/dev路径重写到根路径，改用正则捕获组保留路径后缀：

   annotations:
     nginx.ingress.kubernetes.io/rewrite-target: /$2
   rules:
     - host: 09ab799fd5674c4594a5.centralus.aksapp.io
       http:
         paths:
           - path: /dev(/|$)(.*)
             pathType: Prefix
             backend:
               service:
                 name: dev-env-svc
                 port:
                   number: 80
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: prod-env-svc
                 port:
                   number: 80
   

   该配置会将/dev/home/index类请求转为/home/index转发给后端，/dev/css/site.css转为/css/site.css转发，避免后端收到不存在的路径。
2. 为MVC应用配置虚拟路径根目录，让应用感知到自己运行在/dev前缀下：
   • 若使用ASP.NET Core MVC，直接在启动配置中添加app.UsePathBase("/dev")，框架会自动为所有生成的路由链接、静态资源引用加上/dev前缀
   • 其他主流MVC框架（Spring MVC、Django、Rails等）均提供上下文路径/应用根路径配置项，配置后即可自动生成带前缀的链接。

方案3：Ingress层做响应内容替换（仅临时验证用，不推荐长期使用） #

可以通过Ingress的sub_filter配置，对开发环境返回的HTML内容做字符串替换，将所有href="/、src="/类的根路径引用前自动插入/dev前缀。但该方案缺陷极多：JS动态拼接的路径、接口返回的跳转地址、非HTML类型的资源引用都无法被正确替换，长期运行必然出现各类诡异的路由问题，仅适合临时调试使用。

• 当前通过default命名空间部署Ingress、用ExternalName Service跨命名空间指向后端服务的实现是可行的，新版Nginx Ingress已经支持直接在Ingress规则中通过service.namespace字段指定后端服务所在的命名空间，不需要额外创建ExternalName资源，可简化配置。
• 针对开发环境占满集群资源的隐患，仅需给dev命名空间添加ResourceQuota资源，限制命名空间可使用的最大CPU、内存、Pod数量即可，无需搭建多集群。
• Ingress除host、路径维度的流量分流外，还支持基于权重、请求头、Cookie等维度的流量拆分，完全可以满足个人学习场景下的各类流量路由需求，不存在能力不足的问题。

内容的提问来源于stack exchange，提问作者Matthias Müller