Help us understand the problem. What is going on with this article?

istiodのServiceDiscoveryとEnvoy-Proxyのざっくりとした連携について

概要

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

前提

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

3つの機能

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

  • Service Discovery
  • Configuration
  • Certificate Management

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

スクリーンショット 2020-07-09 7.23.29.png

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

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

図(ズ

スクリーンショット 2020-07-09 7.18.14.png

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の機能をメインに使っているようです。
istiodkubectl logsして見えるログからRDS,CDS,LDS,EDSといったワードが見えると思いますが
この部分がistiodから各Podに同居しているEnvoy-ProxyのAPIを叩きまくっている部分です。

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

スクリーンショット 2020-07-09 7.18.29.png

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

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間で共有します。
よく説明に出てくるサーキットブレーカーの発動に必要な情報と推測しています。

おわりに

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

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

Takagi_
Kubernetes/Istio周辺を勉強中です。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした