用于发现 cluster 内的所有节点,其是 Envoy 官方推荐的节点发现方式,可以规避传统 DNS 方式的问题(如:maximum records in a response),同时还能比 DNS 携带更多信息(如:canary status, zone等),用于实现智能 LB 和 routing。
SDS RESTful API
Envoy 的 SDS v1 要求必须实现以下接口:
通过 service 名称获取服务详情。地址:GET /v1/registration/(string: service_name)
写在前面
上一篇【Envoy.EP1】 介绍了如何使用
filesystem
和runtime对象
来实现 Envoy 的动态配置。但生产环境下,要配置的 Envoy 实例很多而且配置也更复杂,filesystem
就无法满足需求了;同时 Envoy 支持对接外部的配置服务(基于 RESTful 接口),所以这篇文章继续探究更方便的、可用于生产环境的 Envoy 的动态配置方式 --- xDS。xDS
xDS 是一类发现服务的统称,其包括如下几类:
本小节以
v1
为例,介绍如何使用和扩展自己的 xDS。全局的 SDS/EDS
用于发现
cluster
内的所有节点,其是 Envoy 官方推荐的节点发现方式,可以规避传统 DNS 方式的问题(如:maximum records in a response),同时还能比 DNS 携带更多信息(如:canary status, zone等),用于实现智能 LB 和 routing。SDS RESTful API
Envoy 的 SDS v1 要求必须实现以下接口:
GET /v1/registration/(string: service_name)
配置 SDS
在之前的文章初战 Envoy中提到,
cluster_manager >> clusters >> type
配置项支持五种属性:static
、strict_dns
、logical_dns
、original_dst
、sds
,其中最后一项sds
设置该 cluster 中的节点发现使用sds
方式。下面是一段使用
sds
的cluster_manager
配置(其他配置项与非 sds 的配置无异),此配置使用 k8s 的 kubernetes-envoy-sds 插件作为 Envoy 的全局 SDS。全局的 CDS
用于发现
upstream clusters
的服务,实现集群的动态配置。CDS RESTful API
Envoy 的 CDS v1 要求必须实现以下接口:
GET /v1/clusters/(string: service_cluster)/(string: service_node)
配置 CDS
与 CDS 的配置无差别,这里就不赘述了。
利用 HTTP Request Header 和 CDS 实现动态路由
当使用 CDS,但没有使用 RDS 时,通过在 route 中配置使用 cluster_header 属性作为路由规则,可以实现动态路由功能。
HTTP Connection Manager 中的 RDS
用于发现路由配置规则的服务,实现路由规则的动态配置,路由配置前后不影响当前请求。
RDS RESTful API
Envoy 中的 RDS v1 要求必须实现以下接口:
GET /v1/routes/(string: route_config_name)/(string: service_cluster)/(string: service_node)
配置 RDS
RDS 与全局的 SDS、CDS 不同,RDS 的定义位于
HTTP Connection Manager
下,如下所示:全局的 LDS
用于发现
listeners
的服务,实现监听器的动态配置。由于绝大多数配置项均在监听器中定义,所以使用 LDS 服务会大大减少 Envoy 的重启(仅 admin配置修改、tracing配置修改、envoy bin 文件更新等才需要重启)。LDS RESTful API
Envoy 的 LDS v1 要求必须实现以下接口:
GET /v1/listeners/(string: service_cluster)/(string: service_node)
LDS 配置
LDS 配置与
listeners
同级,即:参考文档