本文将探讨 Envoy Gateway 在 Kubernetes 上部署的优势，及其它与服务网格的关系，展示为何它是暴露服务到公网的理想选择。
在 Kubernetes 环境下选择正确的网络通信工具至关重要。根据Tetrate 的讨论，选择取决于网络通信的类型：南北向流量还是东西向流量。对于主要处理外部请求的服务，Envoy Gateway 是理想选择，它不仅高效管理流量，还能在你向微服务架构过渡时提供无缝集成。
本文将探讨 Envoy Gateway 在 Kubernetes 上部署的优势，及其它与服务网格的关系，展示为何它是暴露服务到公网的理想选择。
Envoy Gateway 及其在服务网格中的角色概述
Envoy Gateway 是一个围绕 Envoy Proxy 构建的 Kubernetes 原生 API 网关，它旨在降低用户采用 Envoy 作为 API 网关的难度，并为供应商建立 API 网关（例如 Tetrate Enterprise Gateway for Envoy）增值产品奠定基础。
Envoy Gateway 不仅是管理南北流量的理想选择，也可作为连接和保护服务网格中服务的关键组件。它还通过提供安全的数据传输、流量路由、负均衡及故障恢复等功能，增强了微服务之间的通信效率和安全性。Envoy Gateway 利用其内置的 Envoy Proxy 技术，可以处理大量的并发连接和复杂的流量管理策略，同时保持较低的延迟和高吞吐量。
此外，Envoy Gateway 与 Kubernetes Gateway API 的紧密集成使得它能够以声明式的方式进行配置和管理，极大简化了服务网格中网关的部署和更新过程。这种集成不仅提升了操作效率，还使得 Envoy Gateway 能够在不增加额外复杂性的前提下，与服务网格如 Istio 这样的解决方案无缝协作。
下图展示了 Envoy Gateway 与服务网格的关系。
在 Kubernetes 集群中，Envoy Gateway 负责管理南北向流量，即进出集群的流量，并通过 Kubernetes Gateway API 进行配置，后者定义了服务的路由规格。集群内服务直接连接到 Pods。服务网格部分，由控制平面（如 Istio 或 Linkerd）配置数据平面中的 Envoy Sidecars，这些 Sidecars 负责处理集群内部的东西向流量。在这个系统中，Envoy Gateway 可以与服务网格相互协作，但它们各自独立地管理不同方向的流量。
设想一下，Envoy Gateway 像是一个城市的主要入口（比如海关），所有的数据流，就像各种车辆，都得通过这个大门进出。它就像一个严格的守门员，负责审查、指导，确保每个数据包，就像每个乘客，都能被准确地送到目的地。在 Kubernetes 这座城市中，Envoy Gateway 管理着所有进城的流量，它确保数据流可以安全、高效地进入城市，并被准确地送达给城市内部的服务。
进入城市之后，服务网格就接管了，这就像城市内部的一系列交通网络。服务网格中的 Envoy sidecars 就好比是这座城市内部的出租车或者公交车，负责把数据包从海带到它们在城市内部的具体目的地。Envoy Gateway 负责将外部请求顺利引入，之后服务网格负责在集群内部继续高效地处理这些请求。
Envoy Gateway 对 Kubernetes Gateway API 的支持，可以看作是对我们城市交通信号系统的一个重大升级。这不仅为进入城市的数据流提供了更加清晰和个性化的指引，而且让整个城市的交通运行更加智能化。
Envoy Gateway 的核心功能和优势
Envoy Gateway 提供了几个核心功能，使其成为 API 网关的突出选择：
• 简化配置：通过与 Kubernetes Gateway API 直接集成，Envoy Gateway 允许开发者使用 Kubernetes 自定义资源以声明方式配置路由规则、安全策略和流量管理。
• 性能和可扩展性：基于经过实战测试的 Envoy Proxy，它提供卓越的性能和可扩展性，轻松处理数千个服务和每秒数百万个请求。
• 安全功能：内置支持各种安全措施，如 SSL/TLS 终止、OAuth2、OIDC 认证以及细粒度访问控制。
• 可观测性：提供全面的监控能力，包括详细的度量、日志和追踪，这对于诊断和理解流量行为至关重要。
与 Gateway API 的关系
在 Kubernetes 环境中引入的 Gateway API 为集成和配置 Ingress 网关提供了一种新的强大方法，它与传统的 Ingress 相比具有更高的灵活性和功能性。正如我在 Gateway API：Kubernetes 和服务网格入口中网关的未来 中所讨论的，Gateway API 通过区分角色和提供跨命名空间支持，更适应多云环境，且已被多数 API 网关采用。这种 API 设计支持了 ingress 网关（南北向流量）与服务网格（东西向流量，跨集群路由）的融合，使得 Envoy Gateway 成为 Kubernetes 和服务网格中统一未来的网关解决方案。通过引入 Gateway API，Envoy Gateway 强化了其作为云原生环境中前沿代理的角色，使得用户能够更灵活地管理其流量和策略。
Kubernetes Gateway API 是 Envoy Gateway 的基石，它提供了一种更具表达性、灵活性和以角色为导向的方式来配置 Kubernetes 生态系统中的网关和路由。该 API 提供了如 GatewayClass、Gateway、HTTPRoute 等自定义资源定义（CRD），Envoy Gateway 利用这些资源创建用户友好且一致的配置模型，与 Kubernetes 的原生原则保持一致。
Envoy Gateway 架构概览
Envoy Gateway 的架构设计旨在轻量级和简洁。它包括一个动态配置运行作为数据平面的 Envoy 代理的控制平面。这种关注点的分离确保了网关可以随着流量的增长而扩展，而不影响控制平面的效率。
Envoy Gateway 的架构图如下所示。
在这个架构图的核心是 Envoy Gateway，它是 Envoy 代理的执行实例，负责处理从 Kubernetes 集群进出的所有流量。初始启动时，Envoy Gateway 通过配置文件提供静态配置，建立其操作的基本参数。
Envoy Gateway 配置的动态方面由提供者处理，该提供者定义了网关与 Kubernetes 或其他动态配置输入源的交互。资源监视器负责监视 Kubernetes 资源的更改，特别关注与自定义资源定义（CRD）相关的 CRUD 操作。
随着更改的发生，资源转换器介入将这些外部资源转换为 Envoy Gateway 可以理解的形式。这一转换过程进一步由特定于提供者的基础设施管理器促进，后者负责管理与特定云或基础设施提供商相关的资源，塑造中间表示形式的基础设施，这对于网关的功能至关重要。
然后，该中间表示形式转变为 xDS 中间表示形式，作为 Envoy 理解和执行的最终 xDS 配置的先导。xDS 翻译器承担将这种中间表示形式转换为具体的 xDS 配置的角色。
这些配置由 xDS 服务器交付并执行，该服务器作为服务，根据其收到的 xDS 配置，认真管理 Envoy 实例。Envoy 作为实际运行的代理，最终从 xDS 服务器接收这些配置，解释并实现它们以有效管理流量请求。
最终，所有请求经过 Envoy 的处理后被重定向到了 Envoy Gateway 路由的流量的最终目的地，也就是后端服务。
与其他网关的比较
与 Istio 的入口网关或 NGINX Ingress 等其他流行解决方案相比，Envoy Gateway 凭借其与 Kubernetes 的原生集成以及利用 Envoy 全部潜力的专注，而脱颖而出。下图从多方面对比了目前流行的一些开源的 API 网关。
| API 网关 | 支持的认证和授权策略 | 支持的服务发现组件 | 支持的协议 | 控制平面配置分发方法 | 支持的插件扩展机制 | 组织隶属 |
| Envoy Gateway | OAuth2, JWT, mTLS, OIDC | Kubernetes, EDS | HTTP, HTTPS, gRPC | xDS | 基于 Envoy Filter 的 | CNCF |
| Kuma | mTLS, JWT | Kubernetes, Consul | HTTP, HTTPS, gRPC, TCP | REST, gRPC | 基于 Lua, Go 的 | CNCF |
| NGINX Ingress | RBAC | Kubernetes | HTTP, HTTPS, TCP, UDP | Kubernetes CRD | 基于 Nginx 模块的 | N/A |
| APISIX | OAuth2, JWT, Key Auth, Basic Auth, mTLS, OIDC, LDAP, OpenID 等 | Kubernetes, DNS, Consul, Nacos, Eureka | HTTP, HTTPS, TCP, UDP, WebSocket | REST, CLI, Web UI | 基于 Lua, Wasm 的 | Apache Software Foundation |
| Kong | OAuth2, JWT, Basic Auth, Key Auth | Kubernetes, DNS, Consul | HTTP, HTTPS, gRPC, WebSocket | REST, gRPC, Web UI | 基于 Lua 的 | N/A |
| Emissary | Basic Auth | Kubernetes | HTTP, HTTPS, gRPC | Kubernetes CRD | 基于 Lua, Go 的 | CNCF |
快速开始使用 Envoy Gateway
要快速上手 Envoy Gateway，你可以通过以下简化步骤快速搭建一个本地实验环境。首先，启动一个本地 Kubernetes 集群：
minikube start --driver=docker --cpus=2 --memory=2g接下来，部署 Gateway API CRD 和 Envoy Gateway 本身：
helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.0.1 -n envoy-gateway-system --create-namespace然后，安装网关配置并部署一个示例应用：
kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.0.1/quickstart.yaml -n default为了暴露 LoadBalancer 服务，这里我们使用端口转发作为示例。你也可以选择使用 minikube tunnel 或安装 MetalLB 作为负载均衡器：
export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}')
kubectl -n envoy-gateway-system port-forward service/${ENVOY_SERVICE} 8888:80 &通过以下命令测试你的 Envoy Gateway 是否正常工作：
curl --verbose --header "Host: www.example.com" http://localhost:8888/get想了解更多详细的安装和配置步骤，请访问 Envoy Gateway 网站。通过这些步骤，你可以快速开始探索 Envoy Gateway 的功能。
结论
Envoy Gateway 不仅优化了云原生时代的七层网关配置，而且为从边缘网关向服务网格过渡提供了一个平滑的道路。由于服务网格的推广面临一些挑战，如对应用的侵入性和运维团队推动问题，边缘网关则更易于被开发团队接受。Envoy Gateway 采用简化的 Kubernetes Gateway API，提高了流量管理和可观察性的能力。此外，Envoy Gateway 到 Istio 的过渡对于已熟悉 Envoy 功能的团队来说，将是一个自信的技术进步，同时还支持从标准的 Kubernetes Gateway API 到 Istio Ingress Gateway 的无缝切换，或者作为一个定制解决方案继续与 Istio 协作。这些特点使得 Envoy Gateway 成为一个在云原生时代值得投资的网关选择。
请继续关注本系列博客的后续部分，我们将深入探讨如何配置和优化 Envoy Gateway，提供实用指南并展示更广泛的实际应用案例。
