Istio入門 - アーキテクチャ編
Istioはここ数年の中でアーキテクチャの刷新や、新しいデータプレーンモデルの発表など様々な変化がありました。
本記事では、2022年におけるIstioのアーキテクチャとその歴史について見ていきたいと思います。
Istioのアーキテクチャ
現在のIstioのアーキテクチャがこちらです。
Image Source: https://istio.io/latest/docs/ops/deployment/architecture/
Control Plane
Istioでは、v1.5からControl Planeの構成が大きく変わりました。
v1.5以降
まずはv1.5以降、つまり現在採用されているアーキテクチャを紹介します。
Control PlaneにはIstiodと呼ばれる単一のバイナリが利用されています。
Istiodは、Pilot・Citadel・Galleyの3つのコンポーネントから構成されています。
Pilot
Envoy APIを使用してEnvoyサイドカーと通信します。
Pilotでは、プロキシやルーティングルールの設定を行います。
Citadel
Istiodは、認証局として機能し、Data Plane内の安全なmTLS通信を可能にする証明書を生成します。
Citadelでは、ユーザ認証や証明書・Credential管理を行います。
Galley
Istio内の設定の検証・集約・配布などを行います。
v1.5以前
では、続いてv1.5以前のアーキテクチャを紹介します。
Image Source: https://istio.io/v1.4/docs/ops/deployment/architecture/
v1.5以前では、Pilot・Citadel・Galleyなどのコンポーネントがマイクロサービスとして構築されていました。
一般的にマイクロサービスとして構築されることでいくつかのメリットがあります。
例えば、
- サービスごとに言語を選択することが可能
- 異なるチームが個別にサービスを管理できる
- サービスごとに異なるバージョンでリリース可能
などがよく挙げられます。
しかし、Istioの場合どうでしょうか。
Istioのコンポーネントは異なる言語で書かれているでしょうか？
Istioの全てのコンポーネントはGoで書かれています。そのため、サービスごとに言語を選択する必要がありません。
IstioのControl Planeを管理するチームは異なるでしょうか？
Istioのインストールや運用は単一のチームや個人によって管理されるはずです。
Istioのコンポーネントは異なるバージョンでリリースされるのでしょうか？
Control Planeのコンポーネントは常に同じバージョンでリリースされます。
例えば、PilotとCitadelを異なるバージョンで動作させることをテストしたこともサポートしたこともありませんでした。
よってマイクロサービスの利点の多くはIstioのControl Planeには当てはまらなかったのです。
そこで、モノリスなIstiodへとアーキテクチャを変更する事になりました。
より詳しくは、以下の記事をご覧下さい。
Data Plane
Data PlaneにはSidecarモデルとSidecarlessモデルの2つが開発されています。
Sidecar - istio-proxy
まず初めに現在最も利用されているSidecarモデルについて説明します。
Image Source: https://static.sched.com/hosted_files/kccncna2022/08/Istio Maintainer Session.pptx.pdf
SidecarモデルのData PlaneにはEnvoyが利用されています。
Envoyは、C++で開発された高性能なL4/L7プロキシとして動作します。
また、API経由での設定変更が可能なので再起動せずに動的に設定を変更することが可能です。
Istio以外にもAWS App MeshやGCP Cloud Endpointsなどでも利用されています。
IstioはこのEnvoyを拡張したistio-proxyを利用しています。
istio-proxyはSidecarコンテナとしてデプロイし、同じPod内のサービスコンテナと並行して動作させます。
また、このistio-proxyはサービスメッシュ内のすべてのサービスのInbound/Outboundのトラフィックを仲介します。
Sidecarless - Ambient Mesh
Ambient MeshはIstioが今年の9月に発表したばかりの新しいData Planeモデルです。
このAmbient MeshはSidecarコンテナ (istio-proxy) をデプロイすることなくサービスメッシュを構築します。
Sidecarコンテナの代わりに、L4処理を相当するZtunnelと呼ばれるコンポーネントをDaemonsetとしてデプロイします。
また、必要に応じてL7処理を相当するWaypoint Proxyと呼ばれるコンポーネントをGatewayとしてデプロイします。
Ambient Meshが開発された背景や仕組みについては先日開催されたKubernetes Meetup Tokyoで発表したので興味ある方は併せてご覧下さい。
ちなみにSidecarlessなサービスメッシュとしてはCiliumも有名です。
このAmbient Meshで利用されているZtunnelはSidecar構成と同じくEnvoyを拡張して開発されていました。
しかし、Envoyを拡張したZtunnelではいくつかの課題がありました。
そこで、現在はより軽量で開発体験の良いコンポーネントにするべく新しいRustベースのZtunnelを開発しています。
Ambient Meshは、現時点ではProducition環境での利用は推奨していません。
2023年のProduction環境への移行に向けて開発中です。
まとめ
いかがだったでしょうか？
Istioのアーキテクチャについてざっくりと紹介してみました。
改めてアーキテクチャを見ていくと、まだまだ知らないことばかりでとても面白かったです。
次回は、本記事で紹介できなかったMixerの廃止とWebassemblyについて書こうかなと思っています。
ここまで読んで頂き、ありがとうございました。
Discussion
v1.5以前と現在でアーキテクチャの図が同じではないですか？