Skip to content
Published on

KubeVirtネットワーク2：bridge、masquerade、passt、SR-IOVバインディング比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View
Authors

はじめに

KubeVirtネットワークを理解する際に最も重要な選択肢はバインディングだ。同じVMIでもどのバインディングを使うかによって、ゲストがネットワークを見る方式、サービス公開方式、パフォーマンス、ライブマイグレーション適合性が変わる。

staging/src/kubevirt.io/api/core/v1/schema.goを見ると主要なインターフェースバインディング種類が現れる。

  • Bridge
  • Masquerade
  • SRIOV
  • PasstBinding
  • Binding plugin

つまりKubeVirtは一つの正解ネットワークモデルだけを強要しない。代わりに複数のワイヤリング方式を提供する。

バインディングは正確に何を意味するのか

公式デベロッパーガイドのdocs/network/network-binding-plugin.mdがよくまとめているように、バインディングは「ドメインVM NICをPod内でどのようにゲストに接続するか」を定義する層だ。

ここには以下が含まれる。

  • ドメインvNIC構成
  • Pod内部ネットワーク構成
  • 必要ならDHCPなどのゲスト配信サービス

つまりバインディングは単純なAPIオプションではなくゲストNICワイヤリング戦略だ。

1. masqueradeバインディング

最も無難でKubernetes親和的なデフォルト選択肢だ。

どう動作するか

  • PodはCNIでprimary IPを受け取る
  • ゲストは内部CIDRの別IPを受け取る
  • KubeVirtがDHCPとNATを構成する
  • 外部通信はPod IPを通じて出る

利点

  • Podネットワークとの衝突が少ない
  • サービス公開とポートフォワーディングモデルが馴染みやすい
  • migrationと一般運用で扱いやすい

欠点

  • ゲストがネットワークに直接公開される構造ではない
  • NATオーバーヘッドとポート設計の考慮が必要

運用の便宜性と汎用性のため最初に思い浮かぶ選択肢だ。

2. bridgeバインディング

bridgeバインディングはゲストをネットワークにより直接接続しようとするモデルだ。

どう動作するか

  • PodインターフェースとbridgeとTAPを繋いでゲストを直接接続する
  • ゲストがPodネットワークのより直接的なエンドポイントのように動作する
  • DHCPとbridgeワイヤリングが重要

利点

  • ゲストがより直接的なネットワーク接続性を持てる
  • NATを回避できるシナリオがある

欠点

  • Pod側ネットワーク構造がより敏感に再配線される
  • 運用者がPod IPとゲストの到達性をより気にする必要がある

bridgeは「コンテナのように安全なデフォルト」より「ゲストをより直接公開する」側に近い。

3. passtバインディング

schema.goはPasstBindingを別のcoreバインディングとして置く。passtはユーザーモードネットワーキングベースのアプローチとして理解するとよい。

利点

  • 比較的簡潔な接続モデルを提供する
  • 一部環境ではbridgeより構成負担が少ないことがある

欠点

  • パフォーマンスと機能面で直接カーネルdatapathを使うモデルとのトレードオフがある
  • feature gate、サポート範囲、運用互換性を確認する必要がある

pkg/network/passtとバインディングプラグインドキュメントを一緒に読むと、passtは「高性能L2直結」よりユーザーモード親和的ネットワーキングに近いことが分かる。

4. SR-IOVバインディング

SR-IOVは最もパフォーマンス指向の選択肢だ。代わりにKubernetesとホスト、NIC、IOMMU、VFIO構成がすべて揃わなければならない。

docs/network/sriov.mdを見ると関連コンポーネントがかなり多い。

  • SR-IOVデバイスプラグイン
  • SR-IOV CNIプラグイン
  • Multus
  • 必要ならSR-IOV operator
  • KubeVirtのlibvirtドメイン構成ロジック

どう動作するか

  • デバイスプラグインがVFリソースをKubernetesリソースとして広告
  • MultusとCNIがPod namespace側の準備を実行
  • KubeVirtは割り当てられたPCI情報を基にドメインをVFIOパススルー形態で構成

利点

  • 高パフォーマンス
  • 直接デバイスパススルーに近いネットワーク経路

欠点

  • ハードウェアとカーネル要件が高い
  • migrationとhotplug制約が大きくなる
  • 運用複雑度が高い

つまりSR-IOVは汎用デフォルトではなく、パフォーマンスのために単純性と柔軟性を一部諦める選択肢だ。

プラグインバインディングはなぜ必要か

KubeVirtは内蔵バインディングだけですべてのネットワークを賄おうとしない。network-binding-plugin.mdは次の2方向を説明する。

  • ゼロコードプラグイン
  • サイドカーまたはCNIを含むプラグイン

核心はプラグインがドメインアタッチメントタイプ、サイドカー、カスタムCNIを組み合わせて新しいバインディングを拡張可能にすることだ。

この設計はKubeVirtがネットワークの実験と拡張をcoreコードにすべて入れようとしない意図を示す。

バインディング別にIPモデルはどう異なるか

これは運用者がよく混乱するポイントだ。

masquerade

  • Pod IPとゲストIPが異なりうる
  • ゲストIPはKubeVirt DHCPと内部CIDRベース

bridge

  • ゲストがネットワークにより直接接続する
  • Podネットワークを再配線する効果が大きい

passt

  • ユーザーモードフォワーディングモデルに近い

SR-IOV

  • VFパススルー性格が強い
  • ゲストがより直接的なデバイスアクセスを持つ

つまり「IPを誰が与えるか」の答えもバインディング別に変わる。

migrationとの関係

バインディングは単純な接続性選択ではなくmigration戦略にも大きな影響を与える。

  • masqueradeが最もmigration親和的だ
  • bridgeは実装と環境によってより慎重にしなければならない
  • SR-IOVはデバイスパススルー特性のため制約が大きい
  • プラグインバインディングは文書化されたmigrationメソッドサポート有無を必ず確認しなければならない

network-binding-plugin.mdもバインディングプラグインがmigrationをサポートするには別途のmigrationメソッド宣言が必要だと説明する。

よくある誤解

誤解1：bridgeは常にmasqueradeより優れている

違う。より直接的な接続性が利点になりうるが、運用の単純性とmigration親和性はmasqueradeの方が良い場合がある。

誤解2：SR-IOVは単に速いNICオプションに過ぎない

違う。デバイス広告、CNI、VFIO、IOMMU、libvirtドメイン構成まですべて絡んだ複合選択肢だ。

誤解3：プラグインバインディングはcoreバインディングの装飾だ

違う。KubeVirtがネットワーク拡張をモジュール式に扱うための重要な設計だ。

実務的な選択基準をまとめると

  • 最も安全なデフォルトが必要ならmasquerade
  • ゲストの直接接続性が重要ならbridge
  • 特定のユーザーモードネットワーキング特性が必要ならpasst
  • 最大パフォーマンスと直接デバイスアクセスが必要ならSR-IOV

結局バインディングはパフォーマンス問題であると同時に運用性とmigration可能性の問題だ。

まとめ

KubeVirtのネットワークバインディングはゲストNICをPod内でどのようにワイヤリングするかを決定する核心軸だ。masqueradeは汎用性と運用便宜、bridgeはより直接的な接続性、passtはユーザーモード性格、SR-IOVは高性能デバイスパススルーという明確な性格を持つ。したがってバインディング選択は単純なAPIオプションではなくネットワークモデルと運用戦略全体を決定するアーキテクチャ選択だ。

次の記事ではprimaryネットワークを超えて、MultusとsecondaryネットワークがKubeVirtにどのように接続されるか見ていく。

Discuss on Twitter • View on GitHub