Envoy 代理对于管理和保护云原生和 Kubernetes 应用程序至关重要。了解为什么需要 Envoy 代理及其架构、功能和优势。
本文将涵盖以下主题:
- 为什么需要 Envoy 代理?
- 介绍 Envoy 代理
- 使用 Istio 的 Envoy 代理架构
- Envoy 代理功能
- Envoy 代理的用例
- Envoy 代理的好处
- 演示视频 - 在 K8s 中部署 Envoy 并配置为负载均衡器
为什么需要Envoy代理?
对于将应用程序从单体架构迁移到微服务架构的组织来说,挑战很多。管理和监控 Kubernetes 和公共云中数量庞大的分布式服务通常会让应用程序开发人员、云团队和 SRE 筋疲力尽。以下是微服务的一些主要网络级操作麻烦,这说明了为什么需要 Envoy 代理。
缺乏安全网络连接
Kubernetes 本身并不安全,因为服务之间可以自由通信。它对基础设施构成了巨大威胁,因为获得 pod 访问权限的攻击者可以在网络中横向移动并危及其他服务。这对安全团队来说可能是个大问题,因为更难确保敏感数据的安全性和完整性。此外,传统的基于边界的防火墙方法和入侵检测系统在这种情况下也无济于事。
遵守安全策略是一个巨大的挑战
世界上没有开发人员会喜欢编写安全逻辑来确保身份验证和授权,而不是集思广益地解决业务问题。但是,想要遵守 HIPAA 或 GDPR 等政策的组织会要求其开发人员在其应用程序中编写安全逻辑,例如 mTLS 加密。企业中的此类案例将导致两种后果:沮丧的开发人员,以及在本地和孤岛中实施的安全策略。
由于复杂的网络拓扑而缺乏可见性
通常,微服务分布在多个 Kubernetes 集群和云提供商中。集群边界内和跨集群边界的这些服务之间的通信将很快形成复杂的网络拓扑。因此,运维团队和 SRE 很难了解网络,这阻碍了他们及时识别和解决网络问题的能力。这将导致频繁的应用程序停机和 SLA 受损。
复杂的服务发现
服务通常在动态微服务环境中创建和销毁。老一代代理提供的静态配置无法有效地跟踪此类环境中的服务。这使得应用工程师很难配置服务之间的通信逻辑,因为每当部署或删除新服务时,他们都必须手动更新配置文件。它导致应用程序开发人员将更多时间花在配置网络逻辑上,而不是编码业务逻辑上。
低效的负载平衡和流量路由
对于平台架构师和云工程师来说,确保服务之间的有效流量路由和负载平衡至关重要。然而,他们为每个服务手动配置路由规则和负载均衡策略是一个耗时且容易出错的过程,尤其是当他们拥有大量服务时。此外,在微服务的情况下,具有简单算法的传统负载均衡器会导致资源利用效率低下和负载均衡不佳。由于不正确的流量路由,所有这些都会导致延迟增加和服务不可用。
随着采用微服务架构的兴起,需要一种快速、智能的代理来处理跨云的复杂服务到服务连接。
介绍 Envoy 代理
Envoy是一个开源边缘和服务代理,最初由Lyft开发,以促进他们从单体架构迁移到云原生微服务架构。它还作为微服务(参见下图 1)跨云端的通信总线,使它们能够以快速、安全和高效的方式相互通信。
Envoy 代理将网络和安全从应用程序层抽象到基础设施层。这有助于应用程序开发人员通过节省配置网络和安全逻辑所花费的时间来简化云原生应用程序的开发。
Envoy 代理提供高级负载平衡和流量路由功能,这些功能对于运行大型、复杂的分布式应用程序至关重要。此外,Envoy 的模块化架构有助于云和平台工程师定制和扩展其功能。

图 1:Envoy 代理拦截服务之间的流量
Istio 的 Envoy 代理架构
Envoy 代理与应用程序容器一起部署为边车容器。然后,Sidecar 代理会拦截并处理服务到服务的连接(请参阅下面的图 2)并提供各种功能。这个代理网络称为数据平面,它是从 Istio 提供的控制平面进行配置和监控的。这两个组件共同构成了 Istio 服务网格架构,它提供了一个强大而灵活的基础设施层来管理和保护微服务。

图 2:带有 Envoy 代理数据平面的 Istio sidecar 架构
特使代理功能
Envoy 代理提供以下高级功能。(有关下面列出的功能的更多信息,请访问Envoy 文档。)
- 进程外架构:Envoy 代理独立于应用程序进程之外作为单独的进程运行。它可以部署为边车代理,也可以部署为网关,而无需对应用程序进行任何更改。Envoy 还兼容任何应用程序语言,如 Java 或 C++,这为应用程序开发人员提供了更大的灵活性。
- L3/L4 和 L7 过滤器架构:Envoy 支持过滤器并允许在网络层 (L3/L4) 和应用层 (L7) 自定义流量。这允许对网络流量进行更多控制,并提供精细的流量管理功能,例如 TLS 客户端证书身份验证、缓冲、速率限制和路由/转发。
- HTTP/2 和 HTTP/3 支持:Envoy 支持 HTTP/1.1、HTTP/2 和 HTTP/3(目前处于 alpha 阶段)协议。这使得使用不同版本的 HTTP 的客户端和目标服务器之间能够进行无缝通信。
- HTTP L7 路由:Envoy 的 HTTP L7 路由子系统可以根据路径、权限和内容类型等各种标准路由和重定向请求。此功能对于构建前端/边缘代理和服务到服务网格很有用。
- gRPC 支持:Envoy 支持 gRPC,这是一个使用 HTTP/2 或更高版本作为其底层传输的 Google RPC 框架。Envoy 可以充当 gRPC 请求和响应的路由和负载平衡基础。
- 服务发现和动态配置:Envoy 通过一组分层的 API 支持服务发现和动态配置,这些 API 提供有关后端主机、集群、路由、侦听套接字和加密材料的动态更新。这允许集中管理和更简单的部署,具有 DNS 解析或静态配置文件的选项。
- 健康检查:为了构建 Envoy 网格,服务发现被视为最终一致的过程。Envoy 有一个健康检查子系统,可以执行主动和被动健康检查以确定健康的负载平衡目标。
- 高级负载均衡:Envoy 的自包含代理架构允许它在一个地方实现高级负载均衡技术,例如自动重试、断路、请求阴影和异常值检测,任何应用程序都可以访问。
- 前端/边缘代理支持:在边缘使用相同的软件可提供诸如可观察性、管理以及相同的服务发现和负载平衡算法等优势。Envoy 的功能集使其非常适合作为大多数现代 Web 应用程序用例的边缘代理,包括 TLS 终止、支持多个 HTTP 版本和 HTTP L7 路由。
- 一流的可观察性:Envoy 为所有子系统提供强大的统计支持,并支持通过第三方提供商进行分布式跟踪,使 SRE 和 Ops 团队更容易监控和调试网络和应用程序级别发生的问题。
鉴于其强大的功能集,Envoy 代理已成为组织管理和保护多云和多集群应用程序的热门选择。实际上,它有两个主要用例。
Envoy 代理的用例
Envoy 代理既可以用作 sidecar 服务代理,也可以用作网关。
Envoy 边车代理
正如我们在 Isito 架构中看到的,Envoy 代理构成数据平面并管理部署在网格中的服务之间的流量。sidecar 代理提供服务发现、负载均衡、流量路由等功能,并为微服务网络提供可见性和安全性。
特使网关作为 API
Envoy 代理可以部署为 API 网关和入口(请参阅Envoy 网关 项目)。Envoy Gateway 部署在集群边缘,用于管理流入集群和多云应用程序之间的外部流量(南北流量)。Envoy Gateway 帮助应用程序开发人员将 Envoy 代理(Istio-native)配置为 API 和入口控制器,而不是购买像 NGINX 这样的第三方解决方案。通过其实施,他们拥有一个中央位置来配置和管理入口和出口流量,并应用身份验证和访问控制等安全策略。
下面是 Envoy Gateway 架构及其组件的图表。

Envoy 网关架构( 来源)
Envoy 代理的好处
Envoy 抽象网络和安全层的能力为 IT 团队(例如开发人员、SRE、云工程师和平台团队)提供了多项优势。以下是其中的一些。
有效的网络抽象
Envoy 的进程外架构帮助它将网络层从应用程序抽象到它自己的基础设施层。这允许应用程序开发人员更快地部署,同时还提供一个中央平面来管理服务之间的通信。
细粒度流量管理
Envoy 支持网络 (L3/L4) 和应用程序 (L7) 层,提供灵活、细粒度的流量路由,例如流量拆分、重试策略和负载均衡。
确保 L4/L7 层的零信任安全
Envoy 代理通过 mTLS 和 JWT 等更强大的身份验证机制帮助实现集群内服务之间的身份验证。使用Envoy代理可以轻松实现L7层授权,保证零信任。(您可以使用 Istio 服务网格(Envoy 的控制平面)实施 AuthN/Z 策略。)
控制多云应用程序的东西向和南北向流量
由于企业将其应用程序部署到多个云中,因此了解和控制进出数据中心的流量或通信非常重要。由于 Envoy 代理既可以用作 sidecar,也可以用作 API 网关,因此它可以分别帮助管理东西向流量和南北向流量。
监控流量并确保最佳平台性能
Envoy 旨在通过发出统计信息使网络易于理解,这些统计信息分为三类:传入请求的下游统计信息、传出请求的上游统计信息以及用于描述 Envoy 服务器实例的服务器统计信息。Envoy 还提供日志和指标,以深入了解服务之间的流量,这也有助于 SRE 和 Ops 团队快速检测和解决任何性能问题。