ノードコントローラーを使用してKubernetesノードとIngress NetScaler間のネットワークを確立する

最終公開日 : Oct 02, 2026
Kubernetes環境では、Ingressデバイスを介して外部アクセス用にサービスを公開する場合、KubernetesノードとIngressデバイス間のネットワークを適切に構成する必要があります。
ポッドはCNIフレームワークに基づいてプライベートIPアドレスを使用するため、ネットワークの構成は困難です。適切なネットワーク構成がないと、IngressデバイスはこれらのプライベートIPアドレスにアクセスできません。また、このような到達可能性を確保するためにネットワークを手動で構成することは、Kubernetes環境では面倒です。
また、KubernetesクラスターとIngress NetScaler®が異なるサブネットにある場合、静的ルーティングを使用してそれらの間にルートを確立することはできません。このシナリオでは、KubernetesクラスターとIngress NetScaler間のルートを確立するためにオーバーレイメカニズムが必要です。
NetScalerは、KubernetesノードとIngress NetScaler間に仮想拡張LAN (VXLAN) ベースのオーバーレイネットワークを作成するために使用できるノードコントローラーを提供します。これは次の図に示されています。
CICと連携したCNC
注:
NetScaler Node Controllerは、NetScalerクラスターがIngressデバイスとして構成されているセットアップでは機能しません。ノードコントローラーは、ルートを構成するためにNetScalerとKubernetesノード間にVXLANトンネルを確立する必要がありますが、NetScalerクラスターでのVXLANの作成はサポートされていません。
Related information
ネットワーク

自己修復ルーターポッドとネイティブヘルスチェック

NetScaler Node Controllerリリース3.1.0以降、適格なノードごとに1つのkube-cnc-routerポッドをデプロイして、そのノードとNetScaler間のVXLANオーバーレイを構築できます。この機能強化により、そのフリートは自己修復可能になり、Kubernetesネイティブのヘルスチェックが追加されるため、一時的な問題から回復する単一のノードは手動での操作を必要としません。
この機能により、以下が得られます。
  • ノードごとの自己修復 — ルーターポッドが削除されたり、あるノードで失敗した場合、コントローラーはそのノードのポッドのみを再作成します。コントローラーの再起動は不要で、他のノードへの影響もありません。
  • ノードコントローラーとルーターポッドの両方におけるネイティブのliveness/readinessプローブ。
  • 安定したVTEP IP — ノードはポッドの再作成やコントローラーの再起動後も同じオーバーレイIPを保持するため、ADC PBRのネクストホップは変更されません。
以前は、コントローラーはノードイベントのみを監視し、ルーターConfigMap内のHost-<nodeId>キーの存在をポッドが存在することの証拠として使用していました。ルーターポッドが削除された場合（たとえば、ノードネットワークの一時的な障害の後）、キーは残っていたため、コントローラーはUpdate not required as pod entry found in cmapをログに記録し、ポッドを再作成することはありませんでした。唯一の回避策は、Node Controllerを再起動することでしたが、これはクラスター内のすべてのルーターポッドを再作成するため、正常なノードに影響を与えました。

この機能の仕組み

  • 自己修復: ポッドのライフサイクルウォッチャーは、ノードの削除、障害、またはスタック状態 (ノードが存在し、準備ができており、ノードのテイントを許容することを確認した後) で、そのノードのポッドを再作成します。
  • ヘルスチェック: ノードコントローラー — readiness = インフォーマーキャッシュが同期済み、liveness = 内部ハートビートが最新。ルーターポッド — readiness = オーバーレイ設定完了、liveness = VXLANインターフェースが存在し、そのアドレスを保持している (またはポッドが意図的に停止している)。
  • 安定したVTEP IP: 各ノードのVTEP CIDRは、専用の<router-configmap-name>-vtep ConfigMapに記録され、再作成/再起動のたびに再利用されます。ノードが削除された場合にのみ解放されます。

