Ingress资源本身不跨命名空间生效，需通过Ingress Controller全局监听、ExternalName Service间接引用或AGIC多命名空间模式实现多命名空间路由共享。
Kubernetes Ingress 本身不跨命名空间生效——Ingress 资源必须和它所路由的 Service 在同一个命名空间内。但“多命名空间路由共享”在实践中是常见需求，比如多个团队（dev/staging/prod）共用一个公网入口、同一域名下不同路径分发到不同命名空间的服务。这并非靠 Ingress 自身突破命名空间限制，而是通过 Ingress Controller 的能力 + 合理配置来实现。
以下是三种主流、稳定、生产可用的方式：
方式一：Ingress Controller 全局监听，Ingress 资源按需分散部署
这是最常用也最推荐的做法，适用于 Nginx、AGIC、Traefik 等主流控制器。
- Ingress Controller（如 nginx-ingress-controller）以集群范围（ClusterScope）运行，能监听所有命名空间的 Ingress 资源
- 每个命名空间各自定义自己的 Ingress 对象，只要
spec.rules[].http.paths[].backend.service.name指向本命名空间内的 Service 即可 - 若需将不同命名空间的 Service 暴露在同一个域名下，只需确保它们的 Ingress 规则不冲突（例如用不同 path 或 host）
例如：
-
namespace: staging 定义 Ingress：
host: app.example.com, path: /api → service: api-svc (port: 80) -
namespace: prod 定义 Ingress：
host: app.example.com, path: /web → service: web-svc (port: 80)
只要两个 Ingress 都标注了 kubernetes.io/ingress.class: nginx，且 nginx-ingress-controller 已启用全命名空间监听（默认行为），它就会自动聚合规则，统一处理流量。
方式二：使用 ExternalName Service 跨命名空间引用（间接共享）
当某个 Service 必须被其他命名空间的 Ingress 路由时，可在目标命名空间中创建一个指向它的 ExternalName Service。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
步骤：
- 假设 prod 命名空间有个
payment-svc，你想让 staging 的 Ingress 也能路由到它 - 在 staging 中创建 Service：
apiVersion: v1
kind: Service
metadata:
name: payment-proxy
spec:
type: ExternalName
externalName: payment-svc.prod.svc.cluster.local
ports:
- port: 80 - 再在 staging 的 Ingress 中引用
payment-proxy这个 Service
⚠️ 注意：ExternalName 不支持端口重映射，且部分 Ingress Controller（如老版本 nginx）对它的后端健康检查支持有限，建议搭配 readinessProbe 使用。
方式三：AGIC（Azure Application Gateway Ingress Controller）多命名空间模式
如果你用的是 Azure AKS + Application Gateway，AGIC 从 v0.7 起原生支持多命名空间观察。
关键配置在 helm-config.yaml：
- 删掉或设空
watchNamespace→ 监听全部命名空间 - 或显式列出：
watchNamespace: "default,staging,prod" - AGIC 会自动扫描这些命名空间下的 Ingress，并过滤带
kubernetes.io/ingress.class: azure/application-gateway的资源 - 冲突处理：相同 host+path 会被拒绝；相同 host 不同 path 可共存；TLS 证书若重复，AGIC 会去重复用
补充说明：什么不能做？
以下操作是无效或不被支持的：
- Ingress 的
spec.rules[].http.paths[].backend.service.name写成other-ns/service-name—— Kubernetes API 会直接拒绝创建 - 试图让一个 Ingress 资源同时路由到多个命名空间的 Service —— Ingress 设计上就是命名空间本地资源
- 依赖 kube-proxy 或 ClusterIP 实现跨 ns Ingress 路由 —— 它们只管四层转发，不解析 HTTP Host/Path
本质上，Ingress 多命名空间路由共享，靠的不是“打破隔离”，而是让隔离的资源，在统一入口层被协调调度。控制器是枢纽，Ingress 是声明，Service 是锚点——三者配合，自然达成共享效果。
