Istio

すべてのワークロードの隣にプログラマブルなプロキシを置くサービスメッシュ。トラフィック管理・mTLS・テレメトリをアプリのコード外に出す。

カテゴリ: Service Mesh & Networking
CNCF 成熟度: Graduated
言語: Go
ライセンス: Apache-2.0
リポジトリ: istio/istio
ドキュメント基準コミット: 58e9892 (2026-06-20, master)

何をするものか

Istio はサービスメッシュである。Go で書かれた制御プレーン istiod と、リクエスト経路に座るプロキシ群のデータプレーンから成る。制御プレーンは Kubernetes と Istio の設定を監視し、プロキシごとの設定を計算し、Envoy が話す gRPC ディスカバリプロトコル xDS でプロキシへ配信する。

従来のデータプレーンは各 Pod に注入される Envoy サイドカーである。新しい ambient モードは Pod ごとのサイドカーを廃する。ztunnel という per-node の Rust プロキシが L4 の mTLS とルーティングを担い、L7 機能が要るときだけ namespace または service 単位で waypoint Envoy を立てる。どちらのモードも同じ istiod が xDS で駆動する。

メッシュの狙いは関心事をアプリのコードから外に出すこと。サービス間の相互 TLS、リクエストルーティング、リトライ、トラフィックミラーリング、テレメトリを宣言的に設定し、プロキシが施行する。アプリは素の呼び出しを続けるだけでよい。

いつ使うか

Kubernetes 上に多数のサービスがあり、アプリのコードを変えずにサービス間 mTLS が欲しいとき。
L7 トラフィック制御が要るとき: ヘッダベースのルーティング、カナリア分割、フォールトインジェクション、ミラーリング。
異なる言語のサービス横断で、統一されたメトリクス・トレース・アクセスログが欲しいとき。
ワークロード ID モデル (SPIFFE) と短命証明書を発行する CA が欲しいとき。

向かない場面:

mTLS や細かいルーティングが不要な少数のサービス。制御プレーンとプロキシのオーバーヘッドに見合わない。
L4 接続性と、CNI がカーネルで既に施行できるポリシーしか要らないとき。

このディープダイブの構成

歴史: 起源・マイルストーン・存在理由。
アーキテクチャ: コンポーネントとリクエストの流れ。
採用事例・エコシステム: 誰が動かし、周囲に何があるか。
内部実装: ソースから読んだ重要なコードパス。
はじめに: インストールと最初の動く構成。

Istio ​

何をするものか ​

いつ使うか ​

このディープダイブの構成 ​

出典 ​

Istio

何をするものか

いつ使うか

このディープダイブの構成

出典