Envoy 服务发现原理大揭秘与核心要点概述

Envoy_0">1 Envoy动态配置介绍

动态资源，是指由envoy通过xDS协议发现所需要的各项配置的机制，相关的配置信息保存于称之为管理服务器（Management Server ）的主机上，经由xDS API向外暴露；下面是一个纯动态资源的基础配置框架。

{
"lds_config": "{...}",
"cds_config": "{...}",
"ads_config": "{...}"
}

xDS API为Envoy提供了资源的动态配置机制，它也被称为Data Plane API。
Envoy支持三种类型的配置信息的动态发现机制，相关的发现服务及其相应的API联合起来称为xDS API。

基于文件系统发现：指定要监视的文件系统路径
通过查询一到多个管理服务器（Management Server）发现：通过DiscoveryRequest协议报文发送请求，并要求服务方以DiscoveryResponse协议报文进行响应
(1) gRPC服务：启动gRPC流
(2) REST服务：轮询REST-JSON URL

v3 xDS支持如下几种资源类型:

envoy.config.listener.v3.Listener
envoy.config.route.v3.RouteConfiguration
envoy.config.route.v3.ScopedRouteConfiguration
envoy.config.route.v3.VirtualHost
envoy.config.cluster.v3.Cluster
envoy.config.endpoint.v3.ClusterLoadAssignment
envoy.extensions.transport_sockets.tls.v3.Secret
envoy.service.runtime.v3. Runtime

2 DS API介绍

Envoy对xDS API的管理由后端服务器实现，包括LDS、CDS、RDS、SRDS（Scoped Route）、VHDS （Virtual Host）、EDS、SDS、RTDS（Runtime ）等。

所有这些API都提供了最终的一致性，并且彼此间不存在相互影响；
部分更高级别的操作（例如执行服务的A/B部署）需要进行排序以防止流量被丢弃，因此，基于一个管理服务器提供多类API时还需要使用聚合发现服务（ADS ）API。
ADS API允许所有其他API通过来自单个管理服务器的单个gRPC双向流进行编组，从而允许对操作进行确定性排序

xDS的各API还支持增量传输机制，包括ADS

3 Bootstrap node

一个Management Server 实例可能需要同时响应多个不同的Envoy实例的资源发现请求。

Management Server上的配置需要为适配到不同的Envoy实例
Envoy 实例请求发现配置时，需要在请求报文中上报自身的信息
- 例如id、cluster、metadata和locality等
- 这些配置信息定义在Bootstrap配置文件中
  专用的顶级配置段“node{…}”中配置

node:id: … # An opaque node identifier for the Envoy node. cluster: … # Defines the local service cluster name where Envoy is running.metadata: {…} # Opaque metadata extending the node identifier. Envoy will pass this directly to the management server .locality: # Locality specifying where the Envoy instance is running.region: …zone: …sub_zone: …user_agent_name: … # Free-form string that identifies the entity requesting config. E.g . “envoy ” or “grpc”
requesting config. E.g . “1.12.2” or “abcd1234” , or “SpecialEnvoyBuild ” user_agent_build_version: # Structured version of the entity requesting config.version: …metadata: {…}extensions: [ ] # List of extensions and their versions supported by the node.client_features: [ ]listening_addresses: [ ] # Known listening ports on the node as a generic hint to the management server for filtering listeners to be returned

在这里插入图片描述

4 API的流程

1、对于典型的HTTP路由方案，xDS API的Management Server 需要为其客户端（Envoy实例）配置的核心资源类型为Listener、RouteConfiguration、Cluster和ClusterLoadAssignment四个。每个Listener资源可以指向一个RouteConfiguration资源，该资源可以指向一个或多个Cluster资源，并且每个Cluster资源可以指向一个ClusterLoadAssignment资源。

2、Envoy实例在启动时请求加载所有Listener和Cluster资源，而后，再获取由这些Listener和 Cluster所依赖的RouteConfiguration和ClusterLoadAssignment配置；此种场景中，Listener资源和Cluster资源分别代表着客户端配置树上的“根（root）”配置，因而可并行加载。

3、类型gRPC一类的非代理式客户端可以仅在启动时请求加载其感兴趣的Listener资源，而后再加载这些特定Listener相关的RouteConfiguration资源；再然后，是这些 RouteConfiguration资源指向的Cluster资源，以及由这些Cluster资源依赖的 ClusterLoadAssignment资源；该种场景中，Listener资源是客户端整个配置树的“根”。

