centra
a7ec7e2158
- Created T026-practical-test task.yaml for MVP smoke testing - Added k8shost-server to flake.nix (packages, apps, overlays) - Staged all workspace directories for nix flake build - Updated flake.nix shellHook to include k8shost Resolves: T026.S1 blocker (R8 - nix submodule visibility)
199 lines
8.4 KiB
Markdown
199 lines
8.4 KiB
Markdown
# Overlay Networking Research Summary
|
||
|
||
**Date:** 2025-12-08
|
||
**Task:** T015 S1
|
||
**Status:** Research Complete
|
||
|
||
## Executive Summary
|
||
|
||
マルチテナントVMネットワーク分離のためのオーバーレイネットワーキングソリューションの調査結果。OVN、Cilium、Calico、カスタムeBPFソリューションを評価し、**OVNを推奨**する。
|
||
|
||
## 1. OVN (Open Virtual Network)
|
||
|
||
### アーキテクチャ
|
||
- **ベース**: OpenStack Neutronのネットワーク抽象化をOpen vSwitch (OVS)上に実装
|
||
- **コンポーネント**:
|
||
- `ovn-northd`: 論理ネットワーク定義を物理フローに変換
|
||
- `ovn-controller`: 各ホストでOVSフローを管理
|
||
- `ovsdb-server`: ネットワーク状態の分散データベース
|
||
- `ovn-nb` (Northbound DB): 論理ネットワーク定義
|
||
- `ovn-sb` (Southbound DB): 物理フロー状態
|
||
|
||
### 機能
|
||
- ✅ マルチテナント分離（VXLAN/GRE/Geneveトンネル）
|
||
- ✅ 分散ルーティング（L3 forwarding）
|
||
- ✅ 分散ロードバランシング（L4）
|
||
- ✅ セキュリティグループ（ACL）
|
||
- ✅ DHCP/DNS統合
|
||
- ✅ NAT（SNAT/DNAT）
|
||
- ✅ 品質保証（QoS）
|
||
|
||
### 複雑さ
|
||
- **高**: OVSDB、OVNコントローラー、分散状態管理が必要
|
||
- **学習曲線**: 中〜高（OVS/OVNの概念理解が必要）
|
||
- **運用**: 中（成熟したツールチェーンあり）
|
||
|
||
### 統合の容易さ
|
||
- **PlasmaVMC統合**: OVN Northbound API（REST/gRPC）経由で論理スイッチ/ルーター/ポートを作成
|
||
- **既存ツール**: `ovn-nbctl`、`ovn-sbctl`でデバッグ可能
|
||
- **ドキュメント**: 豊富（OpenStack/OVN公式ドキュメント）
|
||
|
||
### パフォーマンス
|
||
- **オーバーヘッド**: VXLANカプセル化による約50バイト
|
||
- **スループット**: 10Gbps以上（ハードウェアオフロード対応）
|
||
- **レイテンシ**: マイクロ秒単位（カーネル空間実装）
|
||
|
||
## 2. Cilium
|
||
|
||
### アーキテクチャ
|
||
- **ベース**: eBPF（Extended Berkeley Packet Filter）を使用したカーネル空間ネットワーキング
|
||
- **コンポーネント**:
|
||
- `cilium-agent`: eBPFプログラムの管理
|
||
- `cilium-operator`: サービスディスカバリー、IPAM
|
||
- `etcd`または`Kubernetes API`: 状態管理
|
||
|
||
### 機能
|
||
- ✅ マルチテナント分離（VXLAN/Geneve、またはネイティブルーティング）
|
||
- ✅ L3/L4/L7ポリシー（eBPFベース）
|
||
- ✅ 分散ロードバランシング
|
||
- ✅ 可観測性（Prometheusメトリクス、Hubble）
|
||
- ✅ セキュリティ（ネットワークポリシー、mTLS）
|
||
|
||
### 複雑さ
|
||
- **中**: eBPFの理解が必要だが、Kubernetes統合が成熟
|
||
- **学習曲線**: 中（Kubernetes経験があれば容易）
|
||
- **運用**: 低〜中（Kubernetesネイティブ）
|
||
|
||
### 統合の容易さ
|
||
- **PlasmaVMC統合**: Kubernetes API経由または直接Cilium API使用
|
||
- **既存ツール**: `cilium` CLI、Hubble UI
|
||
- **ドキュメント**: 豊富（Kubernetes中心）
|
||
|
||
### パフォーマンス
|
||
- **オーバーヘッド**: 最小（カーネル空間、eBPF JIT）
|
||
- **スループット**: 非常に高い（ハードウェアオフロード対応）
|
||
- **レイテンシ**: ナノ秒単位（カーネル空間）
|
||
|
||
### 制約
|
||
- **Kubernetes依存**: Kubernetes環境での使用が前提（VM直接管理は非標準）
|
||
- **VMサポート**: 限定的（主にコンテナ向け）
|
||
|
||
## 3. Calico
|
||
|
||
### アーキテクチャ
|
||
- **ベース**: BGP（Border Gateway Protocol）ベースのルーティング
|
||
- **コンポーネント**:
|
||
- `calico-node`: BGPピア、ルーティングルール
|
||
- `calico-kube-controllers`: Kubernetes統合
|
||
- `etcd`または`Kubernetes API`: 状態管理
|
||
|
||
### 機能
|
||
- ✅ マルチテナント分離（BGPルーティング、VXLANオプション）
|
||
- ✅ ネットワークポリシー（iptables/Windows HNS）
|
||
- ✅ IPAM
|
||
- ✅ BGP Anycast（L4ロードバランシングに有用）
|
||
|
||
### 複雑さ
|
||
- **低〜中**: BGPの理解が必要だが、シンプルなアーキテクチャ
|
||
- **学習曲線**: 低（BGP知識があれば容易）
|
||
- **運用**: 低（シンプルな構成）
|
||
|
||
### 統合の容易さ
|
||
- **PlasmaVMC統合**: Calico API経由またはBGP直接設定
|
||
- **既存ツール**: `calicoctl`
|
||
- **ドキュメント**: 豊富
|
||
|
||
### パフォーマンス
|
||
- **オーバーヘッド**: 低（ネイティブルーティング）
|
||
- **スループット**: 高い（ハードウェアルーティング対応）
|
||
- **レイテンシ**: 低（ネイティブルーティング）
|
||
|
||
### 制約
|
||
- **BGP要件**: BGP対応ルーター/スイッチが必要（データセンター環境）
|
||
- **VMサポート**: Kubernetes統合が主（VM直接管理は限定的）
|
||
|
||
## 4. カスタムeBPFソリューション
|
||
|
||
### アーキテクチャ
|
||
- **ベース**: 独自のeBPFプログラムとコントロールプレーン
|
||
- **コンポーネント**: 独自実装
|
||
|
||
### 機能
|
||
- ✅ 完全なカスタマイズ性
|
||
- ✅ 最適化されたパフォーマンス
|
||
- ❌ 開発・保守コストが高い
|
||
|
||
### 複雑さ
|
||
- **非常に高**: eBPFプログラミング、カーネル開発、分散システム設計が必要
|
||
- **学習曲線**: 非常に高
|
||
- **運用**: 高（独自実装の運用負荷）
|
||
|
||
### 統合の容易さ
|
||
- **PlasmaVMC統合**: 完全にカスタマイズ可能
|
||
- **既存ツール**: 独自開発が必要
|
||
- **ドキュメント**: 独自作成が必要
|
||
|
||
### パフォーマンス
|
||
- **オーバーヘッド**: 最小（最適化可能）
|
||
- **スループット**: 最高（最適化可能）
|
||
- **レイテンシ**: 最小（最適化可能）
|
||
|
||
### 制約
|
||
- **開発時間**: 数ヶ月〜数年
|
||
- **リスク**: バグ、セキュリティホール、保守負荷
|
||
|
||
## 5. 比較表
|
||
|
||
| 項目 | OVN | Cilium | Calico | カスタムeBPF |
|
||
|------|-----|--------|--------|--------------|
|
||
| **成熟度** | 高 | 高 | 高 | 低 |
|
||
| **VMサポート** | ✅ 優秀 | ⚠️ 限定的 | ⚠️ 限定的 | ✅ カスタマイズ可能 |
|
||
| **複雑さ** | 高 | 中 | 低〜中 | 非常に高 |
|
||
| **パフォーマンス** | 高 | 非常に高 | 高 | 最高（最適化後） |
|
||
| **統合容易さ** | 中 | 高（K8s） | 中 | 低（開発必要） |
|
||
| **ドキュメント** | 豊富 | 豊富 | 豊富 | なし |
|
||
| **運用負荷** | 中 | 低〜中 | 低 | 高 |
|
||
| **開発時間** | 短（統合のみ） | 短（K8s統合） | 短（統合のみ） | 長（開発必要） |
|
||
|
||
## 6. 推奨: OVN
|
||
|
||
### 推奨理由
|
||
|
||
1. **VMファースト設計**: OVNはVM/コンテナ両方をサポートし、PlasmaVMCのVM中心アーキテクチャに最適
|
||
2. **成熟したマルチテナント分離**: OpenStackでの実績があり、本番環境での検証済み
|
||
3. **豊富な機能**: セキュリティグループ、NAT、ロードバランシング、QoSなど必要な機能が揃っている
|
||
4. **明確なAPI**: OVN Northbound APIで論理ネットワークを定義でき、PlasmaVMCとの統合が容易
|
||
5. **デバッグ容易性**: `ovn-nbctl`、`ovn-sbctl`などのツールでトラブルシューティングが可能
|
||
6. **将来の拡張性**: プラガブルバックエンド設計により、将来的にCilium/eBPFへの移行も可能
|
||
|
||
### リスクと軽減策
|
||
|
||
**リスク1: OVNの複雑さ**
|
||
- **軽減策**: OVN Northbound APIを抽象化したシンプルなAPIレイヤーを提供
|
||
- **軽減策**: よく使う操作（ネットワーク作成、ポート追加）を簡素化
|
||
|
||
**リスク2: OVSDBの運用負荷**
|
||
- **軽減策**: OVSDBクラスタリングのベストプラクティスに従う
|
||
- **軽減策**: 監視とヘルスチェックを実装
|
||
|
||
**リスク3: パフォーマンス懸念**
|
||
- **軽減策**: ハードウェアオフロード（DPDK、SR-IOV）を検討
|
||
- **軽減策**: 必要に応じて将来的にCilium/eBPFへの移行パスを残す
|
||
|
||
### 代替案の検討タイミング
|
||
|
||
以下の場合、代替案を検討：
|
||
1. **パフォーマンスボトルネック**: OVNで解決できない性能問題が発生
|
||
2. **運用複雑さ**: OVNの運用負荷が許容範囲を超える
|
||
3. **新機能要求**: OVNで実現できない機能が必要
|
||
|
||
## 7. 結論
|
||
|
||
**推奨: OVNを採用**
|
||
|
||
- マルチテナントVMネットワーク分離の要件を満たす
|
||
- 成熟したソリューションでリスクが低い
|
||
- PlasmaVMCとの統合が比較的容易
|
||
- 将来の最適化（eBPF移行など）の余地を残す
|
||
|
||
**次のステップ**: S2（テナントネットワークモデル設計）に進む
|