Kubernetes 网关
Semantic Router 可以运行在多种基于 Envoy 的 Kubernetes 网关后面。路由策略保持不变；网关特定资源决定 ExtProc 何时运行、所选模型如何到达后端，以及哪一组件负责认证或流量策略。
每个集成都以 gateway.mode: extproc 运行 Helm chart，deploy/kubernetes/ 下各集成的 values 文件已设置该值：Router 随后在 50051 端口为网关提供 ext_proc gRPC。编写自己的 values 时请设置同样的值。chart 的默认模式 standalone 不需要网关：Router 在自己的 listener 上提供 OpenAI 兼容 API。
选择集成
| 现有数据面 | 从此开始 | 它负责什么 |
|---|---|---|
| Agent Router（原 Envoy AI Gateway） | Agent Router | 提供商转换、提供商凭证、速率限制和 Gateway API 流量策略。 |
| agentgateway | agentgateway | Gateway API 代理、后端资源和 ExtProc 阶段策略。 |
| Istio | Istio Gateway | Ingress、HTTPRoute 处理，以及调用 Semantic Router 的 Envoy 过滤器。 |
| Gateway API Inference Extension | GIE | Semantic Router 选择模型池之后的 InferencePool 端点选择。 |
使用平台已经运维的网关。不要仅为获得语义路由而安装第二个网关，除非你已经比较过所有权、安全策略和升级要求。
共享约定
所有集成必须在以下方面一致：
- 客户端请求的公开模型或入口；
- Semantic Router 写入的模型名称；
- 该模型对应的 Gateway API 匹配或提供商后端；以及
- 推理端点接受的已服务模型标识。
除非部署明确将控制权分配到别处，网关负责客户端认证和传输策略。PII 或越狱检测等语义信号本身不会拦截流量；必须由决策或插件执行预期动作。
请求缓冲与流式
从所选集成要求的处理模式开始。仅在请求大小或立即流式响应需要时才更改。body 缓冲、模式覆盖和流式约束见 Streamed ExtProc。
生产前验证
- 向每个后端发送直接请求；
- 通过网关发送同一请求；
- 检查所选模型和决策头；
- 确认网关解析了所选后端；以及
- 测试凭证、请求限制、流式和失败行为。
测试 Kubernetes Gateway 部署 提供通用清单，不假定集群分配的地址。