概要

IstioのコントロールプレーンとしてデプロイされるistiodのServiceDiscoveryがEnvoy-Proxyと
どのように連携しているのかについて、istiod側とEnvoy-Proxy側から私の解釈を記述します。

前提

Istioのバージョンは1.6.0です。

3つの機能

こちらのIstio / Archtectureでも解説されていますが

Service Discovery
Configuration
Certificate Management

の3つから構成されています。

istiodのDeploymentごとkubectl deleteして上記3つに関連することを試すといった検証はしたことが無いですが
istiodがお亡くなりになっているとIstioリソースを新しく適用しようとしてもEnvoy-Proxyへ伝達されません。
そもそもkubectl applyしようにもIstioのAPIが応答しないのでconfig伝達の前にValidationの時点で怒られます。

まだ初学者レベルの私が感じたところとしては、Istioが認識するyamlファイルが事故ってないかを確認し、
事故ってなければEnvoyで認識できる形式に変換し、EnvoyのAPIを利用して各Envoy-Proxyに送り込んでいるいった動きに見えます。

図（ズ

istiodがDiscoveryとConfigurationとCertificatesをそれぞれのEnvoy-Proxyにやっていますよ〜といった
ざっくりとした図ですね。

Istio1.6.0でコントロールプレーンがモノリスになったおかげで、以前のバージョンでPodとして存在してたPilot,Citadel,Galleyが削除され、istiodの中に包括されるようになっています。

PilotはServiceDiscovery相当の動きを担当
CitadelはCertificate Management相当の動きを担当
GalleyはConfiguration相当の動きを担当

していたそうです。

管理が楽になったので喜ぶべきなのでしょうか。

Service DiscoveryはEnvoy APIを添えるだけ

調べてみたのですが、istiodというよりEnvoy-Proxyの機能をメインに使っているようです。
istiodをkubectl logsして見えるログからRDS,CDS,LDS,EDSといったワードが見えると思いますが
この部分がistiodから各Podに同居しているEnvoy-ProxyのAPIを叩きまくっている部分です。

Service Discoveryをもう少し掘っていくと

代表的な物として４つが挙げられるかなと思いました。他にもいくつかあるようですが、ここでは割愛します。ごめんね。

`Route Discovery Service`(RDS)

ざっくりいうとServiceへのルーティング情報をEnvoy-Proxyに叩き込むAPI。
VirtualServiceの設定情報が反映されているかを確認する場合は、
istioctl proxy-config routes [podname].[namespace] -o jsonで詳細まで確認できます。

`Listener Discovery Service`(LDS)

通信を待ち受けるリスナー情報をEnvoy-Proxyに叩き込むAPI。
あまり仲良くした記憶が無いので解説できないのですが、この情報を確認する場合は、
istioctl proxy-config listener [podname].[namespace] -o jsonで詳細まで確認できます。

`Cluster Discovery Service`(CDS)

Serviceの名前解決に必要な情報(

[podname]
[podname].[namespace]
[podname].[namespace].svc
[podname].[namespace].svc.cluster.local
)
や、そのServiceへトラフィックを流す時に適用されるルール(DestinationRule)をEnvoy-Proxyに叩き込むAPI。
istioctl proxy-config cluster [podname].[namespace] -o jsonで詳細まで確認できます。

「DestinationRuleが意図したように効いてないぞ！！？」という事態に陥った時に上記のコマンドで中を覗いてみてください。
どのNamespaceのDestinationRuleがどのホスト名(FQDN)に対して有効になっているか確認できます。

`Endpoint Discovery Service`(EDS)

CDSではFQDNやホスト名に紐づく設定が確認できましたが、
EDSではIPアドレスとポート番号といったエンドポイントとしての情報をEnvoy-Proxyに叩き込むAPI。
istioctl proxy-config endpoint [podname].[namespace] -o jsonで詳細まで確認できます。が、
endpointの場合は-o jsonを付けない方が見やすかったりします。適宜変更してみてください。

他にも、エンドポイントのSTATUS(Healthy/UnHealthy)やOutelier Checkの結果をEnvoy-Proxy間で共有します。
よく説明に出てくるサーキットブレーカーの発動に必要な情報と推測しています。

おわりに

ここまでistiodとEnvoy-Proxy間のService Discoveryについて解説しましたが、
まだまだカバーしきれていないと思っています。
Envoy自体が高機能なプロキシであり、Istio自体がまだEnvoyの全ての機能を操りきれていないため
IstioからEnvoy-Proxyのポテンシャルを全て引き出せていないと思います。

これからのIstioのアップデートに期待ということで、終わります。
読んでくれた方々の参考になれば嬉しいです。