Istio は、コードに触れることなく、マイクロサービスの集合にトラフィック管理、セキュリティ、可観測性を追加します。これが可能なのは、2 つの半分の分担の仕方のおかげです。実際にトラフィックを処理するデータプレーンと、データプレーンに何をすべきかを伝えるコントロールプレーンです。このガイドでは、その両方と、それらをワークロードにつなぐサイドカーモデルを説明します。

サイドカー：コンテナと一緒に動くプロキシ

Istio のデフォルトモードでは、すべてのワークロードの Pod に、アプリケーション自身のコンテナの隣に 2 つ目のコンテナが注入されます。その Pod のすべてのインバウンドとアウトバウンドのトラフィックを傍受するように設定された Envoy プロキシです。アプリケーションは、何も変わらないかのように、これまでどおりポートにバインドし、アウトバウンドの呼び出しを行います。サイドカーはパスに透過的に位置しており、それがまさに要点です。アプリケーションは、プロキシがそこにあることを知る必要がありません。

これによって得られるのは、TLS、リトライ、タイムアウト、ロードバランシング、認可が、アプリケーションコードから、設定として適用される形でプロキシに移ることです。開発チームはビジネスロジックを書き、メッシュは、各チームが同じ関心事の自分のバージョンを再実装する（あるいは実装し忘れる）代わりに、すべてのサービスにわたって一様にネットワークの関心事を扱います。

データプレーン：実際の仕事をする Envoy

データプレーンは、そのすべてのサイドカープロキシの集まりで、サービス間のすべてのリクエストを実際に運びます。トラフィックが暗号化され、タイムアウトの後にリクエストがリトライされ、サービスの 1 つのバージョンがカナリアリリースのためにトラフィックの 10% を受け取る、というのがここです。データプレーンは、自分でポリシーを決定するのではなく、コントロールプレーンがプッシュした設定を適用します。

コントロールプレーン：istiod

istiod は Istio のコントロールプレーンで、istio-system namespace 内の独自の Pod の集合として動作します。3 つの異なる仕事をします。

• 設定の配布。 Istio 自身の Kubernetes リソースで意図を表現します。たとえば「これらの 2 つのバージョンの間でトラフィックを 90/10 に分割する」といったものです。istiod はそれを Envoy のネイティブな設定形式に変換し、関連するすべてのサイドカーにプッシュします。そのため、Envoy の設定を直接手書きすることはありません（このライブラリの Envoy に関する「Learn」シリーズが、istiod が生成しているものの、基底の設定が実際にどのようなものかを、気になる人向けに説明しています）。
• 認証局。 istiod は、各サイドカーが相互 TLS に使う証明書を発行してローテーションします。そのため、アプリケーションコード自体が証明書を管理することなく、サービス間のトラフィックが暗号化され、各側が相手の ID を検証できます。
• サービスディスカバリーとポリシー。 istiod は、どのサービスがどこに存在するかを追跡し、認証と認可のポリシーを、それらを適用する必要のあるプロキシに配布します。

サイドカー注入：Pod が実際にプロキシを得る方法

Istio をインストールするだけでは、実行中のワークロードには何も変わりません。サイドカー注入は、別の明示的なステップです。namespace にラベルを付ける（istio-injection=enabled）と、その後その namespace で作成されたすべての Pod は、作成時にその spec に Envoy サイドカーが自動的に追加されます。既存の Pod は遡って変更されません。ラベルが付いた後に、サイドカーを取得するには、再作成する必要があります（削除して再適用する、または Deployment を通じてローリングする）。

この namespace ごとのオプトイン設計は意図的なものです。サイドカーを実行するようには作られていないシステム namespace を含め、クラスター内のすべての namespace を自動的にメッシュに含めると、誰も求めていないリソースのオーバーヘッドと複雑さが加わります。ラベル付けによって、どのワークロードがメッシュに含まれるかを正確に制御できます。

サイドカーのある Pod は、メッシュのない同等の Pod が 1 つのコンテナを表示するところで、2 つのコンテナを表示します。

kubectl get pods
# NAME                READY   STATUS
# reviews-v1-abc123   2/2     Running   ← サイドカーあり
# ratings-v1-def456   1/1     Running   ← サイドカーなし（ラベルのない namespace）

namespace 全体にラベルを付けずにサイドカーが必要なワークロードには、手動注入（istioctl kube-inject）が、適用前に単一のマニフェストにサイドカーを追加します。これは、インストールの残りとともに、次のガイドで説明します。

アンビエントモードについて

上記はすべて、Istio のオリジナルのサイドカーベースのアーキテクチャを説明したもので、このシリーズの残りが扱うものです。Istio は、サイドカーを使わない代替手段であるアンビエントモードも提供しています。すべての Pod にプロキシを注入する代わりに、データプレーンを、ノードごとのコンポーネント（ztunnel）と namespace ごとの waypoint プロキシに分割し、ワークロードごとに 1 つの Envoy を実行するリソースのオーバーヘッドを減らすことを目指しています。これは、このシリーズの範囲外とするほど、十分に実質的なアーキテクチャの違いです。ここで学ぶトラフィック管理とセキュリティの概念は、概念的にはアンビエントモードでも通用しますが、トラフィックがどう傍受されるかの仕組みは異なります。アンビエントモードを具体的に評価している場合は、Istio 自身のドキュメントを参照してください。