- はじめに
- バインディングは正確に何を意味するのか
- 1. masqueradeバインディング
- 2. bridgeバインディング
- 3. passtバインディング
- 4. SR-IOVバインディング
- プラグインバインディングはなぜ必要か
- バインディング別にIPモデルはどう異なるか
- migrationとの関係
- よくある誤解
- 実務的な選択基準をまとめると
- まとめ
はじめに
KubeVirtネットワークを理解する際に最も重要な選択肢はバインディングだ。同じVMIでもどのバインディングを使うかによって、ゲストがネットワークを見る方式、サービス公開方式、パフォーマンス、ライブマイグレーション適合性が変わる。
staging/src/kubevirt.io/api/core/v1/schema.goを見ると主要なインターフェースバインディング種類が現れる。
BridgeMasqueradeSRIOVPasstBindingBindingplugin
つまり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にどのように接続されるか見ていく。