Kubernetes AI Gateway 工作组章程全解AI 流量管理的探索范围、边界与交付物【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 Kubernetes 社区仓库中 wg-ai-gateway/charter.md 为核心系统解读 AI GatewayAI 网关工作组Working Group, WG的成立背景、探索范围、核心功能方向Prompt Guards、Token 限流、语义路由、语义缓存等、与 SIG Network / WG Serving 的边界划分以及工作组如何产出提案并最终解散。读完本文你将完整理解 Kubernetes 社区如何为“AI 流量管理”这类新兴领域划定标准探索路径以及该 WG 在 sigs.yaml 治理体系中的定位与运作方式。一、背景为什么需要一个 “AI Gateway” 工作组近几年大量名为 “AI Gateway” 的产品/项目涌现并在 Kubernetes 上部署运行且通常基于 Gateway API 构建。面对这一快速增长且碎片化的领域Kubernetes 社区需要判断这些 AI 网关所具备的功能是否具有长期生命力、是否对用户具备普遍价值以及是否应当围绕它们扩展 Kubernetes 的既有标准。本 WG 的使命陈述记录于 sigs.yaml 第 3556-3559 行对此给出了精炼概括The AI Gateway Working Group focuses on the intersection of AI and networking, particularly in the context of extending load-balancer, gateway and proxy technologies to manage and route traffic for AI Inference.即聚焦AI 与网络的交汇点探索如何扩展负载均衡器、网关与代理技术以管理和路由 AI 推理流量。在 SIG Network 中已有Gateway API Inference ExtensionGIE项目。GIE 目前与 Gateway 配对根据模型服务平台如 vLLM通告的能力与指标来“调度”路由。章程将这类场景称为“模型托管用例”model serving use case即模型本身托管在 Kubernetes 上的情况。但还存在另一种部署情形用户并不托管模型而是借助 Gateway 控制对第三方模型服务的访问如 Gemini、OpenAI、Mistral、Claude 等章程称之为“出口用例”egress use case。两种用例中用户都希望能在网关层为推理请求附加更高级的过滤器filter、策略policy与其他插件以控制或修改推理请求。此外还有大量尚未充分探索、但看起来可以干净地以 HTTPRoute 级 filter 或 policy 形式实现部分甚至适用于 Gateway 级的功能例如在 HTTPRoute 层通过 filter 实现“语义路由”在“路由/调度”层之前决定路由到哪个模型基于 token 用量做限流rate-limit策略可能同样适用于 Gateway 层。章程将这些层面的功能统称为“AI Gateway” 特性。二、Scope范围管理 Kubernetes 上的 AI 流量WG 的范围是在 Kubernetes 语境下定义 “AI Gateway” 等术语并提出需要被采纳的交付物以实现在 Kubernetes 上管理 AI 流量。章程列出如下探索方向原文明确注明该列表是示例性、非穷尽的WG 不一定会全部实施目的是说明将探索的功能类型功能方向含义落地层次推测Prompt Guards提示词防护为推理请求内容定义并强制实施内容安全规则检测并阻断敏感或恶意的提示词HTTPRoute 级 filter / policyToken Rate LimitingToken 限流基于 token 用量实施限流规则以控制使用量与成本HTTPRoute 级或可上移至 Gateway 级Semantic Routing语义路由基于请求体的语义相似度对推理请求做出路由决策HTTPRoute 级 filterSemantic Caching语义缓存基于提示词的语义相似度为推理响应提供缓存HTTPRoute 级Response Risk响应风险为生成式 AI 模型的推理响应内容定义并实施内容安全规则检测并阻断敏感响应HTTPRoute 级Failure Modes故障模式定义推理路由失败的处理方式明确需要覆盖的故障模式例如封装回退fallback与重试retry策略跨层级Observability可观测性评估 “AI Gateway” 的可观测机制判断是否存在 AI 网关特有需求并依据现有工具提出建议与 OpenTelemetry 等现有工具协同从章程的行文看这些特性多数“可以干净地添加在 HTTPRoute 层通过 filter 或策略实现”部分如 token 限流“甚至可能适用于 Gateway 层”——这正与 Gateway API 的层级化资源模型Gateway → HTTPRoute → filter/policy相呼应。此外WG 还会探索这些特性在多集群multi-cluster用例中的应用并为多集群部署场景提供支持。2.1 In Scope范围内章程给出的总体指导原则是尽量控制范围。WG 通过 AI 网络与流量管理特性支持模型托管但自身不开发模型托管功能除非与 WG Serving 联合。具体范围内事项包括在 Kubernetes 语境下提供 AI 相关网络术语的定义如 “AI Gateway”为 Kubernetes 用户定义重要用例覆盖单集群与多集群场景根据用户与实现方的需求判断 “AI Gateway” 领域哪些通用特性与能力需要由 Kubernetes 标准与 API 覆盖向合适的子项目提交 “AI Gateway” 特性与能力的提案若现有子项目不足以承载提议创建新的子项目。2.2 Out of Scope范围外章程明确划出了以下边界不开发完整的 “AI Gateway” 解决方案本组专注于让现有与新方案更容易在 Kubernetes 上部署和管理而不是创建新的网关产品不涉及特定硬件支持不覆盖 AI 网络的全谱系例如 RDMA 网络一般不在范围内不直接开发模型托管与 AI 工作负载本身虽然服务于“模型托管用例”但除非与 WG Serving 协作否则直接做模型托管/AI 工作负载不在范围内不制定新的可观测性标准可能向 OpenTelemetry 等组织提出建议但不作为本工作组职责去开发新标准。三、边界厘清与 WG Serving / GIE 的分工章程专门用一节阐述一个微妙但重要的边界当涉及推理**工作负载inference workloads**的负载均衡与路由时——当用例包含集群内本地模型托管且路由/负载均衡特性依赖推理工作负载通告的信息时此类路由归属于WG Serving的范围。典型例子是 Gateway API Inference ExtensionGIE该项目源自 WG Serving专门处理由模型服务平台如 vLLM通告的指标与能力所驱动的推理高级路由与负载均衡。在这个意义上GIE 实际上是 KubernetesServiceAPI 的替代方案而本 WG 更倾向于在Gateway与HTTPRoute层面运作。因此需要与模型托管层交互的联网用例一般超出本 WG 范围如果 WG 的某项工作必须跨越这条线则必须上报给 WG Serving并作为联合工作共同推进。这一分工也解释了为何本 WG 的“语义路由”被定位在路由/调度层之前的 HTTPRoute filter 层面——调度层本身归 WG Serving 管。在仓库中WG Serving 已归档于 archive/wg-serving/其 charter 与年报可对照查阅帮助理解这一历史分工。四、Deliverables交付物WG 的交付物并非代码而是治理文档与提案具体包括两项一份 AI 相关网络定义与关键用例的汇编涵盖 “AI Gateway” 等术语定义以及面向 Kubernetes 用户的关键用例一个协作与实验的空间用于判断 Kubernetes 最应支持哪些特性与能力若对某一想法形成强共识WG 将促进并协调在合适领域提交提案。这与 Kubernetes 对 Working Group 的定位一致wg-governance.md 明确指出Working Group不拥有代码、有清晰可衡量的交付物、本质上是临时性的达成目标后即解散。WG 产出的代码若有会按标准政策存放在由 SIG 拥有的合适仓库中。五、Stakeholders利益相关方章程登记的利益相关方stakeholders为SIG Networksig-network/Gateway API 与网络标准的归属 SIGGIE 项目亦在此SIG MultiClustersig-multicluster/对应章程中多集群用例的探索承诺。相关 WGWG ServingWG Serving 的领域是 AI 工作负载这些工作负载可由本 WG 计划添加的网络支持来承载。当本 WG 产生与 serving 强相关的提案时会邀请 WG Serving 参与并提供反馈。两个 WG 的关系在 sigs.yaml 与归档目录 archive/wg-serving/ 中均有迹可循。六、角色与组织管理本 WG 遵循 wg-governance.md 中定义的角色与组织管理方式并选择接受该文档的后续更新与修订。章程结构本身遵循 committee-steering/governance/wg-charter-template.md 模板约定Background / Scope / In Scope / Out of Scope / Stakeholders / Deliverables / Roles and Organization Management / Exit Criteria而治理细则则由 committee-steering/governance/README.md 与 wg-governance 统一约定。从仓库治理数据sigs.yaml 第 3566-3592 行可确认该 WG 的组织结构当前由 5 位来自不同公司的 Organizers 领导Microsoft、Buoyant、Google、NVIDIA、Red Hat并有 2 位 Emeritus Organizerswg-ai-gateway/README.md 还列出了周会每周四 2PM EST、Slack 频道#wg-ai-gateway、邮件列表与 Steering Committee Liaison 等沟通渠道。根据 wg-governance.mdWorking Group 组建的触发点是 Organizers 回答一系列关键问题要解决什么问题、交付什么产物、如何判断完成、利益相关 SIG 是谁、会议机制、代表谁的利益、由谁主持、多样性如何随后在 sigs.yaml 提交 PR 并按 sig-wg-lifecycle.md 的清单完成创建。七、Exit Criteria退出标准WG 在按既定范围完成交付物、并得到小组共识的关键用例与特性清单后即告完成。章程给出理想的生命周期轨迹确定面向 Kubernetes 用户与实现方的定义及关键用例并文档化确定 Kubernetes 为最佳支持上述用例所需的关键特性清单针对清单中的每项特性向合适的子项目提交提案若有必要提议新的子项目特性清单完成后为未来的实现留下指导与最佳实践然后解散。这一退出机制与 wg-governance.md 及 sig-wg-lifecycle.md 描述的 WG 解散条件无 Chair、沟通渠道长期闲置等共同构成完整的生命周期闭环。八、仓库中的落地佐证从章程到提案的进展章程不是一纸空文仓库中的配套文件记录了它的落地过程wg-ai-gateway/annual-report-2025.mdWG 于 2025 年 9 月正式成立章程获批、提案仓库建立、周会启动2025 年内已产出两份提案——Payload Processingprompt guards、语义路由/缓存及其在 Gateway API filter 上的映射与Egress Gateways面向 OpenAI、Gemini、Claude 等第三方 AI 服务的代理包含先前方案对比与基于 Gateway API 的资源模型并为 Backend 资源在 Gateway API 侧打开了 draft GEPsigs.yaml第 3556-3608 行作为社区治理的“单一事实来源”记录 WG 名称、使命陈述、charter 链接、利益相关 SIG、labelai-gateway、领导层、会议与联系方式wg-ai-gateway/README.md由 generator/wg_readme.tmpl 依据 sigs.yaml 自动生成头部明确标注“请勿直接编辑应修改根目录 sigs.yaml”——这正是本仓库“sigs.yaml 驱动文档生成”治理模式的体现。九、总结这份章程对社区的工程意义从工程师视角看这份章程的价值在于提前划定标准探索的边界在 AI 网关生态碎片化的当下Kubernetes 社区通过一个临时性、无代码所有权、以提案为交付物的工作组来判断哪些能力Prompt Guards、Token 限流、语义路由、语义缓存、响应风险、故障模式、可观测性值得沉淀为 Gateway API 级别的标准同时通过“范围外”条款避免与 WG Serving、模型托管、硬件网络等领域重叠。对于希望在 Kubernetes 上构建或使用 AI 网关的开发者这份章程是一份清晰的“路线图预告”想在HTTPRoute/Gateway 层做语义路由、token 限流、提示词/响应安全过滤——这正是本 WG 的探索方向想基于模型工作负载通告的指标做调度——应关注 WG Serving / GIE 的演进想为第三方模型服务的出口代理egress建立标准资源模型——可追踪 Egress Gateways 提案的后续。后续进展可继续关注 wg-ai-gateway/annual-report-2025.md 所提到的提案仓库与 Gateway API GEP以获取第一手的技术细节。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes AI Gateway 工作组章程全解AI 流量管理的探索范围、边界与交付物【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community导读本文以 Kubernetes 社区仓库中 wg-ai-gateway/charter.md 为核心系统解读 AI GatewayAI 网关工作组Working Group, WG的成立背景、探索范围、核心功能方向Prompt Guards、Token 限流、语义路由、语义缓存等、与 SIG Network / WG Serving 的边界划分以及工作组如何产出提案并最终解散。读完本文你将完整理解 Kubernetes 社区如何为“AI 流量管理”这类新兴领域划定标准探索路径以及该 WG 在 sigs.yaml 治理体系中的定位与运作方式。一、背景为什么需要一个 “AI Gateway” 工作组近几年大量名为 “AI Gateway” 的产品/项目涌现并在 Kubernetes 上部署运行且通常基于 Gateway API 构建。面对这一快速增长且碎片化的领域Kubernetes 社区需要判断这些 AI 网关所具备的功能是否具有长期生命力、是否对用户具备普遍价值以及是否应当围绕它们扩展 Kubernetes 的既有标准。本 WG 的使命陈述记录于 sigs.yaml 第 3556-3559 行对此给出了精炼概括The AI Gateway Working Group focuses on the intersection of AI and networking, particularly in the context of extending load-balancer, gateway and proxy technologies to manage and route traffic for AI Inference.即聚焦AI 与网络的交汇点探索如何扩展负载均衡器、网关与代理技术以管理和路由 AI 推理流量。在 SIG Network 中已有Gateway API Inference ExtensionGIE项目。GIE 目前与 Gateway 配对根据模型服务平台如 vLLM通告的能力与指标来“调度”路由。章程将这类场景称为“模型托管用例”model serving use case即模型本身托管在 Kubernetes 上的情况。但还存在另一种部署情形用户并不托管模型而是借助 Gateway 控制对第三方模型服务的访问如 Gemini、OpenAI、Mistral、Claude 等章程称之为“出口用例”egress use case。两种用例中用户都希望能在网关层为推理请求附加更高级的过滤器filter、策略policy与其他插件以控制或修改推理请求。此外还有大量尚未充分探索、但看起来可以干净地以 HTTPRoute 级 filter 或 policy 形式实现部分甚至适用于 Gateway 级的功能例如在 HTTPRoute 层通过 filter 实现“语义路由”在“路由/调度”层之前决定路由到哪个模型基于 token 用量做限流rate-limit策略可能同样适用于 Gateway 层。章程将这些层面的功能统称为“AI Gateway” 特性。二、Scope范围管理 Kubernetes 上的 AI 流量WG 的范围是在 Kubernetes 语境下定义 “AI Gateway” 等术语并提出需要被采纳的交付物以实现在 Kubernetes 上管理 AI 流量。章程列出如下探索方向原文明确注明该列表是示例性、非穷尽的WG 不一定会全部实施目的是说明将探索的功能类型功能方向含义落地层次推测Prompt Guards提示词防护为推理请求内容定义并强制实施内容安全规则检测并阻断敏感或恶意的提示词HTTPRoute 级 filter / policyToken Rate LimitingToken 限流基于 token 用量实施限流规则以控制使用量与成本HTTPRoute 级或可上移至 Gateway 级Semantic Routing语义路由基于请求体的语义相似度对推理请求做出路由决策HTTPRoute 级 filterSemantic Caching语义缓存基于提示词的语义相似度为推理响应提供缓存HTTPRoute 级Response Risk响应风险为生成式 AI 模型的推理响应内容定义并实施内容安全规则检测并阻断敏感响应HTTPRoute 级Failure Modes故障模式定义推理路由失败的处理方式明确需要覆盖的故障模式例如封装回退fallback与重试retry策略跨层级Observability可观测性评估 “AI Gateway” 的可观测机制判断是否存在 AI 网关特有需求并依据现有工具提出建议与 OpenTelemetry 等现有工具协同从章程的行文看这些特性多数“可以干净地添加在 HTTPRoute 层通过 filter 或策略实现”部分如 token 限流“甚至可能适用于 Gateway 层”——这正与 Gateway API 的层级化资源模型Gateway → HTTPRoute → filter/policy相呼应。此外WG 还会探索这些特性在多集群multi-cluster用例中的应用并为多集群部署场景提供支持。2.1 In Scope范围内章程给出的总体指导原则是尽量控制范围。WG 通过 AI 网络与流量管理特性支持模型托管但自身不开发模型托管功能除非与 WG Serving 联合。具体范围内事项包括在 Kubernetes 语境下提供 AI 相关网络术语的定义如 “AI Gateway”为 Kubernetes 用户定义重要用例覆盖单集群与多集群场景根据用户与实现方的需求判断 “AI Gateway” 领域哪些通用特性与能力需要由 Kubernetes 标准与 API 覆盖向合适的子项目提交 “AI Gateway” 特性与能力的提案若现有子项目不足以承载提议创建新的子项目。2.2 Out of Scope范围外章程明确划出了以下边界不开发完整的 “AI Gateway” 解决方案本组专注于让现有与新方案更容易在 Kubernetes 上部署和管理而不是创建新的网关产品不涉及特定硬件支持不覆盖 AI 网络的全谱系例如 RDMA 网络一般不在范围内不直接开发模型托管与 AI 工作负载本身虽然服务于“模型托管用例”但除非与 WG Serving 协作否则直接做模型托管/AI 工作负载不在范围内不制定新的可观测性标准可能向 OpenTelemetry 等组织提出建议但不作为本工作组职责去开发新标准。三、边界厘清与 WG Serving / GIE 的分工章程专门用一节阐述一个微妙但重要的边界当涉及推理**工作负载inference workloads**的负载均衡与路由时——当用例包含集群内本地模型托管且路由/负载均衡特性依赖推理工作负载通告的信息时此类路由归属于WG Serving的范围。典型例子是 Gateway API Inference ExtensionGIE该项目源自 WG Serving专门处理由模型服务平台如 vLLM通告的指标与能力所驱动的推理高级路由与负载均衡。在这个意义上GIE 实际上是 KubernetesServiceAPI 的替代方案而本 WG 更倾向于在Gateway与HTTPRoute层面运作。因此需要与模型托管层交互的联网用例一般超出本 WG 范围如果 WG 的某项工作必须跨越这条线则必须上报给 WG Serving并作为联合工作共同推进。这一分工也解释了为何本 WG 的“语义路由”被定位在路由/调度层之前的 HTTPRoute filter 层面——调度层本身归 WG Serving 管。在仓库中WG Serving 已归档于 archive/wg-serving/其 charter 与年报可对照查阅帮助理解这一历史分工。四、Deliverables交付物WG 的交付物并非代码而是治理文档与提案具体包括两项一份 AI 相关网络定义与关键用例的汇编涵盖 “AI Gateway” 等术语定义以及面向 Kubernetes 用户的关键用例一个协作与实验的空间用于判断 Kubernetes 最应支持哪些特性与能力若对某一想法形成强共识WG 将促进并协调在合适领域提交提案。这与 Kubernetes 对 Working Group 的定位一致wg-governance.md 明确指出Working Group不拥有代码、有清晰可衡量的交付物、本质上是临时性的达成目标后即解散。WG 产出的代码若有会按标准政策存放在由 SIG 拥有的合适仓库中。五、Stakeholders利益相关方章程登记的利益相关方stakeholders为SIG Networksig-network/Gateway API 与网络标准的归属 SIGGIE 项目亦在此SIG MultiClustersig-multicluster/对应章程中多集群用例的探索承诺。相关 WGWG ServingWG Serving 的领域是 AI 工作负载这些工作负载可由本 WG 计划添加的网络支持来承载。当本 WG 产生与 serving 强相关的提案时会邀请 WG Serving 参与并提供反馈。两个 WG 的关系在 sigs.yaml 与归档目录 archive/wg-serving/ 中均有迹可循。六、角色与组织管理本 WG 遵循 wg-governance.md 中定义的角色与组织管理方式并选择接受该文档的后续更新与修订。章程结构本身遵循 committee-steering/governance/wg-charter-template.md 模板约定Background / Scope / In Scope / Out of Scope / Stakeholders / Deliverables / Roles and Organization Management / Exit Criteria而治理细则则由 committee-steering/governance/README.md 与 wg-governance 统一约定。从仓库治理数据sigs.yaml 第 3566-3592 行可确认该 WG 的组织结构当前由 5 位来自不同公司的 Organizers 领导Microsoft、Buoyant、Google、NVIDIA、Red Hat并有 2 位 Emeritus Organizerswg-ai-gateway/README.md 还列出了周会每周四 2PM EST、Slack 频道#wg-ai-gateway、邮件列表与 Steering Committee Liaison 等沟通渠道。根据 wg-governance.mdWorking Group 组建的触发点是 Organizers 回答一系列关键问题要解决什么问题、交付什么产物、如何判断完成、利益相关 SIG 是谁、会议机制、代表谁的利益、由谁主持、多样性如何随后在 sigs.yaml 提交 PR 并按 sig-wg-lifecycle.md 的清单完成创建。七、Exit Criteria退出标准WG 在按既定范围完成交付物、并得到小组共识的关键用例与特性清单后即告完成。章程给出理想的生命周期轨迹确定面向 Kubernetes 用户与实现方的定义及关键用例并文档化确定 Kubernetes 为最佳支持上述用例所需的关键特性清单针对清单中的每项特性向合适的子项目提交提案若有必要提议新的子项目特性清单完成后为未来的实现留下指导与最佳实践然后解散。这一退出机制与 wg-governance.md 及 sig-wg-lifecycle.md 描述的 WG 解散条件无 Chair、沟通渠道长期闲置等共同构成完整的生命周期闭环。八、仓库中的落地佐证从章程到提案的进展章程不是一纸空文仓库中的配套文件记录了它的落地过程wg-ai-gateway/annual-report-2025.mdWG 于 2025 年 9 月正式成立章程获批、提案仓库建立、周会启动2025 年内已产出两份提案——Payload Processingprompt guards、语义路由/缓存及其在 Gateway API filter 上的映射与Egress Gateways面向 OpenAI、Gemini、Claude 等第三方 AI 服务的代理包含先前方案对比与基于 Gateway API 的资源模型并为 Backend 资源在 Gateway API 侧打开了 draft GEPsigs.yaml第 3556-3608 行作为社区治理的“单一事实来源”记录 WG 名称、使命陈述、charter 链接、利益相关 SIG、labelai-gateway、领导层、会议与联系方式wg-ai-gateway/README.md由 generator/wg_readme.tmpl 依据 sigs.yaml 自动生成头部明确标注“请勿直接编辑应修改根目录 sigs.yaml”——这正是本仓库“sigs.yaml 驱动文档生成”治理模式的体现。九、总结这份章程对社区的工程意义从工程师视角看这份章程的价值在于提前划定标准探索的边界在 AI 网关生态碎片化的当下Kubernetes 社区通过一个临时性、无代码所有权、以提案为交付物的工作组来判断哪些能力Prompt Guards、Token 限流、语义路由、语义缓存、响应风险、故障模式、可观测性值得沉淀为 Gateway API 级别的标准同时通过“范围外”条款避免与 WG Serving、模型托管、硬件网络等领域重叠。对于希望在 Kubernetes 上构建或使用 AI 网关的开发者这份章程是一份清晰的“路线图预告”想在HTTPRoute/Gateway 层做语义路由、token 限流、提示词/响应安全过滤——这正是本 WG 的探索方向想基于模型工作负载通告的指标做调度——应关注 WG Serving / GIE 的演进想为第三方模型服务的出口代理egress建立标准资源模型——可追踪 Egress Gateways 提案的后续。后续进展可继续关注 wg-ai-gateway/annual-report-2025.md 所提到的提案仓库与 Gateway API GEP以获取第一手的技术细节。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
