Antrea Kubernetes クラスタの状態が「停止」になっている場合は、このドキュメントの手順に従って、問題の原因を特定してリカバリするか、サポート バンドルを収集します。

問題

クラスタ制御プレーン ノードが停止しています。Antrea Kubernetes クラスタが中央制御プレーン (CCP) から切断されています。

原因

NSX Manager ユーザー インターフェイスで、[システム] > [ファブリック] > [ノード] > [コンテナ クラスタ] > [Antrea] の順に移動します。必要に応じて、[Antrea] ページのクラスタのリストを [外部 ID] フィールドでフィルタリングします。

問題のあるクラスタの [状態] 列をクリックします。すべてのコンポーネントが停止している場合、考えられる原因は次のとおりです。
  • Kubernetes クラスタが削除されている。
  • CCP とのネットワーク接続に問題がある。
  • 何らかの理由でアダプタがクラッシュしているか、削除されている。
  • アダプタのクライアント証明書が正しくない。
  • アダプタのバージョンが、CCP と互換性がない。

中央制御プレーン アダプタ のみが停止している場合は、CCP アダプタがクラッシュした可能性があります。

解決方法

  1. Kubernetes クラスタが削除された場合は、NSX に残っている登録データとインベントリ データをクリーンアップします。コマンド ラインを使用した NSX インベントリからの Antrea Kubernetes クラスタの削除を参照してください。
  2. Kubernetes クラスタの kubectl および kubeconfig アクセス権を取得します。kubectl を使用して、インターワーキング ポッドが実行されているノード名を取得します。ノードで SSH セッションを開始し、curl または nc コマンドを使用して、ポート 1234 および 1235 の各 NSX Manager IP に接続します。接続を確立できない場合、CCP とのネットワーク接続に問題があることが原因です。
    curl コマンドの例：

    NSX-Manager-IP を環境内の NSX Manager の IP アドレスに置き換えます。

    curl -v NSX-Manager-IP:1235

Trying NSX-Manager-IP... 
Connected to NSX-Manager-IP (NSX-Manager-IP) port 1235 (#0) 
... 
Empty reply from server 
Connection #0 to host NSX-Manager-IP left intact 
curl: (52) Empty reply from server

    nc コマンドの例：

    nc -v NSX-Manager-IP 1235 < /dev/null

Ncat: Version 7.50 (https://nmap.org/ncat)
Ncat: Connected to NSX-Manager-IP:1235.
Ncat: 0 bytes sent, 0 bytes received in 0.37 seconds.
  3. kubectl を使用して、vmware-system-antrea ネームスペース内のインターワーキング ポッドのすべてのコンテナが稼動しているかどうか確認します。
    いずれかのコンテナが停止している場合は、kubectl を使用して、クラッシュしたコンテナのログを取得し、エラー メッセージを確認します。この手順は、次のいずれかの理由で発生した障害の特定に役立ちます。
    • 何らかの理由でアダプタがクラッシュしているか、削除されている。
    • CCP アダプタがクラッシュしている。
    インターワーキング ポッドを取得する kubectl コマンドの例： 
    kubectl get pod -o wide -l app=antrea-interworking -n vmware-system-antrea

    インターワーキング ポッドの名前をメモします。

    インターワーキング ポッドの詳細な状態を取得する kubectl コマンドの例：

    pod-name は実際のポッド名に置き換えます。

    kubectl get pod -o yaml pod-name -n vmware-system-antrea

    コンテナ ログを取得する kubectl コマンドの例：

    pod-name は実際のポッド名に置き換えます。

    kubectl logs pod-name -c mp-adapter -n vmware-system-antrea > mp-adapter.log
kubectl logs pod-name -c ccp-adapter -n vmware-system-antrea > ccp-adapter.log
kubectl logs pod-name -c tn-proxy -n vmware-system-antrea > tn-proxy.log
kubectl logs pod-name -c election-runner -n vmware-system-antrea > election-runner.log

    vmware-system-antrea ネームスペースがないか、インターワーキング ポッドがない場合は、登録解除の手順を実行せずにアダプタが Kubernetes クラスタから削除された可能性があります。システムに残っている登録データとインベントリをクリーンアップしてから、Kubernetes クラスタを再度登録できます。クラスタを再登録すると、別のクラスタ ID が使用されます。クラスタに適用されている Antrea ポリシーがある場合は、クラスタを再登録した後に、ポリシーを再度適用する必要があります。

    残存する登録データをクリーンアップする手順については、コマンド ラインを使用した NSX インベントリからの Antrea Kubernetes クラスタの削除を参照してください。

    Antrea Kubernetes クラスタを NSX に登録する方法については、NSX への Antrea Kubernetes クラスタの登録を参照してください。

  4. kubectl を使用して、インターワーキング ポッドから nsx-proxy コンテナ ログを取得し、エラー メッセージを確認します。
    この手順は、次のいずれかの理由で発生した障害の特定に役立ちます。
    • アダプタのクライアント証明書が正しくない。
    • アダプタのバージョンが、CCP と互換性がない。

    コマンドの例については、手順 3 を参照してください。

  5. 管理プレーン アダプタ が稼動している場合は、NSX のサポート バンドル機能を使用して、Antrea Kubernetes クラスタのログ ファイルを収集します。

    詳細については、Antrea Kubernetes クラスタのサポート バンドルの収集を参照してください。