こんにちは、SPEEDAのSREチームの阿南です。最近Kubernetes界隈が盛り上がっていますね。ここ一年で、各企業での利用事例やKubernetesを解説している書籍等もかなり増え、活用の仕方も徐々に確立されて来ているのではないでしょうか。一方Istioについては、色々できそうということはわかったんだけど、利用事例も少ないためどう使えばいいかわからない、本番運用しているという企業もまだあまり聞かないし導入に踏み切れない、という方も多いかと思います。弊社ではまだ２つのnamespaceのみですが、Istioで運用を開始しております。今回は、Istioで実現できることはなんとなく知っているが、内部の通信の仕組みやどのようなコンポーネントがあるのかを追っていきたいと思います。その上でBlue-Green Deploymentを実現するための設定方法についても次回記事で触れていきます。
この記事で扱うこと
- Istioを構成するコンポーネントについて
- Istioの通信の流れ
Istioを構成するコンポーネント
Istioのコンポーネントについては、IstioのDocumentationに下記の図が紹介されています。
図の上側はdata planeで、サービスのPodにサイドカーコンテナ(Envoy) が起動し、Podへのリクエストを中継しています。 図の下側はcontrol planeで、Pilot, Mixer, Citadel が稼働します。Pilotは各サイドカーコンテナにConfigを反映し、Mixerはtelemetry収集やPolicy check（アクセスコントロールや流量の制御等）を担います。Citadelは証明書の管理を担当します。
では、実際にIstioをデプロイしてみて確認してみます。
デプロイの方法については省略しますが、コマンド一つで大量のPodが起動してきますので、一見面食らいますが、順に整理していきます。（grafana, prometheus, servicegraph, tracingについては実際のサービス通信とは関係が薄いため、省略します）
| pod | 役割 |
|---|---|
| istio-citadel | 証明書の発行、管理を実施 |
| istio-egressgateway | Istioの内部から外部へ通信するためのgateway |
| istio-galley | ユーザが定義したIstio設定のvalidationを実施 |
| istio-ingressgateway | Istioの外部から内部へ通信するためのgateway |
| istio-pilot | ユーザが定義したIstio設定を反映 |
| istio-policy | Mixerの一部. istio-proxyに来たrequestをチェック |
| istio-telemetry | Mixerの一部. 各podからテレメトリを収集 |
| istio-sidecar-injector | Podが起動する際に、リクエストをhookしてサイドカーを auto Injectする |
上記のコンポーネントでIstioの外からどのようにサービスのPodまでリクエストが到達しているのかを図で表現してみました。
上図の番号順に処理内容を解説します。
- リクエストが来る前にEnvoyをサイドカーコンテナとしてInjectしておく。（⓪）
- ingress-gatewayへリクエストが到達。ここで、hostやpathベースで、どのサービスPodにリクエストをforwardするか決める。（①）
- istio-proxyへリクエストが到達。実際には、サービスPodへのリクエストをPreroutingしている。例えば、サービスコンテナが80番で稼働していた場合、80番に来たリクエストを15001(Envoyポート)に流す。（②）
- istio-proxyからistio-policyにアクセスし、Policyのチェックを実施。例えば、流量の制御（最大同時アクセス数100等）で条件にひっかかった場合は、サービスのコンテナに到達する前にその時点でリクエストが返される。（③）
- Policyでチェックを通ったリクエストがサービスコンテナに到達。（④）
この辺りは、実際に通信の流れを理解するまでに時間がかかりました（今も勉強中です）。ご自身で確認したい方は、実際にistio-proxyのコンテナでshellを起動して、tcpdump, netstat等を取ってみると理解が進むと思います。istio-proxyにはデフォルトでこの辺りのコマンドがインストールされているので、スムーズに調査ができます。
今回、実際に通信をみていった結果、想像以上に色々なことをしてるなという印象でした。特に、PolicyチェックのためにMixerにアクセスしている点は結構重要で、istio-policyのPodがダウンするとサービスの通信もダウンしてしまいます。本番運用する際は、この辺りのConfigurationも注意して見ていきましょう。ちなみに、Istioは必要なコンポーネントに絞ってインストールが可能なので、最初はistio-policyなしで運用するのも十分ありだと思います。
今後Istioがどの程度、使われ広まっていくかはまだわかりませんが、Service Meshに必要な概念や機能を勉強するには良いソフトウェアだと思いますので、皆さんもぜひ一度触れてみてください。次回の記事では、通信の流れやコンポーネントを理解した上で、Istioを使ったBlue-Green Deploymentの方法をみていきます。
Kubernetes + Istioでblue-green deploymentを実現する
仲間募集！！
ユーザベースのSPEEDA SREチームは、 「No Challenge, No SRE, No SPEEDA」 を掲げて業務に取り組んでいます。
「挑戦しなければ、SREではないし、SREがなければ、SPEEDAもない」という意識の元、ユーザベースのミッションである 「経済情報で、世界をかえる」 の実現に向けて、日々邁進しています。
少しでも興味を持ってくださった方はこちらまで！
