NetScalerノードコントローラーの問題のトラブルシューティング

最終公開日 : Oct 02, 2026
このトピックでは、ノードコントローラーの使用中に発生する可能性のある問題のトラブルシューティング方法について説明します。ログを収集して原因を特定し、ノードコントローラーの構成に関連する一般的な問題の回避策を適用できます。
ノードコントローラーと基本的なノード構成を検証するには、展開 ページの画像を参照してください。
Related information
アップグレードとトラブルシューティング

ルーターポッドが起動しない

kube-nsnc-router ポッドが起動しない場合、非管理者ユーザー/権限による特権ポッドのデプロイを妨げる特定のクラスター制限が原因である可能性があります。
回避策として、次のいずれかを実行してください。
  1. ノードコントローラーをデプロイするには、kube-system 名前空間を使用します。
  2. ノードコントローラー clusterrolebinding に cluster-admin ロールを割り当てます。
注:
オプション1を選択した場合、クラスターごとに利用可能な kube-system 名前空間は1つしかないため、単一のクラスターでノードコントローラーの複数のインスタンスを作成することはできません。

サービスステータスがDOWN

サービスが「ダウン」状態にあるときに問題をデバッグするには、次の手順を実行します。
  1. 次のコマンドを使用して、ノードコントローラーポッドのログを確認します。
    kubectl logs <nsnc-pod> -n <namespace>
    ログに「permission」エラーがないか確認します。ノードコントローラーは kube-nsnc-router ポッドを作成しますが、これはノードで構成を実行するために NET_ADMIN 特権を必要とします。したがって、ノードコントローラーサービスアカウントは NET_ADMIN 特権とホストモード kube-nsnc-routerpods を作成する能力を持っている必要があります。
  2. 次のコマンドを使用して、kube-nsnc-router ポッドのログを確認します。
    kubectl logs <kube-nsnc-pod> -n <namespace>
    ノード構成にエラーがないか確認します。以下はルーターポッドログのサンプルです。
    ルーターポッドログ
  3. 次のコマンドを使用して、kube-nsnc-router ConfigMap の出力を確認します。
    kubectl get configmaps -n <namespace> kube-nsnc-router -o yaml
    ConfigMap の「data」セクションに空のフィールドがないか確認します。以下は2ノードのデータセクションのサンプルです。
    ルーターデータセクション
  4. ノード構成を確認し、以下を確実にします。
    • ノードコントローラーインターフェイス nsncvxlan<md5_of_namespace> が作成されていること。
      • 割り当てられたVTEP IPアドレスが、NetScalerの対応するルーターゲートウェイエントリと同じであること。
      • インターフェイスのステータスが機能していること。
    • iptable ルールポートが作成されていること。
      • ポートがNetScalerで作成されたVXLANと同じであること。
    ワーカー1

サービスステータスは稼働中だが、NetScalerからのpingが機能しない

この問題は、SRCIPをNSIPとしてNetScalerからのパケットをデフォルトゲートウェイに転送するPBRエントリの存在が原因で発生する可能性があります。この問題は、いかなる機能にも影響を与えません。
NetScalerコマンドラインインターフェイスでpingコマンドの-Sオプションを使用して、NetScalerのVTEPを送信元IPアドレスとして使用できます。例：
ping <serviceIP> -S <vtepIP>
注:
NSIP自体でpingする必要がある場合は、PBRエントリを削除するか、優先度の高いエンドポイントのPBRエントリを追加する必要があります。

ポッドエンドポイントまたはVIPへのcURLが機能しない

サービスが稼働状態であっても、ポッドエンドポイントにcURLできない場合、エンドポイントへのステートフルTCPセッションが失敗していることを意味します。1つの理由として、nsモード「MBF」が有効に設定されている可能性があります。この問題はデプロイメントに依存し、NetScalerの特定のバージョンでのみ発生する可能性があります。
この問題を解決するには、MBF nsモードを無効にするか、netprofileが無効になっているnetprofileをサービスグループにバインドする必要があります。
注:
MBFを無効にすることで問題が解決する場合は、MBFを無効に設定し続ける必要があります。

カスタマーサポート

一般的なサポートについては、カスタマーサポートに問題を提起する際に、より迅速なデバッグに役立つ以下の詳細情報を提供してください。NetScalerからエンドポイントへのcURLまたはpingを実行し、以下の詳細情報を取得してください。
ノードについては、以下のコマンドの詳細情報を提供してください。
  1. ノード上のノードコントローラーインターフェースでのtcpdumpキャプチャ。
    tcpdump -i nsncvxlan<hash_of_namesapce> -w nsncvxlan.pcap
  2. ノードMgmtインターフェースでのtcpdumpキャプチャ（例: "eth0"）。
    tcpdump -i eth0 -w mgmt.pcap
  3. CNIインターフェースでのtcpdumpキャプチャ（例: "vxlan.calico"）。
    tcpdump -i vxlan.calico -w cni.pcap
  4. ノード上のifconfig -aの出力。
  5. ノード上のiptables -Lの出力。
NetScalerについては、以下のshowコマンドの詳細を提供してください。
  1. show ip
  2. show vxlan <vxlan_id>
  3. show route
  4. show arp
  5. show bridgetable
  6. show ns pbrs
  7. show ns bridgetable
  8. show ns mode
  9. ping/cURLを使用してnstraceをキャプチャしてみてください。
    start nstrace -size 0 -mode rx new_rx txb tx -capsslkeys enABLEDstop nstrace