CLOUD SECURITY LAB

Istio、もしかしてテレパシーを使ってる？EnvoyとIstiodの秘密の通信方法 🤫

—

by

cslab
in

こんにちは！今日は、サービスメッシュの代名詞であるIstioの内部動作原理について深く掘り下げていきます。🧐

マイクロサービスアーキテクチャ（MSA）を運用していると、多数のサービス間のトラフィック制御、ポリシー適用、監視が非常に複雑になります。Istioはまさにこの問題を解決するために登場しました。Istioは、サービスと共にデプロイされる「サイドカープロキシ」であるEnvoyと、これらのプロキシを中央で管理する「コントロールプレーン」であるIstiodで構成されています。

ここで一つの疑問が生まれます。

「Istiodは、どのようにして多数のEnvoyプロキシにリアルタイムでコマンドを発行し、設定を更新しているのだろうか？」

まるで中央管制塔が数百機の飛行機とリアルタイムで交信するような、この驚くべき通信方法の秘密を今から解き明かしていきます！

🏛️ まずは全体像から：コントロールプレーン vs データプレーン

本格的に通信方式を理解する前に、全体的な構造から把握する必要があります。

  • コントロールプレーン (Control Plane – Istiod) 🧠
  • サービスメッシュの「脳」の役割を果たします。
  • すべての設定とポリシーを管理し、サービスディスカバリ情報を収集します。
  • 開発者が作成したVirtualService、DestinationRuleなどのYAMLファイルを解釈し、Envoyが理解できる設定に変換します。
  • データプレーン (Data Plane – Envoy Proxies) 💪
  • サービスメッシュの「手足」の役割を果たします。
  • 各アプリケーションコンテナの隣にサイドカーとして配置され、すべてのネットワークトラフィック（Inbound/Outbound）を傍受します。
  • コントロールプレーンから受け取った設定に従って、トラフィックルーティング、ロードバランシング、セキュリティポリシーの適用などの実際の作業を実行します。

核心は、「脳（Istiod）」がどのように「手足（Envoy）」をリアルタイムで制御するかです。

🚀 鍵は「Push」モデル：リアルタイム更新の秘密

結論から言うと、Istiodは変更が発生した際に、必要な設定をEnvoyプロキシにプッシュ（Push）する方式を使用します。

なぜこれが重要なのでしょうか？このプロセスを段階的に見ていきましょう。

  1. 変化の検知 📡: IstiodはKubernetes APIサーバーを絶えず監視しています。新しいサービスがデプロイされたり、既存サービスのPodがスケールアウトしたり、VirtualServiceのようなルーティングルールが変更されたりするなど、すべての変化を即座に検知します。
  2. 設定の変換 ⚙️: 変化が検知されると、Istiodはこの変更がどのEnvoyプロキシに影響を与えるかを計算します。そして、該当するプロキシのための新しい設定を生成します。
  3. 動的プッシュ(Push) ⚡️: Istiodは新しく生成された設定を、影響を受けるEnvoyプロキシに即座にプッシュします。この際、全体の設定をすべて送るのではなく、変更された部分に最適化された情報を伝達します。

このすべてのプロセスは、xDS(Discovery Service) APIという標準プロトコルを通じて、非常に効率的なgRPCストリーム上で行われます。これにより、非常に高速で安定したリアルタイム更新が可能になります。

🗣️ 彼らが使う言語：xDS APIとgRPC

IstiodとEnvoyはただ会話するわけではありません。「xDS」という標準化された言語を使用します。xDSは、さまざまな種類の「Discovery Service」の総称です。

  • LDS (Listener Discovery Service): Envoyがどのポートでどのようなトラフィックを受信するか（Listen）に関する設定 👂
  • RDS (Route Discovery Service): 受信したトラフィックをどのようなルールに従ってどこに送るかに関するルーティング設定 🗺️
  • CDS (Cluster Discovery Service): トラフィックを送信する宛先サービス（Cluster）グループに関する情報 🏢
  • EDS (Endpoint Discovery Service): 各サービス（Cluster）に属する実際のPodのIPアドレスとポートのリスト 📍

