【云原生 | Envoy 系列】--Envoy原理

1. 服务网格的部署模式

服务网格部署模式有两种:

1. 主机共享代理

   • 适用于同一主机上存在许多容器的场景,并且还可以利用连接池来提高吞吐量
   • 但一个代理进程故障将终止其所在主机上的整个容器队列,受影响的不仅仅是单个服务
   • 实现方式,常见的是运行为kubernetes之上的Daemonset

1. sidecar容器

• 代理进程注入每个Pod定义以与主容器一同运行
• Sidecar进程应该尽可能轻量且功能完善
• 实现方案: Linkerd,Envoy和Conduit

2. 未来云原生架构趋势

1. Lifecycle 生命周期管理: k8s
2. Networking 网络: Service Mesh 分布式的高级网络通信需求
3. Binding 绑定: Knative 专注于serverless,同时兼顾了服务编排和事件驱动的绑定需求
4. State 状态: Dapr 建立在k8s,knative和服务网格的思想之上,并深入应用程序运行时以解决状态化工作负载,绑定和集成的需求,充当现代分布式中间件.

3. Envoy 基本概念

3.1 Envoy 几个显著特性

1. 性能,可扩展性急动态可配置性

   - 性能: 除了大量功能外,Envoy还提供极高的吞吐量和低尾延迟差异,同时消耗相对较少的CPU和RAM
   - 可扩展性: Envoy在L4和L7上提供丰富的可插拔过滤器功能,允许用户轻松添加新功能
   

   • API可配置性: Envoy提供了一组可由控制平面服务实现的管理API,也称为xDS API
     • 若控制平面实现了这所有的API,则可以使用通用引导配置在整个基础架构中运行Envoy
     • 所有进一步的配置更改都可以通过管理服务器无缝地进行动态传递,使得Envoy永远不需要重新启动
     • 于是这使得Envoy成为一个通用数据平面,当与足够复杂的控制平面相结合时,可大大降低整体操作复杂性.

2. Envoy xDS API存在v1,v2和v3三个版本

• v1 API 仅使用JSON/REST,本质上是轮询,效率较低
• v2 API 是v1演进,而不是革命,它是v1功能的超集,新的API模式使用proto3指定,并同时以gRPC和REST+JSON/YAML端实现
• v3 API 当前支持的版本,支持start_tls,拒绝传入的tcp连接,4096位的tls秘钥,skywalking和WASM等

3. Envoy已成为现代服务网格和边缘网关的"通用数据平面API",Istio,ambassador和Gloo等项目均是为此数据平面代理提供控制平面

3.2 Envoy常见基础组件

1. LDS : Listener Discovery Service
2. CDS: Cluster Discovery Service
3. RDS: Route Discovery Service
4. EDS: Endpoint Discovery Service
5. SDS: Secret Discovery Service(私钥,证书)
6. VHDS: Virtual Host Discovery Service
7. HDS: Health Discovery Service
8. ADS: Aggregated Discovery Service
9. ECDS: Extension Config Discovery Service
10. CSDS: Client Status Discovery Service
11. RTDS: Runtime Discovery Service
12. RLS: Rate Limit Service
13. LRS: Load Reporting Service
14. ALS: AccessLog Service

3.3 Envoy API xDS常用术语

1. Host(主机): 一个具有网络通信能力的端点
2. Cluster(集群): 集群是Envoy连接到一个逻辑上相似的端点;在v2中,RDS通过路由指向集群,CDS提供集群配置,而Envoy通过EDS发现集群成员,即端点.
3. Downstream下游: 下游主机连接到Envoy,发送请求并响应,它们是Envoy的客户端.
4. Upstream上游: 上游主机接收来自Envoy的连接和请求并返回响应,它们是Envoy代理的后端服务器.
5. Endpoint端点: 即上游主机,是一个或多个集群的成员,可通过EDS发现
6. Listener侦听器: 是能够由下游客户端连接的命名网络位置.如:端口,unix套接字等
7. Locality位置: 上游端点运行的区域拓扑,包括地域,区域和子区域等
8. Management Server管理服务器: 实现v2 API的服务器,它支持复制和分片,并且能够在不同的物理机上实现针对不同xDS API的API服务
9. Region地域: 区域所属地理位置
10. Zone区域: AWS中的可用区AZ或GCP中的区域等
11. Sub Zone子区域: Envoy实例或端点运行的区域内的位置,用于支持区域内的多个负载均衡目标
12. xDS: CDS,EDS,HDS,LDS,RLS,RDS,SDS,VHDS,RTDS等API的同城
13. Mesh和Envoy Mesh

3.4 Deployment type

1. Front Proxy访问单个Service: Envoy访问ServiceA的边车的Ingress Listener,Sidecar将请求转发给ServiceA.

2. 访问调用其他Service的Service: Envoy访问Ingress,Ingress将请求转给ServiceA,ServiceA对ServicerB有请求,ServiceA通过Egress Listener将请求正向代理到ServiceB的Ingress Listener,再有Ingress 将求情反向代理给ServiceB

