机器学习平台技术栈之 Envoy Gateway：云原生 AI 流量调度的全能守门人

在构建现代大规模机器学习平台（Machine Learning Platform）时，人们通常将目光聚焦在底层的算力调度（如 Volcano）、GPU 资源管理（如 Device Plugin）、或是高性能推理引擎（如 vLLM, TensorRT-LLM）上。然而，当一个优秀的模型被成功加载到显存并开始提供服务后，它将面临现实世界中最复杂的挑战——网络流量。

如何将内部的推理微服务安全、稳定、高性能地暴露给外部用户？
如何平滑地进行新老版本模型的 A/B 测试和灰度发布？
对于极其昂贵的 LLM（大语言模型）API，如何进行精准的并发控制与全局限流（Rate Limiting）？
遇到需要维持长连接的 gRPC 流量（例如 Triton Inference Server）或者是流式响应（Server-Sent Events），网关能否扛住压力？

过去，我们大量使用 NGINX Ingress 来解决这些问题，但在面对 AI 推理时代复杂的协议栈和动态拉起的异构服务时，传统 Ingress 显得捉襟见肘。因此，基于 Kubernetes 演进的下一代网关标准 Gateway API，与云原生代理霸主 Envoy Proxy 的结合体——**Envoy Gateway (EG)**，逐渐成为了现代机器学习平台网关层的绝对核心。

本文将全方位深入解构 Envoy Gateway。从基础概念、K8s Gateway API 的架构思想，到底层架构设计，再到针对 AI 场景（gRPC、灰度切流、全局限流）的关键技术细节，带你领略这套下一代全能守门人的风采。

1. 痛点：为什么 AI 平台要抛弃传统的 NGINX Ingress？

在深入 Envoy Gateway 之前，必须先回答一个架构选型问题：为什么原有的 NGINX Ingress 无法满足当今 AI 架构的需求？

  1. 缺乏一等公民的 gRPC 和流式连接支持：AI 领域大量使用 gRPC（例如 NVIDIA Triton 默认推崇 gRPC 接口以实现高并发阵列化传输）。传统 Ingress 对 gRPC 的支持一般通过复杂的、容易出错的 Annotation 来实现，属于“打补丁”性质。
  2. 配置地狱与碎片化（Annotation Hell）：K8s Ingress API 设计过于简陋（只能定义最基础的 Host 和 Path）。想要实现限流、重写、超时设置，只能往 Ingress YAML 里狂塞成百上千行的 nginx.ingress.kubernetes.io/xxx 注解，可维护性极差。
  3. 动态扩缩容导致的 Reload 卡顿：AI 推理 Pod 极具弹性（例如由于流量潮汐产生的大规模 HPA 扩缩容）。NGINX 在更新 Upstream 后端时，常常需要重载（Reload）进程，这会导致现有长连接断开、产生延迟尖峰，甚至引发大模型推理请求的中断。
  4. 缺乏角色分离：集群管理员（SRE）与算法工程师（业务侧）修改的是同一个 Ingress 文件，极其容易发生配置冲突和安全越权。

为了解决上述问题，Kubernetes 社区推出了面向未来的标准网络模型：Gateway API。而 Envoy Gateway 则是这一标准的官方“头牌”实现。

2. 核心概念解析

理解 Envoy Gateway，需要拆解它背后的三大核心概念实体：底层数据面、API 标准模型与控制面大脑。

2.1 Envoy Proxy (数据面 Data Plane)

Envoy 是由 Lyft 开源（现归属 CNCF）的一款专为云原生设计的 C++ 高性能边缘和中间层代理。它的核心特色在于 动态配置管理 (xDS Protocol) ——完全无需任何进程重启（Reload），即可实时更新监听器、路由、后端集群、甚至是 SSL 证书。并且它从基因里原生地、完美地支持 HTTP/2 和 gRPC。对于流式生成（LLM Streaming）极度友好。

