Istio:xDS协议解析

目录

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

xDS基本概念

Istio 发现模型

Istio:xDS协议解析_第1张图片 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流程

Istio:xDS协议解析_第2张图片

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之上。

Istio:xDS协议解析_第3张图片

Why ADS

Istio:xDS协议解析_第4张图片 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模型,调整配置更新顺序可以完全避免流量丢失。

Istio:xDS协议解析_第5张图片

xDS的未来

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

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

增量xDS

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

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

 

你可能感兴趣的:(Istio-后,Kubernetes,时代)