Traefik 3.7 原生吃下 85+ ingress-nginx 注解，无需改写 YAML

Traefik Proxy v3.7 代号 "Langres"，2026-05-05 GA，共 283 个 PR、80+ 社区贡献者。对还在跑 ingress-nginx 的集群来说，最值得看的一点是：Ingress NGINX provider 脱离 experimental，成为一等公民。

• Release 说明：https://traefik.io/blog/traefik-proxy-3-7-is-available
• v3.7.0 release：https://github.com/traefik/traefik/releases/tag/v3.7.0
• 仓库：https://github.com/traefik/traefik

Ingress NGINX provider 转正

provider 现在原生支持 85+ 常用 ingress-nginx 注解，官方称覆盖其观测到的 90%+ 真实使用场景。注解不是一次性全量铺开，而是按采样到的生产环境分布排序，逐步补齐。

「drop-in」就来自这里：注解由 provider 直接解析，翻译成 Traefik 的运行时配置，不需要先把 Ingress 注解转写成 IngressRoute / Middleware CRD。现有 manifest 原样带着启用 provider 即可迁移，不用重写 YAML，也不用做注解转换。

代价同样明确：90%+ 不等于 100%，剩下的边角注解仍要自己核对；既然是「按分布排序、逐步补齐」，覆盖清单也会随版本变化，升级前对着自己的注解集合过一遍更稳。

snippets 的 allowlist 取舍

server-snippet 和 configuration-snippet 不走整体放行，而是按精选 allowlist 解析。

这是一个明确的安全取舍：snippet 本质是往代理配置里注入任意指令，如果原样透传，等于把 ingress-nginx 的配置注入面整块搬到 Traefik 上。走 allowlist 之后，清单之外的指令不会被应用，安全边界清楚，代价是迁移时要逐条比对自己 snippet 里用到的指令是否在清单内。

middlewares on services（#12544）

中间件可以挂到 service 定义上，对该 service 下的所有 router 生效，而不必在每条 router 上重复挂载。这一条补的是 ingress provider 与 CRD 语义之间的落差——从 Ingress 注解迁移过来时，同一个后端服务上的中间件行为能保持住原有形态。

Gateway API v1.5.1（#12768）

完整支持 Gateway API v1.5.1。

Retry 按响应状态码重试（#12667）

Retry 中间件新增三项能力：按 HTTP 响应状态码触发重试、单次尝试超时、非幂等方法的 opt-in。

取舍点在于判定方式。只看连接是否失败，会漏掉「连接正常但上游一直返回 502/503」这类故障；改成按响应状态码判定，这类错误才进入重试路径。单次尝试超时限制每一次尝试的耗时，避免单个慢请求吃光整个重试预算——超时给太紧会误伤正常慢接口，给太松则重试失去意义。

非幂等方法默认不重试，需要显式打开。打开后重试可能导致重复提交，是否 opt-in 取决于该接口本身能否重放。

Failover 也按响应状态码触发（#12596）

Failover service 同样改为按响应状态码触发。配合 TraefikService CRD 的 failover 配置，可以在 K8s 里声明蓝绿或主备切换。

相比纯健康检查，「进程活着但持续返回 5xx」这种情况只有看状态码才切得动，这是这次改动带来的覆盖提升。反面是容量要求：备用后端必须随时能接住全量流量，按双份资源准备；切换之后怎么回切，也要在 TraefikService 里一并想清楚。

其余变更

• Dashboard 新增 certificates 证书总览菜单（#12628，外部贡献）。
• Helm chart v40.0.0 固定 app 版本 v3.7.0。
• 3.7 线后续有多次安全更新，例如 3.7.13、3.7.14，部署时应选用线内最新补丁版本。