Istio：xDS协议解析

目录

xDS基本概念
xDS协议分析
ADS理解
xDS的未来

xDS基本概念

Istio 发现模型

Istio 发现模型

xDS是什么

• xDS是一类发现服务的总称，包含LDS， RDS， CDS， EDS以及SDS。
• Envoy通过xDS API可以动态获取Listener（监听器），Route（路由）， Cluster（集群）， Endpoint（集群成员）以及Secret（证书）配置。

LDS

Listener 发现服务。

Listener监听器控制Envoy启动端口监听（目前只支持TCP协议），并配置L3/L4层过滤器，当网络连接达到后，配置好的网络过滤器堆栈开始处理后续事件。

这种通用的监听器体系结构用于执行大多数不同的代理任务（限流，客户端认证， HTTP连接管理， TCP代理等）。

RDS

Route发现服务，用于HTTP连接管理过滤器动态获取路由配置。

路由配置包含HTTP头部修改（增加、删除HTTP头部键值），virtual hosts （虚拟主机），以及virtual hosts 定义的各个路由条目。

CDS

Cluster发现服务，用于动态获取Cluster信息。

Envoy cluster管理器管理着所有的上游cluster。

鉴于上游cluster或者主机可用于任何代理转发任务，所以上游cluster一般从Listener或Route中抽象出来。

EDS

Endpoint发现服务。

在Envoy术语中， Cluster成员就叫 Endpoint，对于每个Cluster， Envoy通过EDS API动态获取Endpoint。

EDS作为首选的服务发现的原因有两点：

• 与通过DNS解析的负载均衡器进行路由相比， Envoy能明确的知道每个上游主机的信息，因而可以做出更加智能的负载均衡决策。
• Endpoint配置包含负载均衡权重、可用域等附加主机属性，这些属性可用域服务网格负载均衡，统计收集等过程中。
   

SDS

Secret发现服务，用于运行时动态获取TLS证书。

若没有SDS特性，在k8s环境中，必须创建包含证书的Secret，代理启动前Secret必须挂载到sidecar容器中，如果证书过期，则需要重新部署。

使用SDS，集中式的SDS 服务器将证书分发给所有的Envoy实例，如果证书过期，服务器会将新的证书分发， Envoy
接收到新的证书后重新加载儿不用重新部署

标准xDS流程

xDS协议分析

xDS协议是Envoy获取配置信息的传输协议，也是Istio与Envoy连接的桥梁。

Envoy动态的发现服务以及相关资源的API就是指xDS。

xDS可以通过两种方式承载： gRPC、 REST，这两种方式都是通过xDS-API发送DiscoveryRequest请求，然后资源通过DiscoveryResponse下发。

DiscoveryRequest

属性名	类型	作用
VersionInfo	string	成功加载的配置资源的版本号，第一次请求为空
Node	*core.Node	发起请求的节点信息。包含ID、版本位置信息以 及其他元数据
ResourceNames	[]string	请求的资源名称列表，为空表示订阅所有的资源
TypeUrl	string	资源类型，
ResponseNonce	string	ACK/NACK特定的response
ErrorDetail	*rpc.Status	代理加载配置失败的详情， ACK时为空

DiscoveryResponse

属性名	类型	作用
VersionInfo	String	Pilot响应版本号
Resources	[]types.Any	序列化的资源，可表示任意类型的资源
TypeUrl	string	资源类型
Nonce	string	基于gRPC的订阅使用， nonce提供了一种在随后的 DiscoveryRequest中明确ACK特定DiscoveryResponse 的方法

ADS理解

ADS是一种xDS的实现, 它基于gRPC长连接。 gRPC的实现是承载在HTTP/2之上。

Why ADS

Why ADS

Istio 0.8以前， Pilot提供的的单一资源的DS

• 每种资源需要一条单独的连接
• Istio高可用环境下，可能部署多个Pilot

带来的挑战：

• 没办法保证配置资源更新的顺序
• 多Pilot配置资源的一致性没法保证

综合以上两个问题，很容易出现配置更新过程中网络流量丢失带来网络错误（ 虚假的）

ADS允许通过一条连接（ gRPC的同一stream），发送多种资源的请求和响应。

• 能够保证请求一定落在同一Pilot上，解决多个管理服务器配置不一致的问题
• 通过顺序的配置分发，轻松解决资源更新顺序的问题

ADS最终一致性的考量

xDS 是一种最终一致的协议，所以在配置更新过程中流量会丢失。

EDS还没有来得例如，如果通过CDS/EDS获得Cluster X，一条指向Cluster X的RouteConfiguration 刚好调整为指向
Cluster Y， 但是在CDS/及下发Cluster Y的配置的条件下，到Y的流量会全部被丢弃，并且返回给客户端状态码503。

在某些场景下，流量丢弃是不可接受的。 Istio通过遵循make before break模型，调整配置更新顺序可以完全避免流量丢失。

xDS的未来

Istio目前是全量的向sidecar分发配置，由此带来几个问题

• 配置更新频率高，大集群的服务，实例数目多，其中有一个更新后便会触发全量的配置推送到所有的sidecar。带宽占用大， Pilot端cpu利用率高
• Sidecar占用内存多，随着集群规模增大，配置资源呈指数级增长，极大的限制了服务网格的规模
• 频繁的配置加载影响sidecar性能稳定性

增量xDS

Incremental xDS是一个独立的xDS endpoint，是一种runtime的动态配置获取方案，用于增量的更新xDS客户端订阅
的资源，适用于ADS， CDS和RDS：

• 保证Envoy按需/懒请求所需要的资源。例如当流量路由到未知的cluster时， Envoy就会请求获取未知的cluster信息。
• 支持大规模可扩展的目标。例如在一个有100K个服务实例的集群中，如果一个服务实例有更新，管理服务器只需要下发一个Cluster的信息。