2.2 Kubernetes Gateway API (标准资源模型)

这是 Kubernetes 为了取代 Ingress 而推出的全新 CRD（自定义资源）集合。它采用了基于角色的设计（Role-oriented Design），将网关的管理切分为不同层级：

  • GatewayClass：基础设施提供者定义（网关的蓝图，表明由 Envoy Gateway 来接管）。
  • Gateway：集群管理员定义（具体的网关实例，占据什么 IP，监听 80 还是 443 端口，挂载什么 TLS 证书）。
  • HTTPRoute / GRPCRoute：应用开发者/算法工程师定义（具体的路由规则：什么 Path，什么 Header 路由到哪个 Model Serving Pod）。

2.3 Envoy Gateway (控制面 Control Plane)

Envoy Gateway 并不是重新发明轮子，而是一个强大的翻译官。它是一个用 Go 语言编写的 Kubernetes 控制器。它的唯一作用是：监听 K8s 里的 Gateway API 资源（Gateway, HTTPRoute 等），并将它们自动、实时地翻译成 Envoy Proxy 能听懂的 xDS 协议配置，下发给数据面执行。

3. 概念之间的关系图谱与流量模型

在 Gateway API 的世界中，职责被清晰地切分。让我们用一张关系图来反映这种层级递进的关系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
graph TD
    subgraph Infrastructure Provider (平台架构师)
        GC[GatewayClass \n (Name: envoy)]
    end

    subgraph Cluster Operator (平台SRE)
        GW[Gateway \n (Listener: 80, 443; Host: api.ai.com)]
        GC -.->|Instantiates| GW
    end

    subgraph App Developer (算法工程师 / MLOps)
        HR1[HTTPRoute \n (Path: /v1/chat/completions)]
        HR2[GRPCRoute \n (Service: triton.models.ResNet)]
        
        GW -.->|Attaches to| HR1
        GW -.->|Attaches to| HR2
    end
    
    subgraph K8s Services & Pods
        Svc1[Service: Llama-3-8B]
        Svc2[Service: Triton-CV-Model]
        
        HR1 -.->|Forwards Traffic| Svc1
        HR2 -.->|Forwards Traffic| Svc2
    end

这种解耦的巨大意义在于：算法工程师每次发布一个新的大模型（只是加了一条 HTTPRoute），再也不需要去碰全局的 Gateway 或 Ingress 配置，永远不必担心把整个集群的其它模型路由给改崩了。

4. Envoy Gateway 架构设计

Envoy Gateway 是一款标准的云原生微服务架构，分为高度分离的控制平面与数据平面。

4.1 全栈架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
flowchart TB
    Client([外部调用方 (Web/API/App)])

    subgraph Kubernetes Cluster
        subgraph Envoy Gateway Control Plane
            EGManager[Envoy Gateway Controller]
            Translator[Resource Translator (xDS Builder)]
            xDS[xDS gRPC Server]
            
            EGManager -->|Watch / Read| K8sAPI[(K8s API Server)]
            EGManager --> Translator
            Translator --> xDS
        end

        subgraph Envoy Data Plane (Proxy Fleet)
            EnvoyPod1[Envoy Proxy Pod]
            EnvoyPod2[Envoy Proxy Pod]
        end

        subgraph AI workloads
            vLLM[vLLM / SGLang \n (Text Generation)]
            Triton[NVIDIA Triton \n (CV/Embeddings)]
        end
        
        xDS <===> |Dynamic xDS Stream| EnvoyPod1
        xDS <===> |Dynamic xDS Stream| EnvoyPod2
        
        EnvoyPod1 ---> vLLM
        EnvoyPod2 ---> Triton
    end

    Client ===> |Load Balancer (e.g. AWS ALB)| EnvoyPod1
    Client ===> |Load Balancer| EnvoyPod2

