kgateway：云原生 AI 网关的新范式

在 Kubernetes 已经成为容器编排事实标准的今天，如何高效、安全、可观测地管理进出集群的流量，一直是工程团队面临的难题。传统的 API 网关方案往往与特定云厂商绑定，或者依赖繁重的配置语言，学习曲线陡峭、维护成本高。kgateway 的出现，带来了一种完全不同的思路：它不是重新发明轮子，而是站在 Kubernetes Gateway API 这个标准规范的肩膀上，用 Envoy 作为数据面，构建一个声明式、可扩展、厂商无关的网关控制面。更值得关注的是，它正在向 AI Gateway 领域深度挺进——为大模型流量管理专门设计了路由、Prompt 增强、内容安全等能力，成为 LLM 时代基础设施的重要组成部分。

项目起源：从 Slime 到 Kubernetes 原生

kgateway 的历史可以追溯到一个更早期的项目 Slime。Slime 最初是一个服务网格领域的探索项目，目标是简化 Istio 的配置管理。随着 Kubernetes Gateway API 规范的逐渐成熟，社区意识到，与其在 Istio 体系内打补丁，不如基于 Gateway API 从零构建一个更纯粹的网关控制面。于是，kgateway 从 Slime 中独立出来，专注于做 Gateway API 的高质量实现，并放弃了与 Istio 的强绑定关系。

这一转型意义重大：用户不再需要安装完整的 Istio 控制面（通常占用 300MB+ 内存），只需部署 kgateway 一个轻量组件，就能获得完整的 API 网关能力。kgateway 目前由独立团队维护，采用 Apache 2.0 许可证，获得了 OpenSSF Best Practices 认证，在 GitHub 上拥有超过 5500 颗星，是 Kubernetes 生态中增长最快的网关项目之一。

核心定位：Gateway API + Envoy 的控制面

理解 kgateway 的关键，是理解它所处的技术坐标。

Kubernetes Gateway API 是 Kubernetes 官方推进的下一代流量入口规范，相比早年提出的 Ingress，它提供了更丰富的路由抽象——支持 HTTP、TCP、UDP、gRPC 等多种协议，支持权重分流、流量镜像、请求/响应头修改等高级功能，且所有资源都以标准 Kubernetes CRD 的形式管理，任何兼容 Gateway API 的实现都可以互换。

Envoy 则是 Lyft 开源的高性能代理，被广泛部署于服务网格和 API 网关场景，以其强大的可观测性、弹性和可扩展性著称。

kgateway 将两者连接起来：用户编写 Kubernetes 原生的 Gateway、HTTPRoute、TCPRoute 等资源，kgateway 作为控制面将这些配置翻译成 Envoy 能理解的 xDS 协议（Listener、Route、Cluster、Endpoint 等），Envoy 作为数据面执行实际的流量转发。整个链路完全符合云原生设计哲学：控制面与数据面分离，声明式配置驱动。

图1：kgateway AI Gateway 请求流程示意。请求从客户端进入后，经 Envoy 数据面转发，kgateway 控制面通过 xDS 协议下发配置策略，实现 Prompt 增强、内容过滤等功能。

插件架构：像搭积木一样扩展网关功能

kgateway 最具特色的设计，是它的插件翻译管道（Translation Pipeline）。整个配置翻译过程分为三个阶段：

第一阶段：Policy → IR（策略到中间表示）。插件负责将自定义 CRD（如 TrafficPolicy、CircuitBreaker、RateLimit 等）翻译成接近 Envoy proto 格式的 PolicyIR。这一步是插件的核心工作区。

第二阶段：Gateway API 资源聚合。kgateway 聚合 HTTPRoute、Gateway 等核心资源，并将第一阶段的 Policy IR 附加到对应的路由和监听器上，完成配置的"拼装"。

第三阶段：IR → xDS。将完整的中间表示翻译成 Envoy 的 xDS 配置，下发到数据面生效。

图2：kgateway AI Gateway 自定义资源结构。AI 相关的 CRD 涵盖上游类型（AI Provider）和流量策略（AI Policy），形成完整的 AI 流量管理能力。

这种三阶段设计的优势在于：插件之间相互独立，新增功能只需实现一个新的插件，无需修改核心翻译逻辑。插件本身是无状态的（跨翻译无状态，但在单次翻译内通过 ProxyTranslationPass 维护状态），这使得系统行为更容易预测和测试。

kgateway 插件系统借鉴了 Istio 的 KRT（Kubernetes Declarative Controller Runtime）运行时，充分利用 Kubernetes 的声明式能力和事件驱动机制，确保控制器状态与 Kubernetes 资源状态始终保持同步。这种架构选择使得 kgateway 能够优雅地处理 Kubernetes 资源的高频变更，而不会产生竞态条件或配置漂移。

AI Gateway：从通用网关到 LLM 流量专精

kgateway 最令人兴奋的发展方向，是其正在构建的 AI Gateway 能力。根据设计文档（EP-10494），kgateway 计划通过新增两种 CRD 来原生支持 AI 流量管理：

AI Upstream（AI 上游） — 定义 LLM 提供商的连接方式。用户可以配置 OpenAI、Anthropic 等主流模型提供商的接入，也可以连接自托管的模型服务。配置内容包括模型端点、认证方式、默认参数等。

AI TrafficPolicy（AI 流量策略） — 在路由层面附加 AI 特定的处理逻辑，涵盖：

• Prompt 增强（Prompt Enrichment）：在用户请求到达模型之前，自动注入系统提示词、上下文片段或检索增强（RAG）结果。
• Prompt 安全（Prompt Guard）：对输入内容进行安全检查，拦截恶意 Prompt 注入攻击（如著名的"奶奶漏洞"等越狱尝试）。
• 流式响应处理：正确处理 Server-Sent Events（SSE）和流式 token 返回，确保代理层不会破坏流式传输。
• 函数调用（Function Calling）：支持模型发起工具调用场景下的请求/响应拦截和参数转换。

