はじめに
この記事で紹介する構成は、公式にはまだサポートされていません。
Istio 公式ドキュメント には、こう書かれています：
Network topology limitations
Multi-cluster single network configurations are untested and may be broken.
- Be cautious when deploying ambient between clusters that share the same network
- Only multi-network configurations are supported
つまり：
- 単一ネットワーク構成はテストされておらず、壊れている可能性がある
- マルチネットワーク構成のみがサポートされている
それでも私が検証した結果、技術的には動作したので、その挙動を共有します。
本番環境での使用は完全に自己責任です。 将来のバージョンで挙動が変わる可能性も十分あります。
なぜサポート外の構成を検証したのか
Istio Ambient のマルチクラスター対応が alpha で出たとき、公式ブログの Limitations を見て思いました。
- Support only for one network per cluster deployment model.
- No support for direct pod addressing or headless services.
「Pod 直接通信はダメで、east-west gateway 経由のみか...」
でも、ふと疑問が湧いたんです。
「"one network per cluster" って、複数クラスタで同じ network 名を付けたらどうなるんだ？」
Istio本体のコードを読んでみると、network 名が同じならエンドポイントとして Pod IP を返す実装になっていました。
「え、これ動くんじゃない？」
試してみたら、動きました。
TL;DR（結論）
| 設定 | 挙動 | サポート状況 |
|---|---|---|
複数クラスタで topology.istio.io/network を同じ値に |
Pod IP がエンドポイントとして返る → Pod 直通信 | ❌ 未サポート（テストされていない） |
| クラスタごとに別の値に | east-west gateway のアドレスが返る → gateway 経由 | ✅ サポート済み |
公式の「one network per cluster」は「1クラスタに1つの network 名」という制約であり、複数クラスタで同じ名前を共有すること自体はコード上は想定されています。ただし、その構成はテストされておらず、現時点では公式サポート外です。
⚠️ 前提条件: Pod-to-Pod 通信には、vxlan や BGP などで Pod IP がクラスタ間でルーティングされる状態が必要です。
なぜ「サポート外」でも試したくなるのか
経由するコンポーネント数が違うからです。
同一 network の場合（シングルクラスタと同じ経路）
これはシングルクラスタの Ambient と全く同じ経路です。マルチクラスタなのに、まるで同一クラスタ上にいるかのような速度で通信できます。
別 network の場合（gateway 経由）
宛先クラスタ側の East/West Gateway を経由する分、経由するコンポーネントが増えてレイテンシも増加します。
さらに実環境では、East/West Gateway の前段に LoadBalancer Service（NLB 等） が入ることが多いです：
利用している LoadBalancer の技術次第で、さらにコンポーネントが増える可能性があります。
比較表
| 構成 | 経路 | 経由するコンポーネント数 |
|---|---|---|
| シングルクラスタ | Pod → ztunnel → ztunnel → Pod | 4 |
| マルチクラスタ（同一 network） | Pod → ztunnel → ztunnel → Pod | 4 |
| マルチクラスタ（別 network） | Pod → ztunnel → GW → ztunnel → Pod | 5 |
| 〃（NLB 経由の場合） | Pod → ztunnel → NLB → GW → ztunnel → Pod | 6 |
つまり、同一 network 構成が動くなら、マルチクラスタでもシングルクラスタ並みの低レイテンシが実現できるわけです。
💡 Note: これより速い構成は、送信元・送信先両方の Pod が同一 Node 上に配置されているケースとかです。
🎉 混合構成も動いた
さらに検証を進めたところ、パターン A（同一 network）とパターン B（別 network）の混合構成も正常に動作しました。
例：3 クラスタ構成
cluster1: topology.istio.io/network=network-east
cluster2: topology.istio.io/network=network-east ← cluster1 と同じ
cluster3: topology.istio.io/network=network-west ← 別 network
この構成で何が起きるかというと：
| 通信元 → 通信先 | 経路 | 理由 |
|---|---|---|
| cluster1 → cluster2 | Pod 直 | 同じ network-east
|
| cluster1 → cluster3 | Gateway 経由 | 別 network（network-east → network-west） |
| cluster2 → cluster3 | Gateway 経由 | 別 network（network-east → network-west） |
istiod が network ラベルを見て、自動で最適なルーティングを判断してくれます。
図解：混合構成
なぜこれが良いのか
-
地理的に近いクラスタは同一 network にして低レイテンシ
- 同一リージョン内、同一 DC 内など
-
地理的に遠いクラスタは別 network にして Gateway 経由
- リージョン間、オンプレ ↔ クラウド間など
-
設定は namespace ラベルだけ
- アプリケーション側の変更不要
- istiod が自動で判断してくれる