仮想ネットワークのアクティベーション
OVNがアクティベートされるまで、Network > OVN ページには何も表示されません。VaporはOVNデータベースの場所や、このホストがどのような役割を果たすかを認識していないためです。アクティベーションによって両方が設定され、Vaporを再起動することなく即座に有効になります。
Network > OVN を開き、アクティベーションウィザードを開始します。すでにアクティベートされているホストでは、同じウィザードが Reconfigure として利用可能です。
設定の保存場所
アクティベーション設定はVapor自身のデータベースに保存されるため、再起動後も保持され、いつでも変更できます。データベースアドレスは3つのソースから提供され、値を持つ最初のソースが優先されます：
- 環境変数 —
VAPOR_OVN_NB_DBおよびVAPOR_OVN_SB_DB - Vaporのデータベース — ウィザードが書き込む内容
vapor.conf—ovn_nb_dbおよびovn_sb_db（UIを開く前にホストを事前設定する場合に便利）
いずれも設定されていない場合、OVNツールはローカルソケットにフォールバックします。これはデータベース自体を保持しているホストでのみ有効です。
ステータスカードには現在使用されているソースが表示されます。変更が反映されないように見える場合は、まずそこを確認してください。サービスに設定された環境変数は、ウィザードが保存した内容よりも優先されます。
ウィザードのステップ別解説
1. モード (Mode)
デプロイメントの形態を選択します。3つのモードについて以下で説明します。モードによって重要な違いがあるため、続行する前に使用するモードの説明をお読みください。
2. 検出 (Discovery)
Vaporはホストを検査し、検出された内容を表示します。インストールされているOVNおよびOVSプログラムとそのバージョン、実行中のサービス、既存の system-id（存在する場合）、候補となるトンネルアドレスと各アドレスが属するサブネット、および（kubeconfigにアクセス可能な場合）そのノードがKubernetesノードであるかどうか、kube-ovnが存在するかどうかを確認します。
検出ステップでは読み取りのみを行います。適用（apply）ステップに進むまで何も変更されません。
Kubernetesノードでは1つの項目が矛盾して見えることがあります。ovn-controller がインストールされていないと報告されながら、同時に実行中と表示される場合があります。これは、kube-ovnがホストサービスとしてではなくPod内でそれを実行しているためであり、正常な挙動です。
3. アドレスとピア (Addresses and peers)
外部OVNまたはkube-ovnデプロイメントの場合、ここでノースバウンド（northbound）およびサウスバウンド（southbound）のアドレスを入力します。Vaporネイティブデプロイメントの場合、ホストが central（データベースを実行）か chassis（データベースに接続するハイパーバイザー）かを指定し、centralの場合は新しいクラスターをブートストラップするか既存のクラスターに参加するかを指定します。
4. ローカルシャーシ (Local chassis)
system-id、トンネルカプセル化タイプとアドレス、およびオプションのブリッジマッピング（bridge mappings）を設定します。
検出で提示された候補からトンネルアドレスを選択します。デプロイメント内の他のすべてのホストが共有するサブネット上のアドレスを選択してください。ピア（他のホスト）が到達できないアドレスを持つシャーシは正常に登録されますが、トンネルが形成されません。これは、デプロイメントが正常に動作しているように見えながらホスト間のトラフィックが無言でドロップされる原因になります。
ブリッジマッピングは、論理ルーターに物理ネットワークへのパスを提供する場合にのみ必要です。詳細は ルーティングと外部接続 を参照してください。
5. 事前チェック (Preflight)
Vaporは一連のチェックを実行し、各チェックの結果とその理由を表示します。fail（失敗）は適用をブロックし、warning（警告）は明示的に確認（acknowledge）する必要があります。
| チェック項目 | 内容 |
|---|---|
ovs_installed | ovs-vsctl が存在すること。これがないと、仮想マシンを論理スイッチにアタッチした状態で仮想マシンを起動する際に失敗します |
ovn_tools_installed | ovn-nbctl および ovn-sbctl が存在し、そのバージョンが確認できること |
nb_reachable / sb_reachable | データベースが応答すること。独自のデータベースを作成するVaporネイティブのcentralではスキップされます |
central_capable | ホストにOVN centralが必要とするsystemdユニットがあること。ovn-ctl 単体では不十分です（ホストパッケージにも同梱されています） |
cluster_remote_reachable | クラスターに参加するcentralの場合、接続先のメンバーに到達可能であること |
encap_ip_valid | トンネルアドレスがこのホスト上に存在すること |
system_id_valid | システムIDが未設定であるか、意図したIDと一致していること |
no_stale_chassis | 異なるIDでのこのホストの古いシャーシ登録が残っていないこと |
kube_ovn_external_vpc | kube-ovnが認識しないオブジェクトを削除しないように構成されていること |
kube_ovn_node_match | このホストがKubernetesノードであること |
6. レビューと適用 (Review and apply)
適用はべき等（idempotent）です。同じ構成で再実行しても、変更の必要がないことが報告されます。処理の途中でステップが失敗した場合、Vaporは変更内容をロールバックし、復元した内容を通知するため、アクティベーションが失敗してもホストの状態が悪化することはありません。
モード 1: Vaporネイティブ (Vapor-native)
VaporがOVNデータベースを実行します。他のシステムがデータベースを所有しておらず、作成したリソースが勝手に削除される心配がないため、まだOVNを実行していないデプロイメントに推奨される構成です。
ホストは central または chassis のいずれかになります：
- central:
ovn-northdとノースバウンドおよびサウスバウンドデータベースを実行し、自身もシャーシとして機能します。 - chassis:
ovn-controllerのみを実行し、centralに接続します。
1台のcentralで冗長性のない完全な動作環境が構成されます。高可用性（HA）を実現するには3台以上を使用してください。2台構成は1台よりも可用性が低下します。過半数（クォーラム）を形成できないため、いずれかのホストが失われるとデプロイメント全体が停止します。
クラスターの形成、ジョイントークン、ホストの追加については、Vaporネイティブクラスター で説明されています。
モード 2: 既存の外部OVN (Existing external OVN)
他の環境で ovn-central が実行されています。そのノースバウンドおよびサウスバウンドのアドレスを指定すると、Vaporはクライアントとして参加し、このホストをシャーシとして構成します。Vaporはそのcentralの再設定を試みることはありません。
これは最もシンプルなモードです。アドレスが応答し、トンネルアドレスが正しければ、他に決定すべきことはありません。
モード 3: 既存のkube-ovnクラスター (Existing kube-ovn cluster)
VaporがKubernetes CNIに属するOVNデータベースを共有します。動作はしますが、kube-ovnは自身がそれらのデータベースを専有していると見なすため、いくつかの前提条件があります。Vaporは事前チェック中に3つの条件すべてを検証します。
kube-ovnに外部オブジェクトをガベージコレクションしないよう指示する必要がある
kube-ovnはOVNをKubernetesリソースと照合し、自身が把握していないリソースを削除します。デフォルト設定のままでは、kube-ovn-controller が1回再起動するだけで、Vaporが作成したすべての論理スイッチとルーターが削除され、定期的なスイープ処理によって2サイクル以内に論理スイッチポートが削除されます。
kube-ovn-controller のデプロイメントで --enable-external-vpc=true を設定してください。このフラグを設定すると、kube-ovn独自のマーカーが付いていないオブジェクトはガベージコレクションの対象から完全に除外されます。
Vaporは検出中にこのフラグを読み取り、設定されていない場合は目立つ警告を表示します。本番環境や重要な環境では、この警告を無視しないでください。
このフラグを有効にすることによる影響
--enable-external-vpc=true を設定すると、kube-ovnは自身が所有していないすべての論理ルーター（Vaporのルーターを含む）に対して、クラスター規模の Vpc カスタムリソースを作成します。そのカスタムリソースを削除すると、OVN内のルーターも削除されます。
これに依存する前に、以下の保護策を講じてください：
- GitOpsの自動プルーニング対象から
Vpcリソースを除外する。 - kube-ovn自身のサービスアカウント以外のユーザーによる、
ovn.kubernetes.io/vpc_external=trueラベルが付いたVpcリソースの削除を拒否するアドミッションポリシーを検討する。
宣言されていないクラスタースコープのリソースは、クリーンアップツールによって真っ先に削除対象とされてしまいます。
すべてのVaporハイパーバイザーはKubernetesノードでもある必要がある
kube-ovnは、Kubernetesノードに対応しないシャーシ登録をすべて削除します。上記のフラグを設定してもこの動作は変わりません。ノードではないハイパーバイザーは、次回のコントローラー再起動時にシャーシ登録を失い、それとともにトンネルも失われます。
事前チェックでは、これを警告ではなく致命的な失敗（ハードフェイル）として扱います。
バージョンに関する注意事項
上記の除外機能は、kube-ovnが独自のオブジェクトにタグを付けることに依存しています。これはv1.15.0以降で行われています。古いクラスター、またはタグ付け移行を実行せずにアップグレードされたクラスターでは、このフラグを有効にすると、同じフィルターを使用して仮想マシンのポートを検索するKubeVirtのライブマイグレーションにも影響を与える可能性があります。有効にする前に、既存のポートに vendor=kube-ovn マーカーが付いていることを確認してください。
ディアクティベート (Deactivating)
Deactivate を実行すると、このホストの ovn-controller が停止し、データベースへの参照がクリアされ、非アクティブとしてマークされます。共有デプロイメントではこれらのオブジェクトは全体で共有されているため、OVNデータベースから論理スイッチ、ルーター、ACLなどが削除されることはありません。
現在OVNを使用しているワークロードが存在するホストでは、ディアクティベートによってネットワーク通信が切断されます。メンテナンス作業として慎重に実行してください。