Envoy_69">5 Envoy的配置方式

Envoy的架构支持非常灵活的配置方式：简单部署场景可以使用纯静态配置，而更复杂的部署场景则可以逐步添加需要的动态配置机制

1、纯静态配置：用户自行提供侦听器、过滤器链、集群及HTTP路由（http代理场景），上游端点的发现仅可通过DNS服务进行，且配置的重新加载必须通过内置的热重启（ hot restart）完成；

2、仅使用EDS：EDS提供的端点发现功能可有效规避DNS的限制（响应中的最大记录数等）；

3、使用EDS和CDS：CDS能够让Envoy以优雅的方式添加、更新和删除上游集群，于是，初始配置时， Envoy无须事先了解所有上游集群；

4、EDS、CDS和RDS：动态发现路由配置；RDS与EDS、CDS一起使用时，为用户提供了构建复杂路由拓扑的能力（流量转移、蓝/绿部署等）；

5、EDS、CDS、RDS和LDS：动态发现侦听器配置，包括内嵌的过滤器链；启用此四种发现服务后，除了较罕见的配置变动、证书轮替或更新Envoy程序之外，几乎无须再热重启Envoy；

6、EDS、CDS、RDS、LDS和SDS：动态发现侦听器密钥相关的证书、私钥及TLS会话票据，以及对证书验证逻辑的配置（受信任的根证书和撤销机制等）；

EnvoyConfigSource_83">6 Envoy资源的配置源(ConfigSource)

1、配置源（ConfigSource）用于指定资源配置数据的来源，用于为Listener、Cluster、Route、 Endpoint、Secret和VirtualHost等资源提供配置数据。
2、目前，Envoy支持的资源配置源只能是path、api_config_source或ads其中之一。
3、api_config_source或ads的数据来自于xDS API Server，即Management Server。
在这里插入图片描述

7 基于文件系统的订阅

为Envoy提供动态配置的最简单方法是将其放置在ConfigSource中显式指定的文件路径中

Envoy将使用inotify（Mac OS X上的kqueue）来监视文件的更改，并在更新时解析文件中的DiscoveryResponse 报文
二进制protobufs，JSON，YAML和proto文本都是DiscoveryResponse 所支持的数据格式

提示

除了统计计数器和日志以外，没有任何机制可用于文件系统订阅ACK/NACK更新
若配置更新被拒绝，xDS API的最后一个有效配置将继续适用

1、基于eds实现Envoy基本全动态的配置方式
以EDS为例，Cluster为静态定义，其各Endpoint通过EDS动态发现
集群定义格式

# Cluster中的endpoint配置格式
clusters:
- name:...eds_cluster_config:service_name:eds_config:path: ... # ConfigSource，支持使用path, api_config_source或ads三者之一；

cluster的配置

# 类似如下纯静态格式的Cluster定义
clusters:
- name: webclusterconnect_timeout: 0.25stype: STATIC #类型为静态lb_policy: ROUND_ROBINload_assignment:cluster_name: webclusterendpoints:- lb_endpoints:- endpoint:address:socket_address:address: xx.xx.xx.xxport_value: 8080#使用了EDS的配置
clusters:
- name: targetClusterconnect_timeout: 0.25slb_policy: ROUND_ROBINtype: EDS #类型为EDSeds_cluster_config:service_name: webclustereds_config:path: '/etc/envoy/eds.yaml' # 指定订阅的文件路径
#提示：文件后缀名为conf，则资源要以json格式定义；文件后缀名为yaml，则资源需要以yaml格式定义；另外，动态配置中，各Envoy实例需要有惟的id标识；

7.1 EDS的配置

文件/etc/envoy/eds.yaml中以Discovery Response报文的格式给出响应实例，例如，下面的配置示例用于存在地址xx.xx.xx.xx某上游服务器可提供服务时
响应报文需要以JSON格式给出

resources:- "@type": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignmentcluster_name: webclusterendpoints:- lb_endpoints:- endpoint:address:socket_address:address: xx.xx.xx.xxport_value: 8080随后，修改该文件，将xx.xx.xx.xx也添加进后端端点列表中，模拟配置变动
- endpoint:address:socket_address:address: xx.xx.xx.xxport_value: 8080

