上周在群里又看到有人问Nginx Ingress 用了好几年最近要接大模型 API得做 token 限流、多模型 fallback还要管一堆 API Key是不是得上个新网关这个问题几乎每隔几天就出现一次。恰好 Higress 最近正式加入 CNCF Sandbox算是给这个纠结提供了一个新的参考答案它既想保住你手里已有的 Nginx Ingress 资产又把企业级 AI 网关做成了一个主打能力。这篇就结合 Higress 这个项目和我的实际使用体验聊聊它凭什么把存量网关迁移和AI 网关两件事放在一起讲以及如果你正打算从 Nginx Ingress 迁过去到底该怎么动手、有哪些坑要提前知道。1. 先弄明白 Higress 是什么不是又一个网关而是一整套流量入口方案1.1 从 CNCF Sandbox 这个头衔说起CNCF 的项目分级是 Sandbox、Incubating、Graduated 三档Sandbox 是门槛最低的早期项目阶段主要用来验证一个项目是否有生态价值、治理是否健康、能不能走长期路线。Higress 进了 Sandbox意味着它不再只是某个云厂商自己的开源玩具而是以一个中立项目的身份接受基金会治理。对使用者来说这个信号比很多人想象中重要你在生产环境引入一个网关最怕的就是项目突然没人维护或者被某个厂商的商业策略绑架。不过我也提醒一句Sandbox 还远不是毕业状态它只代表项目获得基金会认可、开始高速发展不代表所有能力已经稳定到可以无脑上生产。真要在核心链路用还是要像对待任何基础设施一样先看版本、跑测试、准备回滚。1.2 Higress 的架构定位站在 Istio 和 Envoy 的肩膀上Higress 不是从零写的新网关它站在两个已经被大规模验证的项目之上数据面用 Envoy控制面从 Istio 演进而来。翻译一下就是它拿到了 Envoy 的性能和生态负载均衡、熔断、限流、TLS 终结、可观测性这些能力都是现成的又继承了 Istio 的控制面思路通过 Kubernetes CRD 描述路由、治理规则所以你能看到它支持 Istio 的 VirtualService、DestinationRule 这些 API而不只是 Ingress 那套简陋的路由模型。早年很多人不愿意碰 Istio是因为它重、学习曲线陡。Higress 把 Istio 的东西封装成了自己的网关产品形态你不需要理解整个服务网格只把它当 Ingress Controller 用就行。这样做的好处是你能用上 Envoy 级别的能力但操作心智还保持在管网关的层面。这个取舍我觉得非常务实不重复造轮子不强迫用户学整套网格而是把复杂的东西藏在后面。1.3 三种部署模式接入姿势比想象中灵活Higress 支持几种部署模式不同规模、不同基础设施的团队可以选择不同姿势部署模式适用场景关键特点Kubernetes Ingress 模式替代存量 Ingress Controller直接读取 Ingress 资源兼容 Nginx Ingress 常用注解迁移路径最短独立网关模式多集群网关、统一流量入口控制面独立部署可以纳管多个集群的流量适合中大型平台团队Istio 网关模式已有服务网格的团队作为 Istio Ingress Gateway 使用用 Istio CRD 做精细路由对我个人来说最值得关注的是第一种模式。因为它意味着你可以不用改造业务、不用把 Ingress 资源重写成别的格式先把 Higress 装上去再把流量慢慢挪过去。这个渐进式替换的思路直接决定了迁移成本高不高。2. Nginx Ingress 迁移的难点本质上是注解生态和治理模型的锁定2.1 注解生态业务规则藏在 YAML 的犄角旮旯里很多人以为迁移 Ingress 就是把 Ingress 资源往新网关一扔就完事真做起来根本不是这样。Nginx Ingress 靠注解干了很多事你去看一个跑了两三年的业务 Ingress上面可能挂着十几个注解重写路径、CORS、body 大小限制、速率限制、灰度权重、TCP/UDP 配置、认证转发……这些注解不只是风格问题它们背后是实打实的业务规则。我见过最夸张的一份 Ingress上面同时叠了 rewrite-target、proxy-body-size、limit-rps、auth-url、upstream-vhost 一大堆注解团队已经没人说得清每一条当初为什么加。迁移到新网关的时候如果你只迁移了 path 和 service这些规则就全部丢了轻则功能异常重则直接把生产搞挂。这就是为什么 Higress 把兼容 Nginx Ingress 注解当成一个卖点来强调——它解决的不是技术问题而是业务规则很容易在迁移中被隐形破坏这个问题。2.2 reload 与热更新Nginx 的脾气你懂Nginx Ingress 在配置变更频繁的场景下存在一个老问题很多修改需要 reload 才能生效。reload 过程中worker 进程要重新拉起长连接可能被断开在线用户能感知到卡顿一下。在发布频繁的团队里这种体验是很疼的。Envoy 这边是另一套思路配置变更走的是 xDS 热更新机制不需要重启进程已经建立的连接可以平滑过渡。所以 Higress 在配置变更频繁这个场景下体感会比 Nginx Ingress 好不少。这是我实测中体会比较深的一点以前改一条路由规则要担心 reload 影响连接现在改配置就是秒级生效心理负担小很多。2.3 Lua 二次开发和 Wasm 插件的代际差异很多团队在 Nginx Ingress 之上做了 OpenResty 或者 Lua 插件用来做自定义鉴权、请求改写、灰度逻辑。这些逻辑跑在 Nginx 的生态里一旦要迁移到 Envoy 系网关就等于要重写。重写这东西最麻烦逻辑本身的复杂度不高但要在新环境里复现、对齐行为还要重新压测成本就上来了。Higress 的扩展口子是 Envoy 的 Wasm 插件机制支持用 Go、Rust、C 等多种语言写插件。相比 LuaWasm 的音译不是一个更好的问题而是一种更现代的扩展路径热加载、沙箱隔离、还有类型系统保证写起来相对不容易翻车。从运维角度讲Wasm 插件崩了不会拖垮整个网关进程这一点比 Lua 稳。2.4 为什么把 Nginx Ingress 换掉这件事越来越多人提说句公道话Nginx Ingress 本身没问题它稳定、简单、社区大、文档多到现在依然是很多集群的默认选择。真正的问题在于过去几年大家用 Ingress 做流量入口时治理模型是路径转发 简单限流 TLS 终止。但现在 AI 场景来了流量入口要理解的不只是 URL还有请求内容、模型供应商、token 消耗。Nginx Ingress 在这块基本无能为力。所以换掉 Nginx Ingress并不是因为它坏了而是因为流量入口的职责已经变了。这也是 Higress 把 Nginx Ingress 迁移和 AI 网关打包在一起讲的核心逻辑你不是在做一个简单的替换你是在把入口变成一个有 AI 治理能力的网关。3. Higress 怎么保障迁移兼容层、渐进替换和验证闭环3.1 兼容层具体兼容了什么Higress 的迁移保障思路我总结成一句话先兼容再增强。它直接读取 Kubernetes 标准的 Ingress 资源这是基础。然后针对 Nginx Ingress 常用的注解做了一层适配映射比如nginx.ingress.kubernetes.io/rewrite-target、proxy-body-size、CORS 相关注解、auth 系列注解等在 Higress 侧都有对应处理。也就是说你不需要把注解全部删掉重写很多情况下可以直接带着注解迁过去。但注意这个兼容不是 1:1 的完全复制很多注解的语义有细微差别后面我会专门讲坑。迁移时最忌讳无脑全量同步必须先把注解清单列出来逐一确认新网关下的实际行为。3.2 渐进式迁移不是切流量而是多控制器并存Higress 的另一个聪明之处是它支持多个 Ingress Controller 在一个集群里并存。你可以保留现有 Nginx Ingress Controller只对新的 Ingress 资源指定新的ingressClassName让 Higress 接管这部分流量。老的业务还在 Nginx 上跑新业务或者打算迁移的业务先走 Higress确认稳定之后再逐步改存量 Ingress 的 class 和注解。我建议的节奏是这样的先在测试集群装好 Higress导入一小部分业务域名做功能验证。在预发环境压测重点观察延迟、连接数、日志输出是否符合预期。生产环境先挑一个非核心但流量真实的域名切过去跑一周观察监控和告警。确认没问题后按业务域分批切每切一批留出观察期。最后再把老的 Nginx Ingress Controller 的副本数缩掉而不是直接删。这套节奏本质上是把一次大爆炸迁移拆成无数次可控切换。任何网关迁移失败失败原因大概率不是技术本身而是切换粒度太粗、回滚太难。3.3 迁移前的检查清单真正动刀之前我建议先做一轮盘点至少覆盖以下几项Ingress 资源清单域名、路径、后端 service、端口确认有没有僵尸规则。注解清单逐条列出每个 Ingress 上的注解标注真实用途别只看名字猜。TLS 证书确认证书挂在哪个 secret 上新网关能否直接引用。自定义扩展有没有 Lua 脚本、自定义 Nginx 配置片段server-snippet、config-map 里的特殊指令这些通常是最难迁移的部分。监控告警网关层日志、指标、告警是否都已接入不要等切完流量发现监控是盲的。回滚方案明确一个一键切回 Nginx Ingress的操作步骤并且在预发环境演练一次。这些工作花不了太多时间但能把迁移风险降到可接受范围。3.4 一个切流案例从改 hosts到改 IngressClass我最近帮一个团队做迁移他们的做法很值得参考。他们在生产环境同时跑着 Nginx Ingress 和 HigressNginx 那边继续用老的 IngressClassHigress 这边用新的 IngressClass。第一周他们只把内部测试域名的 Ingress 加了ingressClassName: higress验证内部系统第二周把一个低流量但真实用户会访问的业务域名切过去第三周以后才开始批量迁移。整个过程持续了一个月但几乎没发生线上事故。这就是渐进式的价值你永远有一个还没切完的退路。4. 所谓企业级 AI 网关Higress 到底做了什么4.1 传统网关解决不了 AI 场景的三个问题先说清楚什么是 AI 网关。AI 网关不是一个营销词它要解决的是传统网关在 AI 应用面前的三块短板第一协议不统一。你接 OpenAI、通义千问、Anthropic、DeepSeek每家 SDK 不一样协议格式有时候差很多应用层每接一家就要写一套适配代码。 第二限流维度不对。传统网关限流按 QPS、按 IP、按并发但 AI 应用关心的是 token 消耗。一次请求可能消耗几千个 token某个用户刷一个高 token 的请求比发一万个普通请求还伤成本。按 QPS 限流根本管不住这种场景。 第三API Key 管理分散。AI 应用的 Key 散落在各个服务配置里出了问题没法追溯是谁在用、用了多少。Higress 的 AI 网关能力就是围绕这三块短板做的。4.2 ai-proxy把各家大模型接口统一成 OpenAI 兼容格式Higress 内置了ai-proxy插件可以把它理解为一个协议翻译官。你只要在网关侧配置好各家模型的接入信息API 地址、Key、模型名对外暴露的接口格式统一成 OpenAI 兼容格式。上层业务不用改 SDK不用为每个模型供应商写适配层调用方永远只面对一个标准的 OpenAI 接口。举个例子你可以让 Higress 把 Anthropic 的 Claude 接口伪装成 OpenAI 格式暴露给内部服务。业务团队完全无感但你在网关层已经把供应商切换成了 Claude。这种能力在多个模型供应商之间做横向对比测试时尤其好用。4.3 token 维度的计量与限流不是卡请求而是卡成本我见过很多团队第一次接触 AI 网关都以为 token 限流和普通 QPS 限流差不多其实差异很大。QPS 限流是在请求进来之前拦截token 限流需要先看懂这个请求要消耗多少 token或者从模型响应里拿实际的 usage 数据再按用户维度累加。Higress 在 Envoy 侧解析请求和响应内容从模型返回的 usage 字段里取到 token 消耗数据然后按配置的维度用户、项目、模型、总量做计量和限流。你可以给某个用户设置每天最多消耗 10 万 token超了就直接拒绝或者降级到低配模型。这种能力是传统 Nginx Ingress 完全做不到的因为它根本不理解token是什么。4.4 多上游管理与 Key 托管模型供应商的逃生门AI 应用的另一个痛点是模型供应商可能不稳定。某个厂商的 API 限流了、模型下线了、网络故障了传统网关只会把错误码原样返回给客户端。Higress 这边可以做多上游管理和 fallback配置多个模型供应商主模型失败时自动切到备模型业务方几乎没有感知。API Key 的托管也值得一说。你可以把所有供应商的 Key 都配置在 Higress 上业务方调用时不需要感知用哪个 Key网关帮你轮换、帮你按 Key 做配额统计。这样即使某个 Key 泄漏或者超限也只是影响这一个 Key不会让整条业务断供。4.5 一个务实的提醒AI 网关不是接入模型就完事看了上面的能力你可能觉得 AI 网关很香。但我也要说句实在话AI 网关解决的是接入和治理问题解决不了模型效果问题。你接一个性能差的模型网关再强也无济于事。另外token 计量本身有口径问题——有些厂商按输入输出分别计费有些按总 token 计费配置的时候一定要对齐厂商的计费口径不然最后的账单会对不上。5. 实操把存量 Nginx Ingress 平滑迁到 Higress 的关键步骤5.1 环境准备安装 Higress 并确认 IngressClass安装 Higress 的方式不复杂官方文档提供 Helm Chart 和快速部署 YAML 两种方式。我一般推荐用 Helm因为后续升级、参数调整都方便。装完之后第一件事是确认 IngressClass。Higress 会创建自己的 IngressClass你要做的是在测试集群先建一个最小 Ingress 测试指定ingressClassName: higress确认流量能通。这一步跑通了后面的迁移才有基础。5.2 注解改写对照先把规则对齐再切流量下面把最常用的几组 Nginx Ingress 注解和 Higress 侧的对应关系列一下方便你迁移时对照Nginx Ingress 注解常见用途Higress 迁移建议nginx.ingress.kubernetes.io/rewrite-target路径重写支持对应重写规则但正则 capture 的写法可能有差异必须逐条验证nginx.ingress.kubernetes.io/proxy-body-size请求体大小限制Higress 侧有对应限制能力注意单位换算和默认值差异nginx.ingress.kubernetes.io/cors-*跨域配置支持注意跨域预检请求OPTIONS的行为差异nginx.ingress.kubernetes.io/auth-url/auth-secret外部认证需要映射到 Higress 的认证插件推荐迁移时顺手统一鉴权方式nginx.ingress.kubernetes.io/limit-rps/limit-connections速率限制Higress 有多种限流能力建议按新治理模型重新配置而不是机械照搬这里我特别强调一下rewrite-target。Nginx Ingress 的正则 capture 写法和 Higress 不一定完全一致建议迁移时先把带重写规则的业务梳理出来在测试环境逐条验证确认重写后的 URL 是对的再切生产。重写规则出问题不像路由不通那么明显有时候是页面能打开但接口 404排查起来特别费劲。5.3 流量切换的三种方式切流量的方式取决于你的基础设施。如果前面有云负载均衡或者 DNS 层你可以通过负载均衡的权重来控制两个网关的流量比例先 10% 再到 50% 再到 100%。如果只有集群内部 IngressClass那就用按 Ingress 资源分批改的方式。我用过的比较稳的策略是先改不重要的、只读的、低频的接口再改写接口最后改带复杂鉴权和重写规则的核心接口。每改一批看一批指标不急着推进。5.4 回滚预案不是想不想而是有没有演练过回滚的关键不是知道怎么回滚而是确保能快速回滚。我的做法是在迁移期间保留 Nginx Ingress Controller 不缩容相关 Ingress 资源先不删除随时可以把 IngressClass 改回去。等到 Higress 稳定运行两周以上再做一次模拟回滚演练确认改回 Nginx 后流量依然可用然后再考虑清理旧的 Controller。6. 我在迁移和 AI 网关落地中踩过的坑以及你大概率也会遇到的坑6.1 注解兼容不是全自动更不是一模一样第一次拿 Higress 迁移 Nginx Ingress 业务时我天真的以为注解可以原封不动搬过去结果踩了 rewrite-target 的坑。Nginx 的场景里重写规则经常把正则和固定路径叠在一起写Higress 这边对 capture 组的处理逻辑不完全一样导致一个内部系统迁移后首页正常、静态资源全部 404。所以我的建议非常明确做一个注解迁移验证表把每个 Ingress 的注解、预期行为、实测行为一列逐个打勾。不要相信兼容两个字只相信验证结果。6.2 Wasm 插件不是装了就能漂移也要看日志Higress 的 Wasm 插件是它的亮点但也带来额外的学习成本。插件崩溃、内存超限、逻辑 bug这些问题的排查方式和传统 Lua 插件不一样。我踩过的坑是插件加载之后网关日志里没有明显报错结果某个特定路径的请求直接 500查了半天才发现是插件里一个 nil 指针问题。建议把 Higress 网关 Pod 的日志接入你现有的日志平台重点看 Envoy 层面的 warning 和 error 日志。插件相关的调试可以先在测试环境多跑几轮再上生产别拿生产流量当试验田。6.3 token 限流不是配一个数字就完事AI 网关的 token 限流配置有一个容易被忽略的细节不同模型厂商的 token 计算口径不一样。有的按字符数估算有的按 BPE 词汇表精确计算有的对中文特别不友好。你在 Higress 上配每日 10 万 token之前一定要先确认你说的token和厂商账单里的token是不是同一个东西。我们曾经因为口径不一致某天用户的实际用量超了账单配额三倍才被发现。另一个细节是限流后的行为。超限是直接返回 429还是排队等待还是降级到低配模型这个需要在业务侧和网关侧达成一致否则客户端那边一堆错误码用户体感极差。6.4 多 Key 轮换的并发问题Higress 托管多个 API Key 并自动轮换听起来很省心但如果你下游的调用方是多实例并发部署会有一个隐蔽问题多个请求同时出发时网关可能把同一个 Key 用于多个并发请求遇到厂商的并发限制还是会触发限流。解决思路是配置合理的并发配额感知或者保守一点每个 Key 的并发上限别卡得太满。6.5 什么场景适合现在切什么场景可以再等等最后说点实际的个人判断。如果你现在有这些情况我认为值得认真考虑切到 Higress已经上了 Envoy 系网关或者 Istio不想再维护一套 Nginx。AI 应用开始进入生产需要统一的模型接入层、token 计量、多模型 fallback。受不了一改配置就 reload 的体感希望配置变更秒级生效。团队有能力维护新的网关栈愿意接受学习成本。反过来如果你的业务非常简单就是几十个 Ingress 做纯路径转发没有复杂注解、没有 AI 治理需求团队也没有精力维护新组件那其实没有太大动力非要迁移。Nginx Ingress 依然是个好工具除非你已经遇到它的边界否则不需要为了换而换。Higress 加入 CNCF Sandbox对行业来说是一个信号云原生网关这个赛道已经有一个把存量迁移和AI 治理做成主打能力的项目站上了中立舞台。而从我自己的使用体验看它最打动我的不是某一个酷炫功能而是它让你有机会在不动摇存量业务的前提下把流量入口一步步升级成适配 AI 时代的样子。最后再分享一个实操小技巧不管你是从 Nginx Ingress 迁移还是直接上手 AI 网关配置先在 Higress 的官方文档里找一下从 Nginx Ingress 迁移的对照章节里面那张注解映射表值得打印出来贴墙上比到处翻聊天记录问人要靠谱得多。