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

IstioのIngress通信に何が関わるのかをざっくり解説します

概要

KubernetesにIstioを導入し、外部からメッシュ内のPodにアクセスするまでに
何のリソースが関連しているかをざっくり調べてみましたので画像を交えて説明します。
また、例として記載するyamlファイルは一部を抜粋しています。

※私個人の解釈が多く混じっているので別の観点から捉えてみると理解しやすいかもしれません。

代表的なIstioリソースは3つ

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

  • IngressGateway(Service/Pod)
  • Gateway(Resource)
  • Virtual Service(Resource)

これらのIstioリソースを定義することで最低限のアクセスは可能となります。
DestinationRuleはKubernetesリソースのServiceに対し、同時コネクション数やHTTPリクエスト数の制限、コネクションのアイドル時間の制限といったあらゆる制限を付加することができますが、外部からメッシュ内のPodにとりあえずアクセスしたい場合には必須ではなく、おまけ程度の認識です。

IngressGateway

IngressGatewayは上記画像のようにKubernetesのServiceとDeployment(Pod)で構成します。
ServiceはKubernetesリソースをそのまま使っているだけなので、単純にNodePortと同じ動作をしているように見受けられます。

Podが一番重要な働きをしているように見えていて、Podで受けたトラフィックは後述のIstioリソースに従いトラフィックをコントロールします。

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

例としてistio-systemNamespaceに対しGatewayリソースをデプロイするとIngressGateway Podに反映されることが確認できます。
確認方法は次のコマンドでPod(Envoy)のconfig_dumpをcurlコマンドでGETし、デプロイ前後で比較します。
kubectl exec [IngressGatewayPodName] -n istio-system -- curl localhost:15000/config_dump

Gateway

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

トラフィックを受信するとIngressGateway PodはGatewayリソースを確認します。
トラフィックのFQDN、ポート番号、プロトコルに一致するとVirtualServiceリソースでトラフィックをコントロールすることが可能になります。
この時点でのトラフィックの位置はまだIngressGateway Podの中です。

VirtualService

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

Gatewayの次はVirtualServiceリソースに基づきトラフィックをコントロールしていきます。
画像のVirtualServiceは特定のGatewayのルールに一致したトラフィックだけを扱うことを明示しています。
http:以降ではリクエストURIのプレフィックス/hogehogeに一致した場合に、KubernetesリソースのServiceであるserviceA8080ポートにルーティングします。

ここでやっとIngressGateway PodからServiceにトラフィックが流れ、その後ServiceからPodに流れていきます。
Pod内にはサイドカーとしてインジェクションされているEnvoy-Proxyがあり、トラフィックを一旦受け取ってからアップストリーム(バックエンド)のApplicationコンテナにトラフィックが渡されます。

外からアクセスができない!どこを調べれば良いの!?

今のトラフィックの流れを見ると
IngressGateway Service -> IngressGateway Pod ->
serviceA -> Pod(Envoy-Proxy) -> Pod(Application)
といったフローになります。

まずは、外部からアクセスした際にIngressGateway Podまでトラフィックが来ているのかを確認します。
kubectl logs -f [IngressGatewayPodName] -n istio-systemでtail -fモードを使用し、ログをリアルタイムで確認できる状態にします。
次にブラウザやcurlコマンドで外部からアクセスしてみます。
その時にログとして確認できればIngressGatewayとしては正常に動いています。
しかし、そこからServiceまでの経路が繋がっていない可能性があるため、GatewayVirtualServiceが正しく設定されているか見直してみます。

逆にIngressGateway Podのログからトラフィックを確認できない場合は、IngressGateway Serviceの設定に問題があるか、そもそもワーカーノードのポートまでたどり着けていない可能性がありますので、外部LBのフォワーディング設定やELBのターゲットグループ設定を確認してみると良いかもしれません。

そもそもアクセスログが出力されないのですが???

Istio導入直後はkubectl logsでアクセスログを確認できません。
kubectl edit configmap istio -n istio-systemを実行し、AccessLogFileの値を/dev/stdoutに変更します。
詳細についてはこちらのページで解説しています。
istio-proxy(Envoy)を通過するhttp accessログを出力させる(Pod個別設定)

ここまでざっくりとIngress通信について解説しましたが

「これは違うんじゃないのかな〜?」「私はこう解釈してるよ」といったコメント頂けると本当に嬉しいです。
そもそも私の解釈が全て正解だとは思っていないので他の方の意見も聞いてみたいというのが本音です。

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
ユーザーは見つかりませんでした