Envoy_164">7.2 基于lds和cds实现Envoy基本全动态的配置方式

各Listener的定义以Discovery Response 的标准格式保存于一个文件中。
各Cluster的定义同样以Discovery Response的标准格式保存于另一文件中。
如下面Envoy Bootstrap配置文件示例中的文件引用

node:id: envoy_front_proxy cluster: MageEdu_Clusteradmin:profile_path: /tmp/envoy.prof access_log_path: /tmp/admin_access.logaddress: socket_address: address: 0.0.0.0port_value: 9901dynamic_resources:lds_config:path: /etc/envoy/conf.d/lds.yaml cds_config: path: /etc/envoy/conf.d/cds.yaml lds的Discovery Response格式的配置示例如下resources:
- "@type": type.googleapis.com/envoy.config.listener.v3.Listenername: listener_httpaddress: socket_address: { address: 0.0.0.0, port_value: 80 }filter_chains:- filters:name: envoy.http_connection_managertyped_config: "@type":type.googleapis.com/envoy.extensions.filters.network.http_connection_manag
er.v3.HttpConnectionManagerstat_prefix: ingress_httproute_config:name: local_route virtual_hosts:- name: local_servicedomains: ["*"]routes:- match:prefix: "/"route:cluster: webclusterhttp_filters:- name: envoy.filters.http.routercds的Discovery Response格式的配置示例如下resources:
- "@type": type.googleapis.com/envoy.config.cluster.v3.Clustername: webclusterconnect_timeout: 1s
type: STRICT_DNSload_assignment:cluster_name: webclusterendpoints:- lb_endpoints:- endpoint:address: socket_address: address: webserver01port_value: 8080- endpoint:address: socket_address: address: webserver02port_value: 8080

在这里插入图片描述

8 基于gRPC的动态配置

8.1 gRPC的介绍

Enovy支持为每个xDS API独立指定gRPC ApiConfigSource，它指向与管理服务器对应的某上游集群。
这将为每个xDS资源类型启动一个独立的双向gRPC流，可能会发送给不同的管理服务器
每个流都有自己独立维护的资源版本，且不存在跨资源类型的共享版本机制；
在不使用ADS的情况下，每个资源类型可能具有不同的版本，因为Envoy API允许指向不同的 EDS/RDS资源配置并对应不同的ConfigSources

8.2 API的交付方式采用最终一致性机制

基于gRPC的动态配置格式
以LDS为例，它配置Listener以动态方式发现和加载，而内部的路由可由发现的Listener直接提供，也可配置再经由RDS发现。
下面为LDS配置格式，CDS等的配置格式类同：

dynamic_resouces:lds_config:api_config_source：api_type: ... # API 可经由REST或gRPC获取，支持的类型包括REST、gRPC和delta_gRPCresource_api_version: ... # xDS 资源的API版本，对于1.19及之后的Envoy版本，要使用v3；rate_limit_settings： {...} # 速率限制grpc_services: # 提供grpc服务的一到多个服务源transport_api_version : ... # xDS 传输协议使用的API版本，对于1.19及之后的Envoy版本，要使用v3；envoy_grpc: # Envoy内建的grpc客户端，envoy_grpc和google_grpc二者仅能用其一；cluster_name: ... # grpc集群的名称；google_grpc: # Google的C++ grpc客户端timeout: ... # grpc超时时长；

注意：
提供gRPC API服务的Management Server （控制平面）也需要定义为Envoy上的集群，并由envoy实例通过xDS API进行请求；
(1) 通常，这些管理服务器需要以静态资源的格式提供；
(2) 类似于，DHCP协议的Server 端的地址必须静态配置，而不能经由DHCP协议获取；

8.3 基于GRPC管理服务器订阅

基于gRPC的订阅功能需要向专用的Management Server请求配置信息。
下面的示例配置使用了lds和cds 分别动态获取Listener和Cluster相关的配置。

