Higress 最近发布 v2.2.3，同时项目迈入 CNCF Sandbox。这个节点值得关注：它不只是一次版本号更新，主仓库有 48 项更新，Higress Console 有 8 项更新，方向也很明确——继续扩展 AI Gateway 能力，并增强对 Kubernetes Gateway API 的兼容。
对正在把大模型能力接入生产流量的团队来说，网关正在从“HTTP 转发层”变成“模型访问控制层”：鉴权、路由、限流、观测、灰度和协议适配，都可能在这里发生。
CNCF Sandbox 意味着什么
进入 CNCF Sandbox 不等于项目已经成熟到可以无脑生产托管，但它释放了一个信号：Higress 正在进入更标准化的云原生协作轨道。
对工程团队更实际的影响有三个：
- 生态可见度提升：更多用户、厂商和贡献者会用 CNCF 的视角审视项目。
- 接口标准更重要：项目越靠近云原生主流生态，越需要减少私有配置带来的迁移成本。
- 生产落地会更关注边界：例如插件机制、Gateway API 兼容性、控制台能力、升级路径和可观测性。
v2.2.3 的两个关键词——AI Gateway 扩展与 Kubernetes Gateway API 兼容——正好对应这条路线。
AI Gateway：模型流量需要专门治理
传统 API Gateway 主要处理服务流量，而 AI Gateway 面对的是更“昂贵”和更“不确定”的请求：
- 单次请求成本可能很高，尤其是长上下文和流式输出。
- 不同模型、供应商、区域之间需要动态路由。
- Prompt、Token、响应时间、错误码都应进入观测体系。
- 需要在网关层做统一鉴权、限流、审计和策略控制。
Higress 在 v2.2.3 继续聚焦 AI Gateway 扩展，说明它的定位不只是接入 Kubernetes 服务，也包括统一承载 AI API 流量。对于平台团队来说，这比在每个业务服务里重复写模型调用治理逻辑更干净。
Gateway API：减少网关配置的“方言税”
Kubernetes Gateway API 的价值在于，它试图用标准资源描述网关、监听器和路由关系。相比只依赖某个 Ingress Controller 的私有注解，Gateway API 更适合多团队协作：
- 平台团队管理
GatewayClass和Gateway。 - 应用团队提交
HTTPRoute。 - 权限边界可以通过 namespace 和
allowedRoutes管理。 - 迁移网关实现时，业务配置的改造成本更低。
Higress v2.2.3 强调兼容 Kubernetes Gateway API，说明它正在把自身能力放进更标准的 Kubernetes 资源模型里。这对长期维护尤其重要：网关不应该成为集群里最难迁移的那一层。
可以这样实践：用 Gateway API 描述一条 AI API 路由
下面示例是一个可改造的最小配置，用 Gateway API 思路把 /v1/chat/completions 路由到后端 AI 代理服务。具体 gatewayClassName、命名空间和 Service 名称需要按你的 Higress 安装方式调整。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: higress-gateway
namespace: higress-system
spec:
gatewayClassName: higress
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: ai-chat-route
namespace: default
spec:
parentRefs:
- name: higress-gateway
namespace: higress-system
rules:
- matches:
- path:
type: PathPrefix
value: /v1/chat/completions
backendRefs:
- name: ai-proxy
port: 8080
保存为 ai-route.yaml 后，可以这样应用：
kubectl apply -f ai-route.yaml
kubectl get gateway -n higress-system
kubectl get httproute -n default
如果你还没有后端服务，可以用下面的最小 HTTP 服务模拟 AI 代理，便于验证路由是否生效：
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-proxy
spec:
replicas: 1
selector:
matchLabels:
app: ai-proxy
template:
metadata:
labels:
app: ai-proxy
spec:
containers:
- name: echo
image: hashicorp/http-echo:1.0
args:
- "-text={\"message\":\"mock ai response\"}"
ports:
- containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
name: ai-proxy
spec:
selector:
app: ai-proxy
ports:
- port: 8080
targetPort: 5678
这段配置不代表 Higress v2.2.3 的全部 AI Gateway 能力，而是一个实践起点：先把 AI 流量纳入标准路由模型，再逐步叠加鉴权、限流、观测和模型供应商策略。
升级和采用时的检查清单
如果你已经在使用 Higress，可以围绕下面几个点评估 v2.2.3：
- 配置兼容性：现有 Ingress、插件和控制台配置是否需要迁移或调整。
- Gateway API 覆盖度：你的核心路由场景能否用
Gateway、HTTPRoute等标准资源表达。 - AI 流量治理：是否需要统一处理模型 API 的限流、鉴权、审计和观测。
- 控制台变更：Higress Console 的 8 项更新是否影响日常运维路径。
- 灰度策略：先在测试集群或非核心命名空间验证，再迁移生产入口。
Higress v2.2.3 的重点不是“多了几个功能”这么简单，而是它在两个方向上继续收敛：一边面向 AI 流量治理扩展能力，一边向 Kubernetes Gateway API 这样的标准接口靠拢。对平台团队来说，这正是网关层未来几年最值得押注的组合。