其他分享
首页 > 其他分享> > 华为云讲解:5. Istio xDS协议解析

华为云讲解:5. Istio xDS协议解析

作者:互联网

华为云讲解:5. Istio xDS协议解析

xDS 基本概念

xDS 是sidecar和Pilot 之间传输的应用协议,基于gRPC。

Istio 服务发现模型

这里讲的是Pilot和sidecar之间的配置以及Service discovery (service Endpoints)。

Istio1.1新加入MCP服务发现

Platorm Adapter 进行服务发现之后,通过Aggreagtor Regitstry 聚合层来提供抽象的接口,供XDS 的server使用,Istio0.8之后XDS server的实现方式是ADS(Aggreagtor discovery service) 实现。

XDS server和sidecar之间是走的XDS协议,XDS是为了支持配置而定义的一种协议。

image-20200225105742398

xDS是什么

xDS 是一发现服务的总称,包含LDS,RDS,CDS,EDS以及SDS。Envoy 通过xDS API 可以动态获取Listener(监听器),Route(路由),Cluster(集群),Endpoint(集群成员)以及Secret(秘钥)配置。

标准xDS流程

Envoy 发起请求到Pilot (xds server),Pilot (xds server)根据请求返回一个Response的响应,Envoy收到响应,动态加载响应里面的配置,根据加载的配置进行ACK/NACK (类型与TCP的三次握手)这个时候只是生产一些me

这里的Request就是指DiscoveryRequest,Response是指DiscoveryResponse

image-20200225113759403

xDS 协议分析

XDS 协议

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

Envoy动态的发现服务以及相关资源的API就是指xDS。xDS可以通过两种方式承载:gRPC、REST,这两种方式都是通过xDS-API发送DiscoveryRequest请求,然后资源通过DiscoveryRequest下发。

DiscoveryRequest

DiscoveryRequest是一个 结构化的东西。可以想象成他就是一个接口。下面是包含的字段

image-20200225115048233

DiscoveryResponse

image-20200225115339140

ADS 理解

What is ADS

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

HTTP/2是基于同一个连接进行多路复用,可以HTTP/2 connection连接之上同时发送多个request和response。

使用gRPC因为他是一种长连接。

image-20200225120205058

为什么引入ADS

Istio0.8以前,Pilot提供的是单一资源的DS 。

比如CDS 和EDS请求Pilot是通过两个不同connection连接 去请求的,也就是说XDS 有几种资源就需要创建几条单独的连接。

image-20200225122128426

问题

没办法保证配置资源更新顺序

在生产中需要部署多个Pilot来保证高可用,多个连接可以能会连接到多个Pilot,这样就没有办法保证配置资源的更新,比如LDS连接到Pilot1 ,CDS连接到Pilot2,EDS连接到Pilot3,那么不同资源的动态获取资源的顺序无法保证的。有办法保证也需要耗费很大的代价。

多个Pilot配置资源的一致性没办法保证

在分布式系统中多实例强一致性比较难保证。Pilot也没有提供这种机制,Pilot是一种无状态的应用,如果要保证强一致性必须要通过有状态的方式去实现,多个Pilot还需要定义一种新的协议,需要同步Pilot节点之间的状态。Pilot实例之间的状态,增加Pilot很大的负担。

综合上面两个问题,就很容易出现配置更新过程中网络流量丢失带来网络错误(虚假的)404、503 。没办法保证配置更新过程,没办法保证配置加载的过程就很容易出现404、503 是很常见的。404、503 并不是真正的错误,他是服务扩容和缩蓉带来的临时性的网络错误。其实不是真的,是一种虚假的状态。

为什么ADS可以解决这种问题

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

ADS最终一致性的考量

xDS 是一种最终一致的协议,所以在配置更新过程中流量会丢失。EDS还没有来得例如,如果通过CDS/EDS获取Cluster X配置,一条指向Cluster X 的RouteConfigutation刚好调整为指向Cluster Y,但是在CDS/以下发Cluster Y的配置的条件下,到Y的流量会全部被丢弃,并且返回给客户端状态码503。

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

make before break :断开之前先要合并,电路的术语 断开一个开关之前先打开另一个开关。

配置更新的顺序

image-20200225125020710

xDS的未来

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

当前Istio xDS的弊端大大限制了Istio服务网格的规模,如何解决?

  1. Sidecar 按需要请求资源,懒加载的方式,当真正的需要流量转发的时候,再去获取路由等配置
  2. 定义worklad的服务依赖,例如工作负载A可以访问ns1/serviceB
  3. 定义配置规则、Service的NetworkScope,例如服务A只能被同一个Namespace的workload访问。

通过懒加载的方式官方的并不是很提倡,因为运行时加载。担忧Mixer是一种runtime方式记录metrics 、police这些,在增加一个runtime的懒加载方式其实对Istio的Listener性能损耗比较大,当Pilot挂掉的时候,或者是连接不了的时候,我们的懒加载就会造成真正的流量丢失。转发流量的时候请求会失败。

增量xDS

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

缺点

Incremental xDS 的缺点

张成基 发布了37 篇原创文章 · 获赞 20 · 访问量 3092 私信 关注

标签:配置,Envoy,Istio,Cluster,华为,xDS,连接,Pilot
来源: https://blog.csdn.net/weixin_37546425/article/details/104496074