xDS basic concept
xDS protocol analysis
ADS to understand
the future of xDS

xDS basic concepts

Istio discovery model

What is xDS

xDS is the general term for a class of discovery services including LDS, RDS, CDS, EDS and SDS.

Envoy can dynamically acquire Listener (listener), Route (route), Cluster (cluster), Endpoint (cluster members) and Secret (certificate) configured through xDS API.

LDS

Listener Discovery Service.

Envoy Listener listener control starts listening port (currently only supports TCP protocol), and configure L3 / L4 layer filter, reached when the network connection, the network configured filter stack starts processing subsequent events.

This universal listeners architecture for the agent to perform the most of the task (current limiting, client authentication, HTTP connection management, TCP proxy, etc.) .

RDS

Route discovery service, a connection manager filter HTTP acquired dynamically routing configuration.

Routing configuration includes HTTP header modification (add, delete HTTP headers keys), virtual hosts (virtual host), and each routing entry virtual hosts defined.

CDS

Cluster Discovery Service for Cluster dynamically obtain information.

Envoy cluster manager manages all upstream cluster.

In view of the upstream or the host may be used for any cluster forwarding agent task, typically upstream cluster abstract from the Listener or Route.

EDS

Endpoint Discovery Service.

In terms Envoy, Cluster members called Endpoint , for each Cluster, Envoy Endpoint dynamically obtained by EDS API.

EDS as the reason for the preferred service found two things:

Were compared to the routing by the DNS resolution of the load balancer, Envoy can clearly know the information for each upstream host, and therefore can make more intelligent load balancing decisions.

Endpoint configuration includes load balancing weights, and other additional host attributes available domains, these process attributes available domain grid load balancing services, statistics collection, and the like.

SDS

Secret discovery service, dynamic access to TLS certificate for running.

Without SDS characteristics, k8s environment must be created that contains the certificate Secret, Secret Agent starts before the sidecar must be mounted to the container, if the certificate is expired, you will need to re-deploy.

The use of SDS, the SDS centralized server certificates will be distributed to all of the Envoy example, if the certificate expires, the server will distribute the new certificate, Envoy
reloaded after receiving the new certificate child without redeploying

Standard xDS process

xDS protocol analysis

Envoy xDS protocol is a transmission protocol for configuration information , and also a bridge Istio Envoy connection.

Envoy dynamic discovery of services and related resources API refers xDS.

XDS may be carried in two ways: GRPC, the REST , these two methods are transmitted by the API-XDS DiscoveryRequest request and resources DiscoveryResponse issued.

DiscoveryRequest

Property name	Types of	effect
VersionInfo	string	The allocation of resources successfully loaded the version number, the first request is empty
Node	*core.Node	Originating node information request. Comprises ID, version location information and other metadata,
ResourceNames	[]string	List the name of the resource request, open, which means all the resources subscribe
TypeUrl	string	Resource Type,
ResponseNonce	string	ACK / NACK response specific
ErrorDetail	*rpc.Status	Proxy details loading configuration failed, ACK when empty

DiscoveryResponse

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

ADS理解

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

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的信息。