这些能力使得 kgateway 可以作为企业 LLM 出口网关使用：所有对外部大模型的请求和响应都经过 kgateway 代理，团队可以在单一控制点统一管理 API Key、应用安全策略、记录审计日志，而无需在每个应用代码里单独处理。

技术栈：Go 生态的集大成者

kgateway 的主体代码采用 Go 语言（要求 Go 1.26.3+）编写，充分利用了 Go 在云原生领域成熟工具链和运行时优势。从 go.mod 的依赖分析来看，项目的技术栈构成非常清晰：

• 数据面通信：Envoy go-control-plane（xDS 协议 Go 实现），google.golang.org/grpc（gRPC 通信）
• Kubernetes 集成：sigs.k8s.io/gateway-api（Gateway API 类型定义），k8s.io/client-go（K8s 客户端），sigs.k8s.io/controller-runtime（控制器运行时）
• Istio 技术继承：istio.io/istio、istio.io/client-go、istio.io/api（KRT 运行时、Istio CRD 类型）
• 可观测性：Prometheus client（指标），OpenTelemetry SDK（追踪），Zap（日志）
• Helm 部署：helm.sh/helm/v3（Helm Chart 管理器）
• 代码质量：golangci-lint（代码检查），Ginkgo/Gomega（测试框架）， testify（断言库）

代码结构方面，项目遵循 Go 最佳实践的模块化布局：

• cmd/kgateway — 主控制器二进制
• cmd/envoyinit — Envoy 引导配置处理
• cmd/sds — Secret 发现服务
• api/v1alpha1/kgateway/ — CRD 类型定义（使用 kubebuilder 标记）
• pkg/pluginsdk/ — 插件接口抽象
• pkg/kgateway/extensions2/plugins/ — 各插件实现
• pkg/kgateway/krtcollections/ — KRT 集合（核心资源订阅）
• pkg/deployer/ — Helm 部署器

测试覆盖方面，项目要求所有 IR 类型的 Equals 方法必须正确实现（项目有自定义的静态分析工具检测 reflect.DeepEqual 的误用），单元测试避免使用 Ginkgo 而推荐显式错误检查，E2E 测试使用项目自研框架而非直接 kubectl apply。

部署体验：Helm 一键，但需要 K8s 底座

从部署角度，kgateway 是一个纯 Kubernetes 原生项目。它没有提供 Dockerfile（数据面 Envoy 单独部署），也不提供 docker-compose 开发环境（开发调试推荐使用 Tilt + kind 集群）。

标准生产部署流程：通过 Helm Chart 一键安装。项目提供了完整的 Helm values 配置选项，包括是否启用各个插件、AI Gateway 功能开关、指标采集配置等。由于重度依赖 Kubernetes 自身的能力（CRD、Controller Runtime、Resource Watch），kgateway 不支持在 Kubernetes 之外运行，这对习惯在本地 Docker 环境快速验证的用户来说是一个门槛。

开发环境相对友好：使用 Tilt 可以实现代码修改后自动重建镜像并热加载到 kind 集群，开发迭代效率较高。项目还提供了 .devcontainer 配置，VS Code Remote Container 用户开箱即用。

硬件需求方面，kgateway 作为控制面组件，资源占用极低：官方建议 512MB 内存、1GB 磁盘，无需 GPU。由于 Envoy 数据面通常以 DaemonSet 或 Deployment 形式独立部署，kgateway 本身不参与数据转发路径，因此对计算资源的需求非常克制。

行业意义与局限性

kgateway 的出现代表了云原生网关领域的一个趋势：从大而全的 Service Mesh 向专而精的 API Gateway 轻量化演进。相比 Istio 这类功能完备但复杂度高的服务网格，kgateway 只做网关一件事，且做得足够深入。它的插件架构让第三方扩展变得系统化而非 hack 式，这在企业级场景中非常重要。

然而，项目也有明显的局限性。首先，纯 K8s 依赖意味着它在非 Kubernetes 环境（如传统虚拟机、Serverless 平台）中完全无法使用，对于混合部署场景的用户来说是硬伤。其次，AI Gateway 功能仍在积极开发中（截至目前仍处于 EP 阶段），Prometheus/Grafana 集成、细粒度速率限制等进阶功能也尚未完成。第三，作为相对年轻的项目，生产案例和社区规模相比 Kong、Traefik 等成熟网关仍有差距，企业采用时需要评估长尾风险。

从增长曲线看，kgateway 连续多次进入 GitHub Trending，展现出强劲的社区吸引力。随着 AI Gateway 需求的爆发（每个接入大模型的应用都需要一个代理层来做流量管控），kgateway 的定位恰好契合这一趋势，有望在未来 1-2 年内成为 AI 基础设施栈中的关键组件。

快速上手

对于想在本地体验 kgateway 的开发者，推荐流程：

# 1. 创建 kind 集群（含本地镜像仓库）
ctlptl create cluster kind --name kind-kind --registry=ctlptl-registry

# 2. 构建并加载镜像到集群
VERSION=v1.0.0-ci1 CLUSTER_NAME=kind make kind-build-and-load

# 3. 通过 Helm 部署（生产推荐）
helm install kgateway oci://ghcr.io/kgateway-dev/helm/kgateway --version 1.0.0

# 4. 应用示例配置
kubectl apply -f examples/example-gw.yaml
kubectl apply -f examples/example-http-route.yaml

对于 AI 应用开发者，关注 kgateway 的 AI Gateway EP 进展，未来可以通过简单的 CRD 配置实现企业级的 LLM 流量管理，而无需编写胶水代码。