3. 访问有外部调用的Service: Envoy访问Ingress,Ingress将请求转给ServiceA,ServiceA对外部(External Service)有请求,ServiceA通过Egress Listener将请求正向代理到Egress网关,再有Egress网关转发到外部,并由外部的External Service进行应答响应
   

4. Envoy配置概述

1. 启动时从Bootstrap 配置文件中加载初始配置
2. 支持动态配置
   • xDS API
     从配置文件加载配置
     从管理服务器基于xds协议加载配置
   • runtime
     某些关键特性保存为k/v数据
     支持多层配置和覆盖机制
3. 启用全动态配置机制后,仅极少数场景需要重新启动Envoy进程
   • 支持热启动

4.1 Envoy的配置方法

Envoy的架构支持多种配置方法,常见的有:

1. 纯静态配置: 用户自行提供侦听器,过滤器链,集群及HTTP路由(http代理场景),上游端点的发现仅可通过DNS服务器进行,且配置的重新加载必须通过内置的热启动完成
2. 仅使用EDS: EDS提供的端点发现功能可以有效的规避DNS的限制(响应中的最大记录数等)
3. 使用EDS和CDS: CDS能够让Envoy以优雅的方式添加,更新和删除上游集群,于是,初始配置时,Envoy无需事先了解所有上游集群.
4. EDS,CDS和RDS: 动态发现路由配置,RDS与EDS,CDS一起使用时,为用户提供了构建复杂路由拓扑的能力(流量转移,蓝绿发布等)
5. EDS,CDS,RDS和LDS: 动态发现侦听器配置,包括内嵌的过滤器链,启用此4种发现服务后,除了罕见的配置变动,证书轮替或更新Envoy程序之外,几乎无需再热重启Envoy
6. EDS,CDS,RDS,LDS和SDS: 动态发现侦听器秘钥相关的证书,私钥及TLS会话票据,以及对证书验证逻辑配置(受信任的根证书和撤销机制等.)

4.2 Envoy配置中的重要概念

4.2.1 Bootstrap 配置中几个重要的基础概念

1. node: 节点标识,以呈现给管理服务区并且用于标识的目的
2. static_resources: 静态配置资源,用于配置静态的listener,cluster和secret
3. dynamic_resources: 动态配置资源,用于配置基于xDS API获取listener,cluster和secret配置的lds_config,cds_config,ads_config
4. admin: Envoy内置的管理接口
5. tracing: 分布式跟踪
6. layered_runtime: 层级化的运行时,支持使用RTDS从管理服务器动态加载
7. hds_config: 使用HDS从管理服务区加载上游主机健康状态监测相关的配置
8. overload_manager: 过载管理器
9. stats_sinks: 统计信息接收器

一般来说,侦听器和集群是最为常见的基础配置,无论是以静态或者是动态方式提供

4.2.2 Listener

1. 同一个Envoy实例可以配置多个侦听器
2. 每一个侦听器可以有多个虚拟主机
3. 侦听器需要借助过滤器链来处理请求,过滤器链中使用的过滤器分为:3/4层过滤器,7层过滤器

4.2.3 Cluster如何发现Endpoint

1. Static 通过静态配置直接给定IP和Port
2. 给定的是主机名称和端口,借助于DNS来将主机名称转成IP,一个主机名可以对应多个ip,ip与port的组合就是一个Endpoint
   • Strict DNS,严格DNS: 一个名称只会解析到有限个数的IP地址上.会把DNS解析结果中的所有ip配置为一个Endpoint
   • Logical DNS,逻辑DNS: 解析到不确定个数的地址.仅把DNS解析结果中的第一个IP配置为一个Endpoint
3. EDS: 通过基于GRPC和REST-JSON API的xDS管理服务器获取收集群成员的服务发现方式:
4. Original destination : 当传入连接通过iptables的REDIRRECT或TPROXY target或使用代理协议重定向到Envoy时,可以使用原始目标集群;
5. Custom cluster: Envoy还支持在集群配置上的cluster_type字段中指定使用自定义集群发现机制

4.3 Envoy连接处理

Envoy通过侦听器监听套接字并接收客户端请求,而Envoy的所有工作线程会同时共同监听用户配置的所有套接字,对于某次的连接请求,由内核负责将其派发至某个具体的工作线程处理,随后,相关的工作线程基于特定的处理逻辑分别有相关组件依次完成连接管理.

启用一个work接收用户请求,由listener过滤器进行处理,和客户端建立连接,交给tcp过滤器管理器进行处理.如果Read Fileter则交给TCP Read filters处理,通过Http codec解码,转发给Http manager.由Http Chttp_connection_manager Manager转发给Http 读过滤器,通过路由交给上游Endpoint.响应报文发送给连接池,经HTTP写过滤器封装返回给Http Connation Manager,再有http codec交给TCP写过滤器做TCP封装最终返回给客户端.

5. 常见的Envoy部署方法

1. 使用Docker image进行部署.配置文件默认/etc/envoy/envoy.yaml
2. 二进制,直接下载运行即可
3. 部署文档