前提条件

  • Kubernetes環境を使用している場合は、Kubernetes バージョン1.6以降。
  • OpenShiftプラットフォームを使用している場合は、OpenShift バージョン4.8以降。
  • Helm バージョン2.x以降。Helmのインストール に記載されている手順に従ってインストールできます。
  • コントローラーがNetScalerと通信するために必要なイングリッドNetScaler IPアドレスを決定します。IPアドレスは、NetScalerの展開タイプに応じて次のいずれかになります。
    • (スタンドアロンアプライアンス) NSIP - スタンドアロンNetScalerの管理IPアドレス。詳細については、「NetScalerでのIPアドレス指定」を参照してください。
    • (高可用性モードのアプライアンス) SNIP - サブネットIPアドレス。詳細については、「NetScalerでのIPアドレス指定」を参照してください。
  • イングレスNetScaler SNIPを決定します。このIPアドレスは、コントローラーがNetScalerと通信するために必要なKubernetesクラスター間にオーバーレイネットワークを確立するために使用されます。
  • イングレスデバイスとして使用されるNetScaler VPXまたはMPXアプライアンスのユーザー名とパスワード。ノードコントローラーがNetScaler VPXまたはMPXアプライアンスを構成できるように、NetScalerには特定の権限を持つシステムユーザーアカウント (非デフォルト) が必要です。NetScalerでシステムユーザーアカウントを作成する手順については、「NetScalerでNSNCのシステムユーザーアカウントを作成する」を参照してください。
    Kubernetesシークレットを使用してユーザー名とパスワードを渡す必要があります。次のコマンドを使用して、ユーザー名とパスワードのKubernetesシークレットを作成します。
    kubectl create secret generic nsloginns --from-literal=username='nsnc' --from-literal=password='mypassword'

NetScalerでNetScalerノードコントローラーのシステムユーザーアカウントを作成する

ノードコントローラーは、NetScalerのシステムユーザーアカウントを使用してNetScalerを設定します。NSNCがNetScalerで以下を設定する権限を持つように、システムユーザーアカウントは特定の権限を持っている必要があります。
  • ルートの追加、削除、または表示
  • ARPの追加、削除、または表示
  • VXLANの追加、削除、または表示
  • IPの追加、削除、または表示
注記:
システムユーザーアカウントは、定義するコマンドポリシーに基づいて権限を持っている必要があります。
システムユーザーアカウントを作成するには、次の手順を実行します。
  1. NetScalerアプライアンスにログオンします。次の手順を実行します。
    1. PuTTyなどのSSHクライアントを使用して、NetScalerアプライアンスへのSSH接続を開きます。
    2. 管理者資格情報を使用してアプライアンスにログオンします。
  2. 次のコマンドを使用してシステムユーザーアカウントを作成します。
    add system user <username> <password>
    例:
    add system user nsnc mypassword
  3. システムユーザーアカウントに必要な権限を付与するポリシーを作成します。次のコマンドを使用します。
    add cmdpolicy nsnc-policy ALLOW  (^\S+\s+arp)|(^\S+\s+arp\s+.*)|(^\S+\s+route)|(^\S+\s+route\s+.*)|(^\S+\s+vxlan)|(^\S+\s+vxlan\s+.*)|(^\S+\s+ns\s+ip)|(^\S+\s+ns\s+ip\s+.*)|(^\S+\s+bridgetable)|(^\S+\s+bridgetable\s+.*)
  4. 次のコマンドを使用して、ポリシーをシステムユーザーアカウントにバインドします。
    bind system user nsnc nsnc-policy 0

NetScalerノードコントローラーを展開する

ノードコントローラーを使用してネットワーク接続を確立するには:
  1. NetScaler Ingress Controller をデプロイします。次の手順を実行します。
    1. 次のコマンドを使用して、ノードコントローラーのHelmチャートリポジトリを追加します。
      helm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/
    2. リリース名 nsnc を使用してチャートをインストールするには、次のコマンドを使用します。
      helm install nsnc netscaler/netscaler-node-controller --set license.accept=yes,nsIP=<NSIP>,vtepIP=<NetScaler SNIP>,vxlan.id=<VXLAN ID>,vxlan.port=<VXLAN PORT>,network=<IP-address-range-for-VTEP-overlay>,adcCredentialSecret=<Secret-for-NetScaler-credentials>
      または、この後に示すように values.yaml ファイルを作成し、次のコマンドを使用することもできます。
      helm install nsnc netscaler/netscaler-node-controller -f values.yaml
      Values.yaml
      adcCredentialSecret: "nsloginns" # Kubernetes Secret created for login into Netscaler as mentioned in pre-requisite section.
      clusterName: "" # For e.g. "cluster1", provide the name of the cluster, provide same cluster name in NetScaler Ingress Controller deployment as well.
      cniType: "" # provide the CNI supported (canal, flannel, Calico, cilium, weave)
      license:
        accept: 'yes'
      network: "<network>" #for e.g. 172.16.3.0/24 # Give a network IP not conflicting with pod IP range and cluster IP range
      nsIP: <IP-ADDRESS>  # Management IP of the NetScaler (can be NSIP or SNIP with management access enabled for HA and CLIP for cluster)
      vtepIP: <IP-ADDRESS>  # SNIP IP of the NetScaler
      healthProbes:
        enabled: true
      vxlan:
        id: <ID> # VXLAN ID that you want to use
        port: <PORT> # VXLAN PORT that you want to use
      注:
      healthProbes.enabled パラメーターは、Kubernetes の活性プローブと準備プローブがノードコントローラーに追加されるかどうかを制御します。これらのプローブにより、Kubernetes は異常なコントローラーを自動的に検出し、再起動できます。このパラメーターはデフォルトで有効 (true) になっており、ノードコントローラーイメージバージョン 3.1.0 以降が必要です。以前のイメージバージョンを使用している場合は、このパラメーターを false に設定してください。
      異なる引数の詳細については、必須およびオプションのパラメーター を参照してください。
  2. デプロイメントを確認します。
