NetScaler® GSLBコントローラー（シングルサイト用）

最終公開日 : Oct 02, 2026
Related information
NetScaler GSLB コントローラー

概要

高可用性、近接性ベースの負荷分散、およびスケーラビリティを確保するには、複数のKubernetesクラスターにアプリケーションをデプロイする必要があります。GSLBソリューションは、Ingressを使用して公開されるKubernetesサービスのパフォーマンスと信頼性を向上させます。NetScaler GSLBコントローラーは、地理的に分散した場所間でサービスを負荷分散するようにNetScaler（GSLBデバイス）を構成します。シングルサイトGSLBソリューションでは、データセンター内のGSLBデバイスは、データセンターの各KubernetesクラスターにデプロイされたGSLBコントローラーによって構成されます。このGSLBデバイスは、データセンターの複数のクラスターにデプロイされたサービスを負荷分散します。
次の図は、2つのKubernetesクラスターと単一のGSLBサイトを持つデータセンターにおけるNetScaler GSLBコントローラーの展開トポロジを示しています。
注:
GSLBとIngressに使用されるNetScaler（MPXまたはVPX）は、同じでも異なっていてもかまいません。次の図では、GSLBとIngressに同じNetScalerが使用されています。
シングルサイトGSLB展開トポロジ
以下の手順の番号は、前の図の番号に対応しています。
  1. 各クラスターでは、NetScaler Ingress ControllerがIngressを使用してNetScalerを構成します。
  2. 各クラスターでは、NetScaler GSLBコントローラーがGSLB構成でGSLBデバイスを構成します。
  3. アプリケーションURLのDNSクエリは、NetScalerで構成されたGSLB仮想サーバーに送信されます。GSLB仮想サーバーでのDNS解決は、構成されたグローバル・トラフィック・ポリシー（GTP）に基づいて、いずれかのクラスター上のIPアドレスに解決されます。
  4. DNS解決に基づいて、データトラフィックは、IngressフロントエンドIPアドレスまたはいずれかのクラスターのコンテンツスイッチング仮想サーバーIPアドレスのいずれかに到達します。
  5. 必要なアプリケーションは、GSLBデバイスを介してアクセスされます。

NetScaler GSLBコントローラーの展開

前提条件

  • クラウドまたはオンプレミスでホストされているKubernetesクラスターへのアクセス。クラウド内のKubernetesクラスターは、マネージドKubernetes（例：GKE、EKS、AKS）またはカスタム作成されたKubernetesデプロイメントのいずれかです。Kubernetesクラスターは適切に構成され、稼働している必要があります。NetScalerとクラスターのPodネットワーク間のネットワーク接続が確保されていることを確認してください。
  • Kubernetesデプロイメントの場合、バージョン1.21以降を実行しているKubernetesクラスターへのアクセスが必要です。
  • OpenShiftデプロイメントの場合、バージョン4.11以降を実行しているOpenShiftクラスターへのアクセスが必要です。
  • Helmバージョン3.x以降がインストールされていること。Helmのインストールについては、こちらを参照してください。
  • NetScaler MPX/VPXは、特定のニーズに応じて、スタンドアロン、HA、またはクラスター構成でデプロイされます。
  • NetScaler Ingress ControllerがNetScalerと通信するために使用するNSIP (NetScaler IP) アドレスを決定します。IPアドレスは、NetScalerデプロイメントのタイプに応じて、以下のいずれかになります。
    • NSIP (スタンドアロンアプライアンスの場合) - スタンドアロンNetScalerアプライアンスの管理IPアドレスです。詳細については、NetScalerでのIPアドレス指定を参照してください。
    • SNIP (高可用性モードのアプライアンスの場合) - サブネットIPアドレスです。詳細については、NetScalerでのIPアドレス指定を参照してください。
    • CLIP (クラスターモードのアプライアンスの場合) - クラスターNetScaler展開のクラスター管理IP (CLIP) アドレスです。詳細については、クラスターのIPアドレス指定を参照してください。
  • NetScaler VPXまたはNetScaler MPXのユーザーアカウント。NetScaler Ingress Controllerは、NetScaler内のシステムユーザーアカウントを使用してNetScaler MPXまたはNetScaler VPXを構成します。NetScalerでシステムユーザーアカウントを作成する手順については、NetScaler Ingress Controller 用のNetScalerシステムユーザーアカウントの作成を参照してください。
    ユーザー名とパスワードを直接渡すか、Kubernetesシークレットを使用できます。Kubernetesシークレットを使用する場合は、次のコマンドを使用してユーザー名とパスワードのシークレットを作成します。
    kubectl create secret generic nslogin --from-literal=username=<username> --from-literal=password=<password>

