【入門】Istioをざっくりと理解する
マイクロサービスの課題
近年マイクロサービス化が進み、様々なサービスを連携させてユーザーに機能を提供している。
その際に以下の課題が挙げられる。
- 通信制御の複雑さ：サービス間のやり取りを効率よく制御するのが難しい
- セキュリティ対策：サービス間の認証・認可や暗号化など
- 可観測性の不足：通信の記録や動作状況を一元的に把握できず、原因調査が困難
サービスメッシュ
サービスメッシュは、こうした課題をアプリケーションではなく専用のインフラ層でまとめて解決を行う。
- サービス間通信を一元的に制御
- 認証や暗号化などのセキュリティ機能を共通化
- ログやメトリクス収集など可観測性を向上
アプリ側は業務ロジックに集中でき、通信やセキュリティの実装を個別に行う必要がなくなる。
Istio
代表的なサービスメッシュの一つで、Envoyプロキシを使ってマイクロサービス間通信を管理。
主な特徴は以下の通り。
- 高度なトラフィック制御
- mTLSによる安全な通信
- 詳細なモニタリングやトレーシング機能
- Kubernetesとの高い親和性
Istioのアーキテクチャ
現在のIstioのアーキテクチャは以下のようになっている。
データプレーン(Data Plane)とは
Data PlaneにはSidecarモデルとSidecarlessモデルの2つが開発されている。
Sidecar - istio proxy
現在最も利用されているのがSidecarモデル。
SidecarモデルのData PlaneにはEnvoyが利用されている。
Envoyとは、C++で開発された高性能なオープンソースのプロキシ(通信仲介ソフトウェア)
以下の特徴を持つ。
・サービス間通信の仲介：リクエストを受け取り、適切なサービスへ転送
・トラフィック制御：ロードバランシング、リトライ、タイムアウトなどを実現
・セキュリティ機能：mTLSによる暗号化や認証をサポート
・可観測性：ログ、メトリクス、分散トレーシングを提供
IstioはこのEnvoyを拡張したistio-proxyを利用している。
istio-proxyはSidecarコンテナとしてデプロイし、同じPod内のサービスコンテナと並行して動作させる。
また、このistio-proxyはサービスメッシュ内の全てのサービスのInbound/Outboundのトラフィックを仲介する。
Sidecarless - Ambient Mesh
サイドカーを各Podを配置しない新しいアーキテクチャ
通信のセキュリティは、ノードごとに配置されるshared proxy(ztunnel)が担当
Pod自体はEnvoyを持たずに軽量化できる
特徴
・導入が簡単：既存のPod定義を変更せずにメッシュに参加可能
・軽量：Podごとにサイドカーを置かないため、リソース消費が減る
・段階的な導入：サービス単位で機能を有効化できる
※ただし、サイドカーに比べるとまだ提供される機能に制限がある(高度なトラフィック制御など)
コントロールプレーン(Control Plane)
Control PlaneにはIstiodと呼ばれる単一のバイナリが利用されている。
Istiodは、Pilot・Citadel・Galleyの3つのコンポーネントから構成。
🔷 Pilot
役割：トラフィック制御の司令塔
Envoy(サイドカーやプロキシ)に対してルーティングルールやサービスディスカバリ情報を配布
つまり、「Envoyにどのサービスへどう通信させるか」を教える存在
🔷 Citadel
役割：セキュリティ(認証・証明書管理)
各サービスに証明書を発行し、mTLS(相互TLS通信)を実現する
サービス間の安全な通信を担保する基盤
🔷 Galley
役割：設定管理
ユーザーが書いたIstioの設定を検証し、正しい形式に変換して他コンポーネントに渡す
設定の翻訳者 ＋ チェック係」みたいな存在
まとめ
- Istio はマイクロサービス間通信を制御・管理するサービスメッシュ基盤。
- セキュリティ・トラフィック制御・観測性をアプリに手を入れずに提供できる。
- 主要コンポーネントは統合され、現在はistiodが中核を担っている。
Discussion