Huawei社のクラウドは:. 5 Istio XDSプロトコル解析を説明します

XDS基本的な概念

XDSはsidecargRPC基づいて、送信とパイロットとの間のアプリケーションプロトコル。

Istioサービス発見モデル

ここではパイロットの話やsidecar発見（サービスエンドポイント）間およびサービスに配置されました。

Istio1.1新規参入MCPサービスの発見

Platormアダプタ・サービス・ディスカバリー後、XDSを使用してサーバのポリマー層Aggreagtor Regitstry抽象インタフェースによって提供される、Istio0.8 XDSサーバの実装は、ADS（Aggreagtorディスカバリサービス）に実装された後。

XDSサーバとsidecarXDS間の合意を取っている、XDSは、定義された構成をサポートするためのプロトコルです。

画像-20200225105742398

XDSは何ですか

XDSは、LDS、RDS、CDS、EDSおよびSDSを含むディスカバリ・サービスの総称です。特使は、動的にXDSのAPIで構成されたリスナー（リスナー）、ルート（ルート）、クラスター（クラスター）、エンドポイント（クラスタメンバー）とシークレット（秘密鍵）を取得することができます。

LDS

LDSは、リスナーディスカバリサービスです。ネットワーク接続、ネットワーク構成されたフィルタスタック開始する後続のイベントを処理するとき、及び、L3 / L4層フィルタとポートをリスニング特使リスナーリスナー制御開始は、（現在はTCPプロトコルをサポートする）に達しました。異なる薬剤のリスナーによって使用されている。このアーキテクチャは、ほとんどのタスク（電流制限、クライアント認証、HTTP接続管理、TCPプロキシなど）を行います。
RDS

HTTP接続を動的マネージャルーティングの設定ルートをHTTPヘッダ変形を得る工程フィルタ（付加、削除キーHTTPヘッダ）、仮想ホスト（VM）、及び各ルーティングエントリのルート発見サービスは、仮想ホストを定義しました。
CDS

クラスタのクラスタディスカバリサービスは、動的な情報を取得します。特使のクラスタマネージャは、すべてのアップストリームのクラスタを管理します。上流またはホストのクラスタ・ビューは、リスナーまたはルートから抽象上流クラスタ一般全て、任意のエージェントにパケットを転送するために使用することができます。
EDS

エンドポイントディスカバリサービス。用語特使では、クラスタのメンバーは、各クラスタ、ダイナミックにEDSのAPIによって得られた特使エンドポイントのために、エンドポイントと呼ばれます。優先サービスの理由としてEDSは2つのことを見つけました：
- ロードバランサに比べDNS解決を介してルーティングされるように、特使は、明らかに、各アップストリームホストの情報を知ることができ、したがって、よりインテリジェントな負荷分散戦略を作ることができます。
- エンドポイントの構成は、これらのプロパティは、サービスグリッドの負荷分散、統計収集の際に使用できるプロパティのような追加のドメインをホストすることができ、負荷分散の重みを含み、などが挙げられます。
SDS

秘密の発見サービス、実行するためのTLS証明書への動的アクセス。何のSDSのプロパティをRUOない、あなたはシークレットエージェントシークレットを開始する前に、K8S環境に含まれている証明書を作成する必要がありサイドカーの容器を取り付けなければならない証明書の有効期限が切れている場合、あなたは再配置する必要があります。SDSの使用は、SDSは、サーバ証明書は、証明書の有効期限が切れた場合、サーバは、新しい証明書を配布する特使を再デプロイせずに新しい証明書の子を受けるリロードします、特使の例のすべてに配布されます集中しました。SDSベースk8swatch（サブスクリプション）は、秘密を取得します。

標準のXDSプロセス

パイロット（XDSサーバ）、パイロット（XDSサーバ）へ特使開始要求は、特使応答がACK / NACK（ロードされた構成に応じて種類にTCPスリーウェイハンドシェイクのために、ダイナミックローディング構成内側に応答して受信された応答に応じて要求応答を返します）この時間は、私だけのいくつかを生産します

ここでは、要求が参照しDiscoveryRequest、レスポンスはを参照しますDiscoveryResponse。

画像-20200225113759403

XDSプロトコル分析

XDSプロトコル

特使XDSプロトコルは、構成情報の送信プロトコルであり、また、ブリッジIstio特使接続。

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

DiscoveryRequest

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

画像-20200225115048233

DiscoveryResponse

画像-20200225115339140

ADS 理解

What is ADS

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

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

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

画像-20200225120205058

为什么引入ADS

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

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

画像-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）,发送多种资源的请求和响应。

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

ADS最终一致性的考量

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

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

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

配置更新的顺序

画像-20200225125020710

xDS的未来

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

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

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

Sidecar 按需要请求资源，懒加载的方式，当真正的需要流量转发的时候，再去获取路由等配置
定義されたworkladサービスは、アクセスNS1 / serviceBことができ、このようなワークロードAとして、依存します
例えば、Aのサービスのために定義されたコンフィギュレーションルール、NetworkScopeのサービスは、唯一の名前空間のワークロードにアクセスすることができます。

実行時の負荷ので、公式には、道が提唱非常に遅延ロードではありません。懸念ミキサーは、パイロットハング時間、Istioのリスナーのパフォーマンスの損失が比較的大きく、実際に遅延ロードの実行時の増加で、警察それらを、記録メトリクスへのランタイムの方法である、または接続されていない、上の私たちの遅延ロード本当の原因のトラフィック損失。要求が失敗したときに転送したトラフィック。

インクリメンタルXDS

インクリメンタルXDSは、独立したXDSは、エンドポイントである、ADS、CDSおよびRDSのリソースの増分更新XDSクライアントが加入するための実行時の動的構成取得プログラムは次のとおりです。

特使は、必要に応じてオンデマンド/リクエスト怠惰なリソースを確保します。たとえば、トラフィックが未知のクラスタにルーティングされたときに、特使の未知のクラスタは、情報を取得要求します。
これは、大規模な拡張性の目標をサポートしています。サービスインスタンスが更新されている場合たとえば、100kのサービスインスタンスのクラスタでは、管理サーバは、単に情報のクラスタを発行しました。

短所

インクリメンタルXDSの欠点