超越网关API（第二部分）：如何扩展Envoy ... - Tetrate

背景

Kubernetes 网关 API 是下一代 Kubernetes Ingress 的替代方案，它提供了比传统 Ingress API 更强大的表现力和可扩展性。网关 API 的一个显著优势是其策略附件（Policy Attachment）机制，这种显式扩展方式允许控制器通过自定义策略扩展功能，而无需直接修改网关 API 本身。

在本系列的第一篇文章中，我们探讨了 Kubernetes 网关 API 相较于 Ingress API 的优势，以及策略附件机制在 Envoy 网关中的具体实现方式。

本文将进一步深入研究 Envoy 网关的扩展功能，并探讨它们如何为 Kubernetes 应用程序提供更多附加功能。我们还将介绍 如何为 Envoy Gateway 开发自定义扩展（包括 Wasm 和外部进程扩展），以及 如何使用 EnvoyPatchPolicy 应用 Envoy 配置补丁。

EnvoyExtensionPolicy：自定义扩展

虽然 Envoy Gateway 提供了丰富的流量管理功能，但其内置功能可能无法满足某些特定需求。在这种情况下，您可以通过 EnvoyExtensionPolicy 来扩展 Envoy 的功能。此策略允许您加载自定义扩展，以实现用户定义的请求和响应处理逻辑。

EnvoyExtensionPolicy 支持以下两种扩展类型：

WebAssembly（Wasm）扩展：Wasm 是一种高性能的二进制格式，可以在 Envoy 中运行。用户可以通过 Wasm 实现自定义的请求和响应处理逻辑。
外部进程扩展：外部进程扩展允许用户通过独立的外部服务处理请求和响应。Envoy Gateway 通过远程过程调用（RPC）与这些外部进程通信。

WebAssembly（Wasm）扩展

Envoy Gateway 增强了对 Wasm 的原生支持，允许用户将 Wasm 扩展打包为 OCI 映像。这种方式使得用户可以将自定义 Wasm 扩展存储在容器注册表中，并通过 EnvoyExtensionPolicy 加载。

使用 OCI 映像的主要优势包括：

版本控制：通过图像标签指定扩展版本。
安全性：支持私有注册表存储，提供访问控制。
生态系统支持：可以利用广泛的 OCI 工具链来管理 Wasm 扩展。

此外，Envoy Gateway 还支持通过 HTTP URL 加载 Wasm 扩展。用户可以将 Wasm 扩展上传至 HTTP 服务器，并在策略中指定其 URL。

以下是两种加载 Wasm 扩展的示例：

左侧示例通过 OCI 映像加载扩展。
右侧示例通过 HTTP URL 加载扩展。

外部进程扩展

外部进程扩展是另一种扩展 Envoy Gateway 的机制。它允许用户通过独立的外部服务处理请求和响应。Envoy Gateway 通过 RPC 与这些外部进程通信，从而实现自定义逻辑。

当需要低网络延迟时，可以将外部进程扩展作为 sidecar 部署在与 Envoy Gateway 相同的 Pod 中。此部署模式使用本地 Unix 域套接字（UDS）替代 RPC 调用，从而显著降低延迟。

如下图所示，外部进程扩展与 Envoy 在同一 Pod 内运行，并通过 UDS 通信。用户需要创建后端资源来定义外部进程的 UDS 地址，并在 EnvoyExtensionPolicy 中引用该后端。

在 WebAssembly 和外部进程扩展之间进行选择

Wasm 和外部进程扩展各有优劣，选择时需要考虑以下因素：

性能：Wasm 扩展直接运行在 Envoy 进程中，性能更优。而外部进程扩展依赖网络调用，可能会导致性能下降，但通过 sidecar 部署可缓解这一问题。
功能：Wasm 运行在沙盒环境中，限制了系统调用和外部资源访问。外部进程扩展没有这些限制，可以使用任何编程语言实现，并完全访问系统资源。
部署：Wasm 扩展可直接从 OCI 注册表或 HTTP URL 加载，而外部进程扩展需要单独部署，增加了管理复杂性。
安全性：Wasm 扩展运行在 Envoy 内部，可能因扩展错误影响 Envoy 的稳定性。外部进程扩展运行在独立进程中，即使失败也不会影响 Envoy。
可扩展性：外部进程扩展可以独立扩展资源，而 Wasm 扩展需与 Envoy 一起扩展。

一般而言，Wasm 扩展适合轻量级的数据路径处理任务，而外部进程扩展更适合复杂的逻辑处理。选择应基于具体应用场景和需求。

EnvoyPatchPolicy：任意配置补丁

Envoy Gateway 通过网关 API 及其策略扩展简化了对 Envoy 的管理。然而，对于一些未涵盖的边缘用例，用户可以使用 EnvoyPatchPolicy 将任意补丁应用到生成的 Envoy 配置中，以满足特定需求。

工作原理

默认情况下，EnvoyPatchPolicy 是禁用的，必须在 Envoy Gateway 配置中显式启用。启用后，用户可以向生成的 Envoy 配置添加补丁，包括修改侦听器、集群和路由配置。

以下是一个示例：EnvoyPatchPolicy 修改了生成的 Listener default/eg/http，将 localReplyConfig 参数添加到过滤器链中。此更改将 404 错误响应代码更新为 406，并将响应正文设置为“找不到您要查找的内容”。

使用建议

EnvoyPatchPolicy 是一个强大的工具，但也存在一定风险，因为它依赖于生成配置的结构和字段命名，这些可能会随着 Envoy Gateway 的更新而变化。因此，建议仅在必要时使用，并注意以下情况：

当 Envoy Gateway 尚不支持某些新功能时，可使用 EnvoyPatchPolicy 作为临时解决方案。
当生成的配置不符合特定需求时，可通过 EnvoyPatchPolicy 进行调整。

在创建 EnvoyPatchPolicy 之前，建议使用 egctl 工具查看原始配置，以确定需要修改的部分。完成补丁后，还可使用 egctl 验证修补后的配置是否符合预期。

需要注意的是，升级 Envoy Gateway 可能会导致配置变化，从而影响现有的 EnvoyPatchPolicy。因此，在升级时，应审查并更新相关策略。

关键要点

Kubernetes 网关 API 是下一代 Ingress API，为集群入站流量管理提供了强大的功能。基于 Envoy 构建的 Envoy Gateway 完全支持网关 API，并通过扩展机制提供了更高的灵活性。

Envoy Gateway 提供了多种高级策略，包括 ClientTrafficPolicy、BackendTrafficPolicy、SecurityPolicy、EnvoyExtensionPolicy 和 EnvoyPatchPolicy。这些策略可以与网关 API 资源（如 Gateway、HTTPRoute 和 GRPRoute）结合使用，实现细粒度的流量控制。通过这些策略，用户可以优化客户端和后端连接行为，实施访问控制，并实现自定义扩展，从而充分释放 Envoy 在边缘流量管理中的潜力。

原文链接: https://tetrate.io/blog/beyond-gateway-api-part-2-how-to-expand-envoy-gateway-with-wasm-and-external-process-extensions/