シングルサイト向けGSLBコントローラーのデプロイ手順

この手順では、サイトの2つのクラスターに同じHTTPSアプリケーションをデプロイし、各クラスターにGSLBコントローラーをデプロイします。これにより、GSLBコントローラーはGSLBデバイス（NetScaler VPXまたはNetScaler MPX）を構成し、クラスター全体にデプロイされたサービスの負荷分散を行います。
注記:
  • シングルサイトGSLBソリューションをセットアップするには、両方のクラスターで以下の手順を繰り返します。特定クラスターで実行すべきことを強調する例外が一部の手順に追加されていますので、それに応じて手順を実行してください。
  • アプリケーションの名前空間にイングレスリソースをデプロイする必要があります。
  • GTPおよびGSEリソースは同じ名前空間にデプロイする必要があります。これらのリソースはアプリケーションの名前空間にデプロイすることをお勧めします。
  1. NetScaler VPXまたはNetScaler MPXで、証明書署名要求 (CSR) の共通名としてcnn.comを使用して証明書-キーペアを作成します。証明書-キーペアの作成については、証明書の作成を参照してください。
  2. 次のコマンドを使用してCNNアプリケーションをデプロイします。
    kubectl apply -f - <<EOF
    apiVersion: apps/v1
    kind: Deployment
    metadata:
    name: cnn-website
    labels:
      name: cnn-website
      app: cnn-website
    spec:
    selector:
      matchLabels:
        app: cnn-website
    replicas: 2
    template:
      metadata:
        labels:
          name: cnn-website
          app: cnn-website
      spec:
        containers:
        - name: cnn-website
          image: quay.io/sample-apps/cnn-website:v1.0.0
          ports:
          - name: http-80
            containerPort: 80
          - name: https-443
            containerPort: 443
    ---
    apiVersion: v1
    kind: Service
    metadata:
    name: cnn-website
    labels:
      app: cnn-website
    spec:
    type: NodePort
    ports:
    - name: http-80
      port: 80
      targetPort: 80
    - name: https-443
      port: 443
      targetPort: 443
    selector:
      name: cnn-website
    EOF
    注記:
    OpenShiftのデプロイでは、次のコマンドoc adm policy add-scc-to-user anyuid system:serviceaccount:<namespace>:defaultを実行して、サービスアカウントに特定のセキュリティコンテキスト制約 (SCC) を付与します。<namespace>をCNNアプリケーションをデプロイした実際の名前空間に置き換えてください。
  3. NSICをデプロイします。
    1. 次のコマンドを使用して、NetScaler HelmチャートリポジトリをローカルのHelmレジストリに追加します。
      helm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/
      NetScaler Helmチャートリポジトリがすでにローカルレジストリに追加されている場合は、次のコマンドを使用してリポジトリを更新します。
      helm repo update netscaler
    2. values.yamlを更新して、以下に示すようにNetScaler Ingress Controllerを構成します。
      cluster1の例 values.yaml
      license:
        accept: yes
      adcCredentialSecret: nslogin # K8s Secret created as part of prerequisiste
      nsIP: <x.x.x> # CLIP (for appliances in Cluster mode), SNIP (for appliances in High Availability mode) , NSIP (for standalone appliances)
      openshift: false # set to true for OpenShift deployments
      entityPrefix: cluster1 # unique for each NSIC instance.
      clusterName: cluster1
      ingressClass: ['nsic-vpx'] # ingress class used in the ingress resources
       # serviceClass- To use service type LB, specify the service class
      cluster2の例 values.yaml
      license:
        accept: yes
      adcCredentialSecret: nslogin # K8s Secret created as part of prerequisiste
      nsIP: <x.x.x> # CLIP (for appliances in Cluster mode), SNIP (for appliances in High Availability mode) , NSIP (for standalone appliances)
      openshift: false # set to true for OpenShift deployments
      entityPrefix: cluster2 # unique for each NSIC instance.
      clusterName: cluster2
      ingressClass: ['nsic-vpx'] # ingress class used in the ingress resources
      # serviceClass- To use service type LB, specify the service class
    3. 次のコマンドを実行して、Helmチャートを使用してNSICをインストールします。
      helm install nsic netscaler/netscaler-ingress-controller -f values.yaml
      NSICインストール中に設定できる必須およびオプションのパラメータについては、設定を参照してください。
      注:
      以前のバージョンのNSICがすでにクラスターにデプロイされている場合は、次のコマンドを使用してCRD仕様をデプロイします: kubectl apply -f https://raw.githubusercontent.com/netscaler/netscaler-helm-charts/refs/heads/master/netscaler-ingress-controller/crds/crds.yaml。
  4. 次のイングレスリソースをデプロイします。
    cluster1のイングレスリソース。
    kubectl apply -f - <<EOF
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
     name: frontend-ingress
     annotations:
       ingress.citrix.com/frontend-ip: <NSVIP1> # vserver IP1
       ingress.citrix.com/preconfigured-certkey: '{"certs": [{"name": "singlesite", "type": "default"}]}' # provide the certificate key created in step 1
    spec:
     tls:
     - {}
     ingressClassName: nsic-vpx
     rules:
       - host: cnn.com
         http:
           paths:
             - path: /
               pathType: Prefix
               backend:
                 service:
                   name: cnn-website
                   port:
                     number: 80
    EOF
    cluster2のイングレスリソース。
    kubectl apply -f - <<EOF
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend-ingress
      annotations:
        ingress.citrix.com/frontend-ip: <NSVIP2> # vserver IP2
        ingress.citrix.com/preconfigured-certkey: '{"certs": [{"name": "singlesite", "type": "default"}]}' # provide the name of the certificate key created in step 1
    spec:
      tls:
        - {}
      ingressClassName: nsic-vpx
      rules:
        - host: cnn.com
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: cnn-website
                    port:
                      number: 80
    EOF
  5. GSLBコントローラーがGSLBデバイスに接続し、GSLBコントローラーから構成をプッシュするために必要なシークレットを作成します。
    kubectl create secret generic secret--from-literal=username=<username for gslb device>--from-literal=password=<password for gslb device>
    注:
    • このシークレットは、GSLBコントローラーのhelm installコマンドで、それぞれのサイトのパラメータとして提供されます。コマンドでNetScaler (GSLBデバイス) ユーザーの資格情報をusernameおよびpasswordとして指定します。
    • この場合、GSLBデバイスとイングレスデバイスが同じであるため、前提条件セクションで作成された同じシークレットを使用できます。
  6. 次のコマンドを実行して、Helmチャートを使用してGSLBコントローラーをインストールします。
    helm install my-release netscaler/netscaler-gslb-controller -f values.yaml
    注:
    このチャートは、推奨されるRBACロールとロールバインディングをデフォルトでインストールします。
    例のvalues.yamlファイル:
    license:
      accept: yes
    localRegion: "east"
    localCluster: "cluster1"  # use cluster2 when deploying GSLB controller in cluster2
    entityPrefix: "gslb" # should be same for GSLB controller in both clusters
    nsIP: "x.x.x.x"
    openshift: false # set to true for OpenShift deployments
    adcCredentialSecret: <Secret-for-NetScaler-credentials>
    sitedata:
      - siteName: "site1"
        siteIp: "x.x.x.x"
        siteMask:
        sitePublicip:
        secretName: "secret"
        siteRegion: "east"
    YAMLファイルで次のパラメータを指定します。
    パラメータ 説明
    LocalRegion GSLBコントローラーがデプロイされているローカルリージョン。この値は、すべてのクラスターにわたるGSLBコントローラーのデプロイメントで同じです。
    LocalCluster GSLBコントローラーがデプロイされているクラスターの名前。この値は、Kubernetesクラスターごとに一意です。
    sitedata.サイト名 GSLBサイトの名前。
    sitedata.サイトIP GSLBサイトのIPアドレス。サイト1のNetScalerのIPアドレスをsitedata.siteIpとして追加します。
    sitedata.サイトマスク GSLBサイトIPアドレスのネットマスク。
    sitedata.サイトパブリックIP GSLBサイトのサイトパブリックIPアドレス。
    sitedata.シークレット名 GSLBサイトのログイン資格情報を含むシークレットの名前。
    サイトデータ.サイトリージョン GSLBサイトのリージョン。
    NSIP GSLBデバイスのSNIP (サブネットIPアドレス)。NetScalerにsitedata.siteIpをSNIPとして追加します。
    adcCredentialSecret NetScaler VPXまたはMPXのログイン資格情報を含むKubernetesシークレット。
    各クラスターにGSLBコントローラーが正常にインストールされると、GSLBサイトとADNSサービスが構成され、GSLBサイトのIPアドレスで管理アクセスが有効になります。
    注:
    以前のバージョンのGSLBコントローラーがクラスターにすでにデプロイされている場合は、次のコマンドを使用してGTPおよびGSE CRD仕様をデプロイします: kubectl apply -f https://raw.githubusercontent.com/netscaler/netscaler-k8s-ingress-controller/master/gslb/Manifest/gtp-crd.yaml および kubectl apply -f https://raw.githubusercontent.com/netscaler/netscaler-k8s-ingress-controller/master/gslb/Manifest/gse-crd.yaml。
  7. 要件に基づいてグローバル・トラフィック・ポリシーをデプロイします。
    注:
    • GTP構成がすべてのクラスターで同じであることを確認してください。GTP CRDと許可される値の詳細については、GTP CRDを参照してください。
    • GTP YAMLの宛先情報は、servicename.namespace.region.clusterの形式である必要があります。ここで、サービス名と名前空間は、それぞれServiceタイプのKubernetesオブジェクトとその名前空間に対応します。
    カナリアおよびフェイルオーバーデプロイメントのロードバランシング方法を指定できます。
    • 例1：ラウンドロビン展開
      この展開を使用して、トラフィックをクラスター全体に均等に分散します。次の例では、ラウンドロビン展開用にGTPを構成します。 weightフィールドを使用して、より多くのクライアント要求をグループ内の特定のクラスターに誘導できます。
      kubectl apply -f - <<EOF
      apiVersion: "citrix.com/v1beta1"
      kind: globaltrafficpolicy
      metadata:
        name: gtp1
      spec:
        serviceType: 'HTTP'
        hosts:
        - host: 'cnn.com'
          policy:
            trafficPolicy: 'ROUNDROBIN'
            targets:
            - destination: 'cnn-website.default.east.cluster1'
              weight: 2
            - destination: 'cnn-website.default.east.cluster2'
              weight: 5
            monitor:
            - monType: http
              uri: ''
              respCode: 200
      EOF
    • 例2：フェイルオーバー展開
    このポリシーを使用して、アプリケーションをアクティブ/パッシブモードで構成します。フェイルオーバー展開では、アプリケーションは複数のクラスターに展開されます。フェイルオーバーは、GTPポリシーでターゲット宛先に割り当てられた重みに基づいて、ターゲット宛先のインスタンス間で実現されます。
    次の例は、フェイルオーバーのGTP構成例を示しています。primaryフィールドを使用して、どのターゲット宛先がアクティブで、どのターゲット宛先がパッシブであるかを指定できます。primaryフィールドのデフォルト値はTrueで、ターゲット宛先がアクティブであることを示します。各クラスターのエンドポイントにモニターをバインドして、そのヘルスをプローブします。
    kubectl apply -f - <<EOF
    apiVersion: "citrix.com/v1beta1"
    kind: globaltrafficpolicy
    metadata:
      name: gtp1
    spec:
      serviceType: 'HTTP'
      hosts:
      - host: 'cnn.com'
        policy:
          trafficPolicy: 'FAILOVER'
          secLbMethod: 'ROUNDROBIN'
          targets:
          - destination: 'cnn-website.default.east.cluster1'
            weight: 1
          - destination: 'cnn-website.default.east.cluster2'
            primary: false
            weight: 1
          monitor:
          - monType: http
            uri: ''
            respCode: 200
    EOF
    • 例3：RTT展開
      このポリシーを使用して、ネットワークのリアルタイムステータスを監視し、クライアント要求を最も低いRTT値を持つターゲット宛先に動的に誘導します。
      次の例では、RTT展開用にGTPを構成します。
      kubectl apply -f - <<EOF
      apiVersion: "citrix.com/v1beta1"
      kind: globaltrafficpolicy
      metadata:
        name: gtp1
      spec:
        serviceType: 'HTTP'
        hosts:
        - host: 'cnn.com'
          policy:
            trafficPolicy: 'RTT'
            targets:
            - destination: 'cnn-website.default.east.cluster1'
            - destination: 'cnn-website.default.east.cluster2'
            monitor:
            - monType: http
              uri: ''
              respCode: 200
      EOF
    • 例4：カナリア展開
      カナリア展開は、アプリケーションの新しいバージョンを本番環境に移行する前に、選択したクラスターにロールアウトする場合に使用します。
      このセクションでは、カナリア展開を使用したグローバル・トラフィック・ポリシーの例について説明します。このポリシーでは、アプリケーションの新しいバージョンを本番環境に展開する前に、段階的にロールアウトする必要があります。
      この例では、アプリケーションの安定版がcluster2に展開されます。アプリケーションの新しいバージョンはcluster1に展開されます。weightフィールドを使用して、各クラスターにリダイレクトされるトラフィックの量を指定します。ここでは、weightが40パーセントと指定されています。したがって、トラフィックの40パーセントのみが新しいバージョンに誘導されます。宛先にweightフィールドが指定されていない場合、それは大部分のトラフィックを受け取る本番環境の一部と見なされます。アプリケーションの新しいバージョンが安定したら、新しいバージョンを他のクラスターにロールアウトできます。
      kubectl apply -f - <<EOF
      apiVersion: "citrix.com/v1beta1"
      kind: globaltrafficpolicy
      metadata:
        name: gtp1
        namespace: default
      spec:
        serviceType: 'HTTP'
        hosts:
        - host: 'cnn.com'
          policy:
            trafficPolicy: 'CANARY'
            secLbMethod: 'ROUNDROBIN'
            targets:
            - destination: 'cnn-website.default.east.cluster1'
              weight: 40
            - destination: 'cnn-website.default.east.cluster2'
            monitor:
            - monType: http
              uri: ''
              respCode: 200
      EOF
    • 例5：静的近接性
    このポリシーを使用して、近接性基準に最も一致するサービスを選択します。次のトラフィックポリシーは、静的近接性展開の例です。
    注：
    静的近接性の場合、ロケーションデータベースを手動で適用する必要があります: add locationfile /var/netscaler/inbuilt_db/Citrix_Netscaler_InBuilt_GeoIP_DB_IPv4。
    kubectl apply -f - <<EOF
    apiVersion: "citrix.com/v1beta1"
    kind: globaltrafficpolicy
    metadata:
      name: gtp1
      namespace: default
    spec:
      serviceType: 'HTTP'
      hosts:
      - host: 'cnn.com'
        policy:
          trafficPolicy: 'STATICPROXIMITY'
          targets:
          - destination: 'cnn-website.default.east.cluster1'
          - destination: 'cnn-website.default.east.cluster2'
          monitor:
          - monType: http
            uri: ''
            respCode: 200
    EOF
    • 例 6: ソースIP永続性
    次のトラフィックポリシーは、パラメータ sourceIpPersistenceId を指定してソースIP永続性を有効にする例です。
    kubectl apply -f - <<EOF
    apiVersion: "citrix.com/v1beta1"
    kind: globaltrafficpolicy
    metadata:
      name: gtp1
      namespace: default
    spec:
      serviceType: 'HTTP'
      hosts:
      - host: 'cnn.com'
        policy:
          trafficPolicy: 'ROUNDROBIN'
          sourceIpPersistenceId: 300
          targets:
          - destination: 'cnn-website.default.east.cluster1'
            weight: 2
          - destination: 'cnn-website.default.east.cluster2'
            weight: 5
          monitor:
          - monType: http
            uri: ''
            respCode: 200
    EOF
  8. GSEリソースをデプロイします。
    GSE構成は、クラスターエンドポイント情報に基づいて特定のクラスターに適用されます。GSE名は、グローバルなトラフィックポリシーにおけるターゲット宛先名と同じである必要があります。
    注:
    GSEの作成はオプションです。GSEが作成されていない場合、NetScaler Ingress Controllerはホストが <svcname>.<namespace>.<region>.<cluster> 形式に一致するイングレスを探します。
    以前の例で述べたグローバルなトラフィックポリシーの場合、次のYAMLはcluster1のグローバルサービスエントリです。この例では、グローバルサービスエントリ名 cnn.default.east.cluster1 は、グローバルなトラフィックポリシーにおけるターゲット宛先名の一つです。
    kubectl apply -f - <<EOF
    apiVersion: "citrix.com/v1beta1"
    kind: globalserviceentry
    metadata:
      name: 'cnn-website.default.east.cluster1'
    spec:
      endpoint:
        ipv4address: NSVIP1 # vserver IP1
        monitorPort: 80
    EOF
    以前の例で述べたグローバルなトラフィックポリシーの場合、次のYAMLはcluster2のグローバルサービスエントリです。この例では、グローバルサービスエントリ名 cnn.default.east.cluster2 は、グローバルなトラフィックポリシーにおけるターゲット宛先名の一つです。
    kubectl apply -f - <<EOF
    apiVersion: "citrix.com/v1beta1"
    kind: globalserviceentry
    metadata:
      name: 'cnn-website.default.east.cluster2'
    spec:
      endpoint:
        ipv4address: NSVIP2 # vserver IP2
        monitorPort: 80
    EOF
  9. DNSクエリを送信するには、次のコマンドを使用します。
    dig@siteIP cnn.com