はじめに
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にどのように接続されるか見ていく。
현재 단락 (1/86)
KubeVirtネットワークを理解する際に最も重要な選択肢はバインディングだ。同じVMIでもどのバインディングを使うかによって、ゲストがネットワークを見る方式、サービス公開方式、パフォーマンス、ライブ...