4.2 架构流金步骤解析

  1. 基础设施编排（Provider Orchestration）：当你创建了一个 Gateway 对象后，Envoy Gateway 控制面会发现它，并主动为你拉起（Provision）一个由 Envoy Proxy 组成的 Deployment 或 DaemonSet（即数据面）。你甚至不需要手写 Envoy 的 YAML。
  2. 侦听与翻译（Watch & Translate）：当算法工程师创建了 HTTPRoute 或扩展策略（如 RateLimit 策略）。这部分配置会被 Translator 读取，并根据高度复杂的拓扑组合，转换为 Envoy 底层的 Listener、RouteConfiguration、Cluster、Endpoint 数据结构。
  3. xDS 推送（Push）：基于双向流式 gRPC 长连接，控制面在一瞬间将上述变更推送给所有的 Envoy 代理。新的路由配置在纳秒级生效，不会遗漏和中断任何正在流式吐字的 LLM 请求。

5. 面向 AI 平台的关键技术细节（硬核深水区）

作为整个机器学习平台架构对外的心脏部位，我们来看看如何利用 Envoy Gateway 的高阶特性来攻克实际的痛点。

5.1 GRPCRoute 与多路复用支持体验

在计算机视觉（CV）或高并发特征向量抽取（Embedding）的推断时，NVIDIA Triton Server 通常被应用在集群内部。外部请求如何以 gRPC 安全穿透网关？传统的 HTTP / REST 往往损失性能。

Gateway API 原生提供 GRPCRoute 抽象。Envoy 是处理 HTTP/2（gRPC的传输层）的王者。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: triton-route
spec:
  parentRefs:
  - name: eg-gateway
  rules:
  - matches:
    - method:
        service: "inference.GRPCInferenceService"  # 精确匹配 Triton 的 protobuf service namespace
        method: "ModelInfer"
    backendRefs:
    - name: triton-inference-svc
      port: 8001

这个配置非常优雅。Envoy Gateway 在底层翻译时，会自动在 Envoy 中配好相应的 application/grpc 头检测协议，并在向上游（Upstream）发起请求时进行连接池（Connection Pool）的高效管理和重用，避免创建连接风暴。

5.2 模型更新时的 Traffic Splitting (流量切分与灰度测试)

AI 模型存在非常高频的迭代（如重新针对特定领域数据微调出来的 Llama3-v2 模型）。如果直接做替换部署，模型表现拉胯或幻觉（Hallucination）会导致非常严重的业务灾难。我们迫切需要在网关层实现 A/B Testing 和 **金丝雀发布 (Canary Release)**。

使用 Envoy Gateway，在权重切流方向极其直白：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: llm-chat-route
spec:
  parentRefs:
  - name: eg-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1/chat/completions
    backendRefs:
    - name: vllm-llama3-v1-svc
      port: 8000
      weight: 95   # 95% 老模型，作为稳流
    - name: vllm-llama3-v2-svc
      port: 8000
      weight: 5    # 5% 的新微调模型测试

Envoy Gateway 充分利用 Envoy 内部路由表的高级随机数与哈希功能，在数据面实现了不丢包的无损精确流量按比例分发。当监控大盘显示新模型 TTFT (首字延迟) 及输出正常后，算法开发者只需 kubectl apply 更新上述 weight 数值，直至逐渐切换至 100%。

5.3 进阶绝杀：Traffic Mirroring (流量镜像用于离线基准测试)

相比于 Canary 的让真实用户承担新模型测试风险。很多严谨的 AI 平台采用 Shadow Traffic（影子流量/流量镜像） 进行安全测试。
将生产环境极其珍贵的“真实 Prompt 请求”，在网关层拷贝（复制）一份，异步扔给还在测试的 V2 模型集群收集结果表现。同时主线业务丝毫不受影响（只返回 V1 的结果）。

Gateway API 提供的 RequestMirror Filter 被 Envoy 完美支持，实现了异步并发无阻塞的流量镜像，这相当于给 MLOps 流水线白送了一个最强的线上流量捕获神器！