node:id: envoy_front_proxy cluster: webclusteradmin:profile_path: /tmp/envoy.profaccess_log_path: /tmp/admin_access.logaddress:socket_address:address: 0.0.0.0port_value: 9901dynamic_resources: lds_config:  #定义动态获取listenerresource_api_version: V3api_config_source:api_type: GRPC  #使用GRPC模式transport_api_version: V3grpc_services:- envoy_grpc:cluster_name: xds_cluster #调用grpc服务器cds_config: #定义动态获取clusterresource_api_version: V3api_config_source:api_type: GRPC  #使用GRPC模式transport_api_version: V3grpc_services:- envoy_grpc:cluster_name: xds_cluster #调用grpc服务器#xds_cluster需要静态配置
static_resources:clusters:- name: xds_clusterconnect_timeout: 0.25stype: STRICT_DNS# Used to provide extension-specific protocol options for upstream connections. typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config:http2_protocol_options: {}lb_policy: ROUND_ROBINload_assignment:cluster_name: xds_clusterendpoints:- lb_endpoints:- endpoint:address:socket_address:address: xdsserver-IPport_value: 18000

8.4 ADS

通过上面的交互顺序保证MS资源分发时的流量丢弃是一项很有挑战的工作，而ADS允许单一MS通过单个gRPC流提供所有的API更新。
在这里插入图片描述

配合仔细规划的更新顺序，ADS可规避更新过程中流量丢失
使用 ADS，在单个流上可通过类型 URL 来进行复用多个独立的 DiscoveryRequest/DiscoveryResponse 序列
使用了ads分别动态获取Listener和Cluster相关的配置

node:id: envoy_front_proxy cluster: webclusteradmin:profile_path: /tmp/envoy.profaccess_log_path: /tmp/admin_access.logaddress:socket_address:address: 0.0.0.0port_value: 9901dynamic_resources:ads_config:api_type: GRPCtransport_api_version: V3grpc_services:- envoy_grpc:cluster_name: xds_clusterset_node_on_first_message_only: truecds_config:resource_api_version: V3ads: {}lds_config:resource_api_version: V3ads: {}#xds_cluster需要静态配置
static_resources:clusters:- name: xds_clusterconnect_timeout: 0.25stype: STRICT_DNS# Used to provide extension-specific protocol options for upstream connections. typed_extension_protocol_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions: "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions explicit_http_config:http2_protocol_options: {}lb_policy: ROUND_ROBINload_assignment:cluster_name: xds_clusterendpoints:- lb_endpoints:- endpoint:address:socket_address:address: xdsserver-IPport_value: 18000

9 REST-JSON轮询订阅

9.1 REST-JSON介绍

通过REST端点进行的同步（长）轮询也可用于xDS单例API
上面的消息顺序是类似的，除了没有维护到管理服务器的持久流
预计在任何时间点只有一个未完成的请求，因此响应nonce在REST-JSON中是可选的 p proto3的JSON规范转换用于编码DiscoveryRequest和DiscoveryResponse消息。
ADS不适用于REST-JSON轮询
5)当轮询周期设置为较小的值时，为了进行长轮询，则还需要避免发送DiscoveryResponse ，除非发生了对底层资源的更改

9.2 以LDS为例，它用于发现并配置Listener

基于REST订阅的LDS配置格式，CDS等其它配置类似

dynamic_resources:lds_config:resource_api_version: … # xDS 资源配置遵循的API版本，v1.19版本及以后仅支持V3 ；api_config_source：transport_api_version: ... # xDS 传输协议中使用API版本，v1.19版本及以后仅支持V3；api_type: ... # API 可经由REST或gRPC获取，支持的类型包括REST、GRPC和DELTA_GRPCcluster_names: ... # 提供服务的集群名称列表，仅能与REST类型的API一起使用；多个集群用于冗余之目的，故障时将循环访问；refresh_delay: ... # REST API 轮询时间间隔；request_timeout: ... # REST API请求超时时长，默认为1s；注意：提供REST API服务的管理服务器也需要定义为Envoy上的集群，并由LDS等相关 的动态发现服务进行调用；但这些管理服务器需要以静态配置的格式提供；

9.3 基于REST管理服务器订阅

使用了ads分别动态获取Listener和Cluster相关的配置

node:id: envoy_front_proxycluster: webclusteradmin:profile_path: /tmp/envoy.profaccess_log_path: /tmp/admin_access.logaddress:socket_address:address: 0.0.0.0port_value: 9901dynamic_resources:cds_config:resource_api_version: V3api_config_source:api_type: RESTtransport_api_version: V3 refresh_delay: {nanos: 500000000} # 1/2s cluster_names:- xds_clusterlds_config:resource_api_version: V3api_config_source:api_type: RESTtransport_api_version: V3 refresh_delay: {nanos: 500000000} # 1/2s cluster_names:- xds_cluster