ノードコントローラーをデプロイした後、ノードコントローラーがNetScaler上にルートを設定したかどうかを確認できます。
確認するには、NetScalerにログオンし、次のコマンドを使用して、ノードコントローラーによってNetScalerに設定されたVXLAN VNID、VXLAN PORT、SNIP、ルート、およびブリッジテーブルを確認します。
検証
検証
スクリーンショットのハイライトは、NetScaler 上でノードコントローラーによって設定された VXLAN VNID、VXLAN PORT、SNIP、ルート、およびブリッジテーブルを示しています。

クラスターデプロイメントの検証

netscaler-node-controller デプロイメントとは別に、他のリソースも作成されます。
  • NSNC がデプロイされている名前空間で:
    • 各ワーカーノードに、kube-cnc-router ポッド。
    • ConfigMap kube-cnc-router。
検証
各ワーカーノードに、インターフェース cncvxlan<hash-of-namespace> と iptables ルールが作成されます。
検証 検証
# Delete one node's router pod; a replacement appears within ~30s, other nodes are
# untouched, and the new pod keeps the same VTEP IP.
kubectl delete pod kube-cnc-router-<nodeId> -n <namespace>
kubectl get pods -n <namespace> -w

# The per-node IP allocation survives recreates/restarts
kubectl get configmap <router-configmap-name>-vtep -n <namespace> -o yaml

# Probes on the pod spec
kubectl describe pod <pod> -n <namespace> | grep -A2 -E 'Liveness|Readiness'

NetScaler Kubernetes ノードコントローラーの削除

helm delete nsnc

インターネットアクセスなしで NetScaler ノードコントローラーを実行する

ノードコントローラーは、各 Kubernetes クラスターノードにヘルパーポッド (kube-cnc-router ポッド) を内部的に作成します。デフォルトで使用されるイメージは、インターネットアクセスを必要とする quay.io/citrix/cnc-router:1.1.0 です。Kubernetes ノードがインターネットアクセスを持たない場合、kube-cnc-router ポッドの作成は失敗します。
しかし、NetScaler は、内部リポジトリからイメージにアクセスする方法を提供しており、インターネットアクセスなしでノードコントローラーを実行できます。CNC_ROUTER_IMAGE 環境変数を使用すると、quay.io/citrix/cnc-router:1.1.0 の内部リポジトリイメージを指すことができます。

内部リポジリのイメージを使用するように NetScaler ノードコントローラーを設定する

ノードコントローラーをデプロイする際に、CNC_ROUTER_IMAGE 環境変数を指定し、その変数の値をイメージ quay.io/citrix/cnc-router:1.1.0 の内部リポジトリパスとして設定します。
この環境変数を指定すると、ノードコントローラーは、CNC_ROUTER_IMAGE 環境変数によって提供される内部リポジトリイメージを使用して、kube-cnc-router ヘルパーポッドを作成します。この環境変数が指定されていない場合、インターネットアクセスを必要とするデフォルトイメージ quay.io/citrix/cnc-router:1.1.0 を使用します。ノードコントローラーをデプロイする際に、nsncRouterImage を設定してください。
nsncRouterImage: "quay.io/citrix/cnc-router"

同じクラスターで複数のNetScalerノードコントローラーを実行する

同じクラスターに複数のノードコントローラーをデプロイする場合は、ノードコントローラーをデプロイする際に以下の引数を設定して、CNC_ROUTER_NAME に別の名前を使用してください。
nsncRouterName: "abc-nsnc-router"
ノードコントローラーのデプロイのトラブルシューティングについては、ノードコントローラーのトラブルシューティング を参照してください。