01
一起提供关联资源
用 --- 分隔 Ingress、Service 和可选的 Deployment 或 Pod。Ingress 只能引用同命名空间的 Service，跨命名空间同名对象不会被错配。
Kubernetes / Helm
Ingress 路径匹配检查
粘贴已渲染的 YAML，输入一条请求的 Host 和路径，查看静态路由链。
Ingress 路径匹配检查
路由报告
粘贴已渲染的清单，或载入示例。
仅在浏览器本地分析；不连接集群或发送 HTTP 请求。
请求设置
Exact 与 Prefix 按 Kubernetes 规则匹配；不模拟控制器特有路径。
上限：300,000 个字符、100 个资源、500 条路径。
粘贴已渲染的清单，或载入示例。
Ingress 规则看起来命中了，后端却可能引用了不存在的 Service 端口。排查这类配置时，Ingress 路径匹配检查能把一条请求逐段展开。
报告区分标准规则命中、确定断链和缺少运行证据。它不发送网络请求，线上连通性仍需到集群核实。
为什么使用 Ingress 路径匹配检查？
沿一条请求追踪到目标端口
Ingress 路径匹配检查先按最长路径与 Exact 优先规则选路，再查 Service port 如何映射到 targetPort。这样能解释 /api/orders 到底落在哪条规则上。
把断链与未知分开
Ingress 后端引用了 Service 不存在的端口时，报告会明确指出断点；未提供 Pod 清单时则只说明证据不足，不把它误判为故障。
改动清单前先读懂路由
02
指定具体请求
默认路径是 /；可改为 /api/orders 等路径。有 Host 的规则需要输入请求 Host；留空时只能检验无 Host 规则。
03
辨认报告的证据级别
“命中”只说明静态规则可解析；“断链”指出引用缺失；“不确定”表示控制器可能改变行为。修改输入后须重新检查才能复制。
从路径规则查到后端端口
按 Kubernetes 路径规则选路
Ingress 路径匹配检查支持 Exact、按路径段判断的 Prefix、精确 Host 与单级通配 Host。/api 不会误匹配 /apix。
逐段核对端口
Service 端口与 targetPort 在报告中分别显示。Ingress 后端须先指向 Service 的 port 或端口名，再由 Service 映射到 Pod 目标端口。
补充工作负载线索
提供 Deployment 模板或 Pod 后，会比较 Service selector 与标签；没有这些对象时显示“未知”，不声称 Pod 已就绪。
静态检查的边界
- 控制器规则不作确定结论
- ImplementationSpecific、正则及路径重写注解由具体控制器解释。Ingress 路径匹配检查会标记不确定，不假装已模拟实际选路。
- 没有真实流量探测
- Ingress 404 排查还需查看控制器日志、DNS、EndpointSlice 和真实响应。本页只读本地 YAML，静态命中不能证明应用可访问。
- 未提供工作负载不算断链
- Service 可以选中未粘贴的 Pod，也可能使用手工端点；缺少工作负载清单只意味着无法核实。真正缺少引用的 Service 或端口才报断链。
- 输入范围明确
- 最多处理 300,000 个字符、100 个资源和 500 条路径；只检查已渲染的 networking.k8s.io/v1 Ingress 与 v1 Service，不解析 Helm 模板或 Gateway API。
Ingress 路径匹配检查常见问题
Ingress 的 Prefix 路径会匹配 /foo-bar 吗？
Prefix 按 / 分隔的路径段匹配：/foo 可匹配 /foo/bar，但不会匹配 /foo-bar；路径还区分大小写。
Ingress 后端端口应该填 Service port 还是 targetPort？
Ingress 后端要填写 Service 的 port 数值或端口名。Service 再将这个端口映射到 targetPort；直接填 Pod 端口可能找不到 Service 端口。
请求主机名不匹配时会走哪个后端？
若 Host 或路径不符合规则，可能进入默认后端；没有默认后端时则由控制器处理。本工具报告静态选路，不推断具体 HTTP 状态码。
为什么 Ingress 路径配置后仍然返回 404？
404 可能来自 Host/Path 不匹配、默认后端、路径重写或应用自身。先看静态报告，再用控制器日志和真实请求定位来源。
只看 YAML 能确认 Pod 一定可达吗？
不能。YAML 只能说明配置关系，无法证明控制器运行、Pod Ready、DNS、EndpointSlice 或网络策略的实时状态。
还有路由问题？