Ingress2Gateway 1.0 迁移前如何核对 Ingress 路由行为

Ingress2Gateway 1.0 适合做迁移前的“行为盘点器”，不适合被当成一键切换器。先用它把现有 Ingress 转成 Gateway API 候选资源，再逐项对照 host、path、后端、TLS、重写、正则和重定向；凡是出现 warning、未转换注解或实现相关差异，都要在测试集群里补验证。这样才能知道哪些路由能进入灰度，哪些必须人工改写。

官方地址：https://github.com/kubernetes-sigs/ingress2gateway

先把原 Ingress 规则拆成可核对的清单

不要直接从 YAML 的行数判断迁移难度。先按请求入口整理四组事实：域名和 TLS 证书、路径匹配类型、后端服务与端口、实现相关注解。对 ingress-nginx 来说，rewrite-target、use-regex、permanent-redirect、proxy-read-timeout、proxy-body-size 和 canary 注解都可能改变最终请求行为。

同时保留一组基线请求：正常路径、未匹配路径、重写前后路径、HTTP 到 HTTPS、带特殊 Header 的请求，以及超时和大请求体。每条请求记录状态码、Location、最终 Host、转发路径和后端服务，后面才能判断“资源看起来相似”是否真的等价。

用 1.0 生成候选 Gateway API 清单

官方 1.0 发布说明提供了文件输入、命名空间和全集群读取方式。迁移前建议先从脱敏后的导出文件开始，避免工具直接读取生产 kubeconfig。

# 使用 1.0.0 安装迁移助手\n go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0\n\n# 从脱敏清单生成 Gateway API 候选资源\n ingress2gateway print --input-file ingress.yaml --providers=ingress-nginx > gateway-candidate.yaml\n\n# 查看指定命名空间的候选结果；域名和文件名仅为示意\n ingress2gateway print --namespace demo --providers=ingress-nginx > gateway-demo.yaml

输出后先看日志，不要只看生成文件。Ingress2Gateway 1.0 的价值之一是把未翻译字段和不完全映射显式提示出来；例如配置片段类注解可能没有标准 Gateway API 等价物，某些超时也可能只是尽力映射。工具支持多个 provider 和 emitter，但具体落地仍取决于目标 Gateway API 实现。

迁移前重点核对六类路由行为

项目的 ingress-nginx provider 文档列出了已支持、只识别但不转换、以及会发出 warning 的注解。特别要注意正则路径、捕获组重写、Cookie 灰度和 TLS 后端验证：它们即使出现在生成 YAML 中，也要用实际请求验证语义。

把生成结果当候选，再做行为对照

在测试集群中同时保留原 Ingress 和 Gateway API 入口，用同一组请求分别访问两条路径。对照结果至少包括状态码、Location、响应头、后端收到的路径、超时表现和大请求体处理；不要用“YAML 能成功 apply”代替业务验证。

对照通过后，再采用旁路部署或加权 DNS、负载均衡流量切分等方式做小比例灰度。观察错误率、4xx/5xx、重定向比例、后端路径命中和 P95/P99 延迟；发现差异时先回退流量，再定位是哪一类规则没有等价转换。全部流量稳定后，才清理旧 Ingress 和旧控制器。

常见问题

Ingress2Gateway 1.0 会自动修改生产流量吗？

不会。它读取资源并输出 Gateway API 资源，迁移、apply、旁路和切流仍由团队控制。

生成的 Gateway API YAML 能直接上线吗？

不能这样假设。输出中可能有未转换字段或实现相关差异，必须先在测试集群对照请求行为。

为什么路径看起来一样，结果仍可能不同？

Ingress 控制器常通过注解扩展语义；正则大小写、捕获组重写、重定向状态码、超时和请求体默认值都可能让相同路径得到不同结果。

最终判断可以收敛为一张表：原规则有基线、生成结果无未处理 warning、关键请求行为一致、目标实现的默认值已确认，并且灰度具备快速回退能力，才把该路由标记为可迁移。Ingress2Gateway 1.0 降低的是盘点和转换成本，不能替团队承担路由等价性的判断。