仮想ネットワークのトラブルシューティング
OVNには誰もが一度は陥る典型的な障害パターンがあります。他の何よりも先に、まずこれを知っておく価値があります。
存在しているのに何も機能しないルール
OVNのノースバウンドデータベースは、入力内容の検証をほとんど行いません。データプレーンがコンパイルできない式を持つルールであっても、そのまま受け入れてしまいます。その場合：
- オブジェクトは作成され、
- APIは成功を報告し、
- 管理画面には正常なリソースとして一覧表示されますが、
- 実際には何の効果も発揮しません。
データベースの観点からはオブジェクトが正常に見えるため、Vapor側のUIからはこの問題に気付くことができません。唯一の手がかりはホスト上の ovn-controller のログにあります：
grep -iE "error parsing|Syntax error" /var/log/ovn/ovn-controller.logオブジェクトが存在するのに期待通りに動作しない場合は、必ずこのログ確認を最初のチェックにしてください。代表的な原因は以下の2つです：
- ポートグループまたはアドレスセットの名前にハイフン（
-）が含まれている（OVNが減算記号として解釈する） - DNSサーバーのリスト形式が不正など、不正な形式のオプション値
同じ種類の問題を示すもう1つの兆候：ルールが ovn-sbctl lflow-list には表示されるものの、ovs-ofctl dump-flows br-int に対応するエントリが存在しない場合です。論理ルールは生成されたものの、スイッチによって拒否されたことを示しています。
症状と確認ポイント
仮想マシンがDHCPアドレスを取得できない
- OVNがポート用に記録しているMACアドレスと、ゲストが送信しているMACアドレスが一致しているか確認してください。OVNのDHCPレスポンダーは送信元MACでマッチングするため、両者が一致している必要があります。
- そのサブネットでDHCPが有効になっており、ポートにサブネットのDHCPオプションが関連付けられているか確認してください。
- 前述の通り
ovn-controller.logを確認してください。不正な形式のDHCPオプションがあると、1つのポートだけでなく、そのスイッチ上のすべてのポートでDHCPが停止します。 - ゲストOSが実際にアドレスを要求しているか確認してください。ホットプラグされたインターフェースは自動的には構成されません。
ゲートウェイや同一サブネットには到達できるが、ルーティングされた宛先に到達できない
ほとんどの場合、OVNの問題ではなくゲストOS側のルーティング設定に原因があります。2つ目のインターフェースを持つゲストは、そちらのインターフェースに低いメトリックのデフォルトルートを持っていることが多く、ルーティングされたトラフィックが誤った経路から送出されてしまいます。ネットワークを疑う前に、ゲストのルーティングテーブルを確認してください。
同じ論理スイッチ上のホスト同士が通信できない
- 両方のポートがバインド（bound）されているか確認してください。
ovn-controllerがポートを要求すると、Logical Switch Ports ページでバインド済みとして表示されます。 - 2つのシャーシのトンネルアドレスが、両者が共有するサブネット上にあるか確認してください。到達不能なトンネルアドレスを持つシャーシは登録自体は成功しますが、トンネルは一切形成されません。
- 論理ポートを持たないホストでトンネルポート数が0であることは正常です。OVNはオンデマンドでトンネルを構築します。
起動時に仮想マシンの論理スイッチへのアタッチが失敗する
ホストに ovs-vsctl が必要です。Vaporはこれを使用してインターフェースを統合ブリッジ（br-int）に配置します。これがない場合、マシン起動時に br-int へのポート追加に関するエラーメッセージが表示されて失敗します。OVNステータスカードでこのクライアントが存在するかどうかを確認できます。
ロードバランサーが無応答になる
- ゲートウェイポートを持たない分散ルーターではなく、論理スイッチ にアタッチされているか確認してください。ルーターにアタッチされたバランサーはインバウンドトラフィックのみを変換し、応答を変換しません。
- 仮想IP（VIP）にクライアントのサブネット 外部 のアドレスを指定しているか確認してください。サブネット内のVIPにはARP応答者が存在しないため、パケットが送信される前に接続がハングします。
ACLがブロックすべきトラフィックをブロックしない
- ポートグループおよびアドレスセットの命名規則を確認し、
ovn-controller.logを確認してください。 - リモート（送信元）の指定が実際に記録されているか確認してください。送信元制限のないACLはすべての送信元にマッチするため、意図よりも広範になり、一見「ルールが効いていない」ように見えながら実際にはすべてに適用されている状態になります。
allowはステートレスです。コネクション型通信では必ずallow-relatedを使用してください。そうしないと戻りの応答がドロップされます。
しばらくするとオブジェクトが勝手に消える
共有kube-ovnデプロイメントの場合、kube-ovnのガベージコレクションが原因です。以下を確認してください：
kubectl -n kube-system logs deploy/kube-ovn-controller | grep gc.goまた、コントローラーが再起動していないか確認してください。これを防止するための3つの条件については、仮想ネットワークのアクティベーション のモード3のセクションを参照してください。
kube-ovnデプロイメントでルーターが消滅した
--enable-external-vpc=true が設定されている場合、Vaporの各ルーターはKubernetesの Vpc リソースとしても存在しており、そのカスタムリソースを削除するとOVN内のルーターも削除されます。外部のクリーンアップツールやGitOpsによってプルーニングされていないか確認してください。
クラスター固有のチェック項目
メンバーがクライアントポートでの接続を拒否する
フォロワー（follower）ノードでは正常な動作です。OVSDBクライアントはリーダーとしか通信しないため、メンバー自体が正常であっても、フォロワーに対する直接のクエリは拒否されます。Vaporがすべてのメンバーアドレスを指定してクラスターに接続するのはこのためです。診断目的でフォロワーに直接クエリを送信したい場合は、--no-leader-only を使用してください。
リーダーシップが頻繁に移動する
再起動後や一時的なネットワーク瞬断後には正常な動作です。システム全体の稼働は維持されます。最初にブートストラップしたメンバーとは異なるメンバーにリーダーシップが落ち着くことも異常ではありません。
centralのデータベースが起動しない
起動順序を確認してください。ovn-northd は2つのデータベースサービスが起動していることを前提としており、同時に起動すると競合（レースコンディション）が発生します。まず ovn-ovsdb-server-nb と ovn-ovsdb-server-sb を起動してアクティブであることを確認してから、ovn-northd を起動してください。
再起動後にcentralにデータベースが存在しない
クラスターパラメーターはOVNサービスユニットの構成ファイルに保持されており、それらのユニットが有効化（enable）されている必要があります。Vaporはアクティベーション中にこれらを有効化しますが、失敗した場合はログに警告を出力します。
役立つコマンド
これらはホスト上で実行します。kube-ovnノードでは、ovn-nbctl や ovs-vsctl がホスト上ではなくPod内で実行されている場合があります。
# このホストが認識している自身のロールを確認
ovn-nbctl --db=<nb-address> show
# ポートがバインドされているか、どのシャーシにバインドされているか確認
ovn-sbctl --db=<sb-address> find Port_Binding logical_port=<port>
# データベースのクラスターメンバーシップ状態を確認
ovs-appctl -t /var/run/ovn/ovnnb_db.ctl cluster/status OVN_Northbound
# スイッチ用に生成された論理フロールールを確認
ovn-sbctl lflow-list <switch>
# スイッチに実際にインストールされたフローを確認
ovs-ofctl dump-flows br-int
# サイレントエラーを説明するログを検索
grep -iE "error parsing|Syntax error" /var/log/ovn/ovn-controller.log問題を報告する際の情報
ホストがアクティベートされたモード、どのソースがデータベースアドレスを提供したか（ステータスカードに表示）、ノースバウンドデータベースにオブジェクトが存在するか、スイッチに対応するフローが存在するか、および ovn-controller.log の error parsing の行を含めて報告してください。この5つの情報があれば、設定ミスと実際の障害を最も迅速に切り分けることができます。