5.4 OIDC 与高强度全局限流 (Global Rate Limiting)

大模型的 API 接口具有极高的金融属性（每一个 Token 都是显卡在燃烧的电费）。如果没有极高强度的网关兜底，DDoS 攻击或者某个开发者的死循环脚本会瞬间将系统的 GPU 把打冒烟。

Envoy Gateway 包含两个利器：

  1. OIDC 与 JWT 认证：通过 Gateway 挂载的 SecurityPolicy 或 ClientTrafficPolicy，可以在流量进入内网前，由 Envoy 拦截该请求并校验 JWT Token，提取 Payload 里的 user_id 等租户声明。
  2. Global Rate Limiting：传统的 NGINX Ingress 其限流往往是节点级（Local）的。当 NGINX 扩容至 3 个 Pod 后，单机限制 10qps，全局实际能放行 30qps。
    Envoy Gateway 原生整合了基于 Redis 的 Envoy RateLimit Service。

AI 平台典型限流实践策略配置思路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
  name: ai-api-limit
spec:
  targetRef:
    group: ""
    kind: Service
    name: openai-compatible-api
  rateLimit:
    type: Global
    global:
      rules:
      - clientSelectors:
        - headers:
          - name: "X-User-Tier" # 如果前面的鉴权层写入了用户等级段位
            value: "Free"
        limit:
          requests: 50
          unit: Minute

在这个配置下，控制面指令 Envoy 遇到匹配的用户请求时，使用 gRPC 高速呼叫公共的限流服务集群（Redis做状态维持）。不论 Envoy 数据面扩展到几百个 Pod，基于 user_id 的 50次/分钟 请求阈值都是绝对精确且穿透整个集群的。

5.5 WASM (WebAssembly) 可扩展能力：网关层定制的神助攻

AI 原生的业务场景花样百出，有些企业希望在网关层就校验前端传入的 Request Body 中是否包含非法词汇，或者想在网关处计算出一次流式请求究竟吐出了多少个 data:块落子进行计费（Metering）。
如果重写网关难度登天，传统的 Lua 脚本又面临极度恶劣的性能和不可维护性。此时通过 Envoy Gateway 对 WASM (WebAssembly) 的一等公民支持，即可化腐朽为神奇。

工程师可以用 Rust, Go 甚至 C++ 编写极度高性能的、运行在沙盒中的 Wasm 滤镜模型：
例如：用 Rust 写一个针对 /v1/chat/completions 这个 Endpoint 抓包并发送到计费 Kafka 集群的插件，编译成了 .wasm 挂载到 Gateway 对象下生效。由于这跑在 Envoy 虚拟机内，所以不会引起丝毫的崩溃风险。

6. 总结：Envoy Gateway 对于 AI 基础设施的真正价值

纵观全文，从 K8s 异构设备管理，到底层的调度大盘，所有的基建如果没有统一的网络入口，就都是一片散沙。

Envoy Gateway 重塑了 AI 机器学习平台的北大门：

  1. 对于算法人员 / MLOps：K8s Gateway API 高度解耦让算法组不再依赖运维就可以安全、隔离地宣告、切面、灰度甚至是镜像他们刚刚微调训练所得的模型。
  2. 对于平台架构师：依靠底仓极其成熟稳定的 Envoy，他们彻底告别了曾经基于 NGINX Ingress 在应对 gRPC 流式多路复用时由于频繁 reload 带来的微断和雪崩；更是收获了金融级的高精度全局限流（RateLimit）与监控探针体系。
  3. 未来的遐想：结合云原生生态（如我们前文提到的专注在模型层感知路由的 Aibrix），Envoy Gateway 提供的是绝对坚实的下盘网络平面，将 L4/L7 协议控制做到了极致。

在这个万物大模型、生成式架构狂奔的年代，拥有一个在海量长链接并发前不动如山的网关——Envoy Gateway，正是你的 AI 基础设施从“野路子”迈向“企业级”的核心加冕之路。