Mesh3# Envoy代理转发与xDS映射关系
引言
Envoy作为Istio默认数据面代理,它的工作流程是怎么样的?本文通过示例运行,走查其运行流程,以及xDS协议映射。
xDS 协议是“X Discovery Service”的简写,这里的“X”表示它不是指具体的某个协议,是一组基于不同数据源的服务发现协议的总称,包括 CDS、LDS、EDS、RDS等。在Istio架构中,基于xDS协议提供了标准的控制面规范,并以此向数据面传递服务信息和治理规则。在Envoy中,xDS被称为数据平面 API,并且担任控制平面Pilot和数据平面Envoy的通信协议。
CDS 是 Cluster Discovery Service的缩写,Envoy使用它在进行路由的时候发现上游Cluster。Envoy通常会优雅地添加、更新和删除 Cluster。有了 CDS 协议,Envoy在初次启动的时候不一定要感知拓扑里所有的上游Cluster。在做路由 HTTP 请求的时候通过在 HTTP 请求头里添加 Cluster信息实现请求转发。
EDS 即Endpoint Discovery Service 的缩写。在Envoy术语中,Endpoint即Cluster的成员。Envoy 通过 EDS API可以更加智能地动态获取上游Endpoint。
LDS 即Listener Discovery Service的缩写。基于此,Envoy 可以在运行时发现所有的Listener,包括 L3 和 L4 filter 等所有的 filter 栈,并由此执行各种代理工作,如认证、TCP 代理和 HTTP 代理等。添加 LDS 使得 Envoy 的任何配置都可以动态执行。
RDS 即 Router Discovery Service 的缩写,用于 Envoy 在运行时为 HTTP 连接管理 filter 获取完整的路由配置,比如 HTTP 头部修改等。并且路由配置会被优雅地写入而无需影响已有的请求。当 RDS 和 EDS、CDS 共同使用时,可以帮助构建一个复杂的路由拓扑蓝绿发布等。
ADS EDS,CDS 等每个独立的服务都对应了不同的 gRPC 服务名称。对于需要控制不同类型资源抵达 Envoy 顺序的需求,可以使用聚合发现服务,即 Aggregated xDS,它可以通过单一的 gRPC 服务流支持所有的资源类型,借助于有序的配置分发,从而解决资源更新顺序的问题。
备注:上述概念摘自 https://www.servicemesher.com/istio-handbook/ecosystem/xds.html
二、Envoy代理示例安装部署
以mac版本为例,安装看看
brew update
brew install envoy
版本检查
envoy --version
envoy version: a2a1e3eed4214a38608ec223859fcfa8fb679b14/1.19.1/Modified/RELEASE/BoringSSL
下载示例yaml文件
https://www.envoyproxy.io/docs/envoy/latest/_downloads/92dcb9714fb6bc288d042029b34c0de4/envoy-demo.yaml
示例运行
envoy -c envoy-demo.yaml
访问以下地址会路由转发到Envoy官方地址「www.envoyproxy.io」
http://localhost:10000/
三、逻辑走查envoy-demo.yaml文件走查
概念:
LDS(Listener Discovery Service):监听发现服务
RDS(Route Discovery Service):路由发现服务
CDS(Cluster Discovery Service):集群发现服务
EDS(Endpoint Discovery Service):集群成员发现服务
流程:
1.Listener通过监听端口(10000)将请求根据Route提供的策略转发
2.Route可以配置路由规则,示例中转发到名字为「service_envoyproxy_io」的cluster
3.Cluster中可以配置行为相同的多个EndPoint,多个EndPoint可以配置负载均衡策略
4.EndPoint最终转发的节点地址