pathType 是什么
Ingress 里每条 path 规则都必须声明 pathType，它决定控制器用什么方式把请求路径与 path 对齐。Prefix 按 / 分隔的路径元素逐段匹配，Exact 要求路径完整相等且大小写敏感，ImplementationSpecific 则把解释权交给具体控制器实现。它直接决定「哪些请求进哪个后端」，写错会出现本该走 v2 的流量被打到 v1，而且不报任何错。
取值与匹配规则
| 取值 | 匹配规则 | 示例说明 |
|---|---|---|
| Prefix | 按 / 分隔的路径元素逐段匹配，不跨元素边界 | path: /api 命中 /api、/api/v1，不命中 /apiv2 |
| Exact | 路径完全相等且区分大小写 | path: /health 只命中 /health，不命中 /healthz |
| ImplementationSpecific | 由控制器自行解释，行为随实现变化 | nginx 控制器可配合正则注解实现 /users/数字 |
典型使用场景
- 按前缀拆分应用：/api 交给后端服务、/static 交给静态资源服务，用 Prefix 覆盖子路径
- 健康检查与探活入口：/health 用 Exact 暴露给外部拨测，避免被前缀规则捕获到其他后端
- 灰度与版本路由：/v2 用 Prefix 指向新版本工作负载，回退时只改一条规则
- 多域名收敛：同一 Ingress 里用 host 分域名、path 分路径，减少对象数量
- 迁移旧网关规则：旧系统里的正则路径用 ImplementationSpecific 承接，同时记录控制器依赖
多路径示例
多路径示例
spec:
rules:
- host: api.example.com
http:
paths:
- path: /api
pathType: Prefix # 命中 /api 及其子路径
backend:
service:
name: api
port: {number: 8080}
- path: /health
pathType: Exact # 只命中 /health 本身
backend:
service:
name: api
port: {number: 8080}核对实际生效规则
核对实际生效规则
kubectl get ingress web -o yaml | grep -A6 'paths:' # 确认 pathType 与 path 成对出现
kubectl describe ingress web | sed -n '/Rules:/,/Annotations:/p' # 看控制器解析后的路由表
kubectl -n ingress-nginx logs deploy/ingress-nginx-controller --tail=30 | grep -i error # 规则冲突会在此报错
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: api.example.com' http://<入口IP>/api/v1 # 实测命中情况匹配边界对照
| 请求路径 | path: /api 且 Prefix | path: /api/ 且 Prefix |
|---|---|---|
| /api | 命中 | 不命中（少一个元素分隔） |
| /api/v1 | 命中 | 命中 |
| /apiv2 | 不命中 | 不命中 |
| /api/ | 命中 | 命中 |
| /Api/v1 | 视控制器大小写处理，通常不命中 | 同上 |
优先级由控制器实现决定。ingress-nginx 中长前缀优先、Exact 优先于 Prefix，因此 /api/v1 的规则会盖住 /api；不同控制器（Traefik、HAProxy Ingress 等）排序规则并不一致，跨控制器迁移前要逐条实测。
Prefix 的语义是路径元素前缀，不是字符串前缀：这是最常被误解的一点，/api 不会命中 /apiv2，但会命中 /api/v2 与 /api/。