Istioのトラフィック制御 — 通信の判断をアプリから分ける
マイクロサービスの通信では、リトライ・可観測性・段階的リリース・ルーティングを各アプリに重ねると管理が難しくなります。IstioはEnvoyと制御プレーンで通信の方針を配ります。
TL;DR
- EnvoyはPodの近くで通信を扱い、istiodが設定を配る。
- Gatewayは入口、VirtualServiceはホスト・パス・ヘッダーに応じた行き先の規則。
- 段階的な振り分けはアプリのコードではなく通信ポリシーとして管理できる。
01データプレーンと制御プレーン
istiodから複数のEnvoyサイドカーへ設定を配信する図
Envoyは各ワークロードの近くでリクエストを中継するデータプレーンです。istiodはVirtualServiceなどの設定を監視し、Envoyへ必要なルーティング情報を配る制御プレーンです。
押さえること：EnvoyはPodの近くで通信を扱い、istiodが設定を配る。
02GatewayとVirtualServiceを分ける
外部→ALB/Ingress→Istio Gateway→VirtualService→Service→Podの流れ
Gatewayは外部から受け入れるホスト・ポート・TLSなどの入口を定義します。VirtualServiceは受信したリクエストを、ホスト・パス・ヘッダー等でどのServiceへ送るか決めます。
押さえること：Gatewayは入口、VirtualServiceはホスト・パス・ヘッダーに応じた行き先の規則。
03重み付けは段階的リリースに使える
v1/v2へ重み付きトラフィックを振り分け、観測して調整する図
VirtualServiceのルールは、複数バージョンのServiceへ重み付きで振り分ける表現もできます。少量の通信から新バージョンを試し、観測結果を見ながら配分を変えると、変更の影響を限定できます。
押さえること：段階的な振り分けはアプリのコードではなく通信ポリシーとして管理できる。
結論
- EnvoyはPodの近くで通信を扱い、istiodが設定を配る。
- Gatewayは入口、VirtualServiceはホスト・パス・ヘッダーに応じた行き先の規則。
- 段階的な振り分けはアプリのコードではなく通信ポリシーとして管理できる。