これらの情報は、gRPCストリームを通じて継続的に接続されたチャネル上でリアルタイムに伝達されます。

簡単な例で理解する

もし開発者が、reviewsサービスのトラフィックをv1バージョンとv2バージョンにそれぞれ90%、10%で分割するVirtualServiceをデプロイしたと仮定してみましょう。

1. 開発者が適用したVirtualService（入力）

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

2. Istiodの反応

  1. IstiodはKubernetes APIを通じて上記のVirtualServiceの作成を検知します。
  2. このルーティングルールが、reviewsサービスにトラフィックを送信するすべてのEnvoyプロキシに影響を与えることを計算します。
  3. 影響を受けるEnvoyに配信するRDS更新を生成します。

3. Envoyが受け取る設定（概念的な生データ）

Envoyは、以下のように変換された設定をxDSを通じてプッシュで受け取ります。（理解を助けるために簡略化された形式です。）

# RDS (Route Discovery Service) 応答の一部 (概念的表現)
# Istiodがこのような情報を生成してEnvoyにPushします。
{
  "name": "http.8080",
  "virtual_hosts": [
    {
      "name": "reviews:8080",
      "domains": ["reviews", "reviews:8080", ...],
      "routes": [
        {
          "match": { "prefix": "/" },
          "route": {
            "cluster": "outbound|8080|v1|reviews.default.svc.cluster.local",
            "weighted_clusters": {
              "clusters": [
                {
                  "name": "outbound|8080|v1|reviews.default.svc.cluster.local",
                  "weight": 90  // 👈 90% トラフィック加重
                },
                {
                  "name": "outbound|8080|v2|reviews.default.svc.cluster.local",
                  "weight": 10  // 👈 10% トラフィック加重
                }
              ]
            }
          }
        }
      ]
    }
  ]
}

このようにして、Envoyは開発者が意図した通りにトラフィックを90:10で正確に分配し始めます。このすべてのプロセスが数秒以内に自動的に行われます！

🤔 よくある誤解を正す

Istioの通信方式について話す際によくある誤解があります。なぜこれらが正しくないのかを見ていきましょう。

  • 「Envoyが定期的に問い合わせるんじゃないの？（Pull方式）」 ❌
  • なぜ違うのか？: もしEnvoyが10秒ごとにIstiodに「新しい設定はない？」と問い合わせると想像してみてください。何も変更がなくても、多数のプロキシが不要なネットワークトラフィックを発生させます。また、重要なポリシー変更が発生しても、最大10秒の遅延時間が発生する可能性があります。これはリアルタイム対応が重要なMSA環境には適していません。
  • 「決まった時間ごとに一括で受け取るんじゃないの？（Fixed Interval）」 ❌
  • なぜ違うのか？: これもPull方式と同様の欠点があります。変更がなくても決まった時間になると通信が発生し、変更が発生しても次の周期まで待つ必要があります。イベントベースのPush方式に比べて、はるかに非効率的で遅いです。

結論として、Istioの「イベントベースのPush」方式は、効率性、リアルタイム性、拡張性のすべての面で最も優れたアーキテクチャです。

✨ まとめ

今日は、Istioの核心的な頭脳であるIstiodが、データプレーンのEnvoyプロキシとどのように「テレパシー」のように通信するのかを探りました。

要点をまとめると、Istiodは変更事項をリアルタイムで検知し、xDS APIを通じてgRPCストリームで、必要なEnvoyにのみ最新の設定を動的に「Push」するということです。

この賢く効率的な通信方式のおかげで、私たちは複雑なマイクロサービス環境でもトラフィックを自在に制御し、ポリシーを迅速に適用できるのです。Istioをご利用中であれば、この目に見えない賢い交信が今この瞬間にも行われていることを覚えておいてください！😉

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です