WEBKT

手把手教你编写 EnvoyFilter：如何实现自定义的七层协议解析

5 0 0 0

在 Istio 的世界里，默认的 HTTP、gRPC、Redis 等协议支持已经涵盖了 90% 的场景。然而，当你面对企业内部深水区的私有 RPC 协议、旧版 SOA 架构或是特殊的安全校验逻辑时，Istio 的标准 API（如 VirtualService）往往显得力不从心。

这时候，你就需要祭出大杀器：EnvoyFilter。

EnvoyFilter 允许我们直接操作 Istio 底层的 Envoy 配置，通过插入自定义过滤器的方式，在 L7（应用层）对流量进行深度定制。今天，我们就通过实战，手把手教你如何利用 EnvoyFilter 实现自定义的七层协议逻辑。

一、 核心概念：什么是 EnvoyFilter？

Envoy 的核心是一个插件化的过滤器链。当一个请求进入 Envoy，它会依次经过：
Listener Filter -> Network Filter -> HTTP Filter。

EnvoyFilter 这个自定义资源（CRD）的作用，就是让你能以“非侵入”的方式，向这个链条中注入（Insert）、替换（Replace）或删除（Remove）特定的配置片段。

二、 场景设定：解析自定义 Header 协议

假设我们有一个内部协议，要求所有进入 Service A 的请求必须携带一个名为 x-magic-token 的 Header，且其值必须经过特定的 Base64 逻辑校验。如果校验失败，直接在网格入口拦截并返回 403。

由于这是业务相关的 L7 逻辑，Istio 默认的 RBAC 无法处理，我们需要编写一个 Lua 过滤器 并通过 EnvoyFilter 注入。

三、 编写 EnvoyFilter：四步走

1. 确定作用范围（Match）

首先，我们要告诉 Istio 这个滤器安装在哪个 Pod 上。

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-auth-filter
  namespace: istio-system # 如果想全局生效，放在 istio-system
spec:
  workloadSelector:
    labels:
      app: my-service # 仅作用于带有此标签的 Pod

2. 定位注入位置（Patch context）

我们要处理的是七层协议，所以位置应该选在 HTTP_FILTER。

  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: SIDECAR_INBOUND # 作用于进入 Sidecar 的流量
        listener:
          filterChain:
            filter:
              name: "envoy.filters.network.http_connection_manager"
              subFilter:
                name: "envoy.filters.http.router" # 在路由过滤器之前插入

3. 编写逻辑逻辑（The Lua Script）

我们利用 Envoy 内置的 Lua 引擎编写解析逻辑。

      patch:
        operation: INSERT_BEFORE
        value:
          name: envoy.lua
          typed_config:
            "@type": "type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua"
            inlineCode: |
              function envoy_on_request(request_handle)
                local token = request_handle:headers():get("x-magic-token")
                if token == nil or token ~= "open-sesame" then
                  request_handle:respond(403, "Invalid Magic Token", "text/plain")
                end
              end

4. 完整配置合并

将上述部分整合，你将得到一个完整的 EnvoyFilter 定义文件。应用此配置后，Envoy 会在处理 HTTP 请求的 pipeline 中动态加载这段 Lua 代码。

四、 深度进阶：从 Lua 到 WebAssembly (Wasm)

虽然 Lua 简单好用，但在高性能、高并发的生产环境下，Lua 脚本的执行效率和内存隔离性可能成为瓶颈。

更好的替代方案是 Wasm：

  1. 高性能：接近原生 C++ 的执行速度。
  2. 多语言支持：你可以用 Go (TinyGo)、Rust 或 C++ 编写解析逻辑。
  3. 安全性：Wasm 运行在沙箱中，即便脚本崩溃也不会导致整个 Envoy 进程宕机。

在 EnvoyFilter 中引用 Wasm 插件的方式与 Lua 类似，只需将 typed_config 指向你的 .wasm 文件或镜像地址即可。

五、 避坑指南：调试 EnvoyFilter 的正确姿势

编写 EnvoyFilter 最痛苦的是配置不生效或导致 Sidecar 闪崩。这里有几个实战技巧：

  1. 配置校验：在 kubectl apply 之前，先看 Istio 日志。如果 EnvoyFilter 格式错误，Istiod 会在日志中报错。
  2. 查看运行配置：
    使用命令查看 Envoy 实际加载的配置：
    istioctl proxy-config listener <pod-name> --port 8080 -o json
    搜索你的过滤器名称，确认它是否真的被插入到了 http_connection_manager 的链条中。
  3. 日志输出：在 Lua 或 Wasm 中多写 request_handle:logInfo()，这些日志会出现在 Sidecar 容器的标准输出中。

六、 结语

EnvoyFilter 是 Istio 的“逃生舱”，它赋予了开发者超越标准 API 的自由度。实现自定义七层协议解析，本质上是在寻找业务灵活性与系统性能之间的平衡点。

对于轻量级的逻辑，Lua EnvoyFilter 是快速上手的首选；而对于复杂的协议解析和高性能要求，Wasm 则是云原生时代的终极答案。

你在使用 EnvoyFilter 时遇到过哪些诡异的坑？欢迎在评论区交流。

云原生小记 Istio服务网格

评论点评