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

最終公開日 : Oct 02, 2026
以下の手順では、クラスターにGSLBコントローラーを展開する方法について説明します。
注記：
他のクラスターにGSLBコントローラーを展開するには、手順1から5を繰り返します。
  1. GSLBコントローラーがGSLBデバイスに接続し、GSLBコントローラーから構成をプッシュするために必要なシークレットを作成します。
    kubectl create secret generic secret-1  --from-literal=username=<username for gslb device1>  --from-literal=password=<password for gslb device1> --from-literal=sitesyncpassword=<password1 for secure site-to-site communication>kubectl create secret generic secret-2  --from-literal=username=<username for gslb device2>  --from-literal=password=<password for gslb device2> --from-literal=sitesyncpassword=<password2 for secure site-to-site communication>
    注記：
    • これらのシークレットは、各サイトのhelm installコマンドを使用してGSLBコントローラーをインストールする際のパラメーターとして提供されます。コマンド内のusernameとpasswordは、NetScaler GSLBデバイスユーザーの資格情報を指定します。NetScalerでシステムユーザーアカウントを作成する方法については、「NetScalerでNetScaler Ingress Controllerのシステムユーザーアカウントを作成する」を参照してください。
    • GSLBコントローラーバージョン2.3.15以降、GSLBサイト間の通信のセキュリティを強化するために、上記のシークレットを作成する際に、追加のキーsitesyncpasswordがサポートされます。sitesyncpasswordキーが提供されない場合、GSLBサイト間の通信にはデフォルトのpasswordキーが使用されます。
  2. 次のコマンドを使用して、NetScaler HelmチャートリポジトリをローカルのHelmレジストリに追加します。
    helm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/
    NetScaler Helmチャートリポジトリがすでにローカルレジストリに追加されている場合は、次のコマンドを使用してリポジトリを更新します。
    helm repo update netscaler
  3. 次のコマンドを実行して、Helmチャートを使用してクラスターにGSLBコントローラーをインストールします。
    注記：
    NetScaler Operatorを使用してGSLBコントローラーをインストールする方法については、「NetScaler Operatorを使用してOpenShiftにNetScaler GSLBコントローラーを展開する」を参照してください。
    helm install gslb-release netscaler/netscaler-gslb-controller -f values.yaml
    注記：
    このチャートは、推奨されるRBACロールとロールバインディングをデフォルトでインストールします。
    例 values.yaml ファイル:
    license:
      accept: yes
    localRegion: "east"
    localCluster: "cluster1"
    openshift: false # set to true for OpenShift deployments
    entityPrefix: "k8s"

    sitedata:
    - siteName: "site1"
      siteIp: "x.x.x.x"
      siteMask: "y.y.y.y"
      sitePublicIp: "z.z.z.z"
      secretName: "secret-1"
      siteRegion: "east"
    - siteName: "site2"
      siteIp: "x.x.x.x"
      siteMask: "y.y.y.y"
      sitePublicIp: "z.z.z.z"
      secretName: "secret-2"
      siteRegion: "west"
    values.yml ファイルで以下のパラメータを指定します。
    パラメータ 説明
    LocalRegion GSLB コントローラーが展開されているローカルリージョン。
    LocalCluster GSLB コントローラーが展開されているクラスターの名前。この値は、各 Kubernetes クラスターで一意です。
    entityPrefix NetScaler VPX/MPX 上のリソースのプレフィックス。注: entityPrefix はすべてのクラスターで同じである必要があります。
    サイトデータ.サイト名 GSLB デバイスで構成されている最初の GSLB サイトの名前。
    サイトデータ.サイトIP 最初の GSLB サイトの IP アドレス。site1 の NetScaler の IP アドレスを sitedata.siteIp として追加します。
    サイトデータ.サイトマスク 最初のGSLBサイトIPアドレスのネットマスク。
    サイトデータ.サイトパブリックIP 最初のGSLBサイトのパブリックIPアドレス。
    サイトデータ.シークレット名 最初のGSLBサイトのログイン資格情報を含むシークレットの名前。
    サイトデータ.サイトリージョン 最初のサイトのリージョン。
    サイトデータ.サイト名 GSLBデバイスで構成された2番目のGSLBサイトの名前。
    サイトデータ.サイトIP 2番目のGSLBサイトのIPアドレス。site2のNetScalerのIPアドレスをsitedata.siteIpとして追加します。
    サイトデータ.サイトマスク 2番目のGSLBサイトIPアドレスのネットマスク。
    サイトデータ.サイトパブリックIP 2番目のGSLBサイトのパブリックIPアドレス。
    サイトデータ.シークレット名 2番目のサイトのログイン資格情報を含むシークレット。
    サイトデータ.サイトリージョン 2番目のサイトのリージョン。
    注:
    GSLBサイト情報の順序は、すべてのクラスターで同じである必要があります。順序の最初のサイトは、構成をプッシュするためのプライマリサイトと見なされます。そのプライマリサイトがダウンすると、リスト内の次のサイトが新しいプライマリになります。 たとえば、cluster1でサイトの順序がsite1の後にsite2が続く場合、他のすべてのクラスターも同じ順序である必要があります。
  4. 次のコマンドを使用してインストールを確認します: kubectl get pods -l app=gslb-release-netscaler-gslb-controller。
    各クラスターにGSLBコントローラーが正常にインストールされると、ADNSサービスが構成され、両方のGSLBデバイスで管理アクセスが有効になります。
Related information
NetScaler GSLB コントローラー

GSLB構成を同期する

プライマリNetScaler GSLBデバイスで次のコマンドを同じ順序で実行し、プライマリGSLBデバイスとセカンダリGSLBデバイス間でGSLB構成の自動同期を有効にします。
set gslb parameter -automaticconfigsync enable
sync gslb config -debug

グローバル・トラフィック・ポリシー (GTP) 展開の例

GTP構成は、すべてのクラスターで同じである必要があります。
以下の例では、アプリケーションapp1が東リージョンのcluster1のデフォルト名前空間と、西リージョンのcluster2のデフォルト名前空間に展開されています。
注:
GTP yamlの宛先情報は、servicename.namespace.region.clusterの形式である必要があります。ここで、servicenameとnamespaceは、Service種類のKubernetesオブジェクトとその名前空間に対応します。
カナリアおよびフェイルオーバー展開の負荷分散方法を指定できます。
NSICリリース2.1.4以降、GSLBセットアップのサービスに対して複数のモニターを構成できます。詳細については、「GSLBのマルチモニターサポート」を参照してください。

例1：ラウンドロビン展開

この展開を使用して、クラスター全体にトラフィックを均等に分散します。次の例では、ラウンドロビン展開のGTPを構成します。
weightフィールドを使用して、より多くのクライアント要求をグループ内の特定のクラスターに転送します。monitorパラメーターの下にcustomHeader引数を追加して、GSLBエンドポイント監視トラフィックに追加するカスタムヘッダーを指定します。
kubectl apply -f - <<EOF
apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 2
      - destination: 'app1.default.west.cluster2'
        weight: 5
      monitor:
      - monType: http
        uri: ''
        customHeader: "Host: <custom hostname>\r\n x-b3-traceid: afc38bae00096a96\r\n\r\n"
        respCode: 200
EOF

例2：フェイルオーバー展開

このポリシーを使用して、アプリケーションをアクティブ/パッシブモードで構成します。フェイルオーバー展開では、アプリケーションは複数のクラスターに展開されます。フェイルオーバーは、GTPポリシーでそれらのターゲット宛先に割り当てられた重みに基づいて、異なるクラスター内のアプリケーションインスタンス（ターゲット宛先）間で実現されます。
次の例は、フェイルオーバーのGTP構成例を示しています。プライマリフィールドを使用して、アクティブなターゲット宛先とパッシブなターゲット宛先を指定できます。プライマリフィールドのデフォルト値はTrueで、ターゲット宛先がアクティブであることを示します。各クラスターのエンドポイントにモニターをバインドして、そのヘルスをプローブします。
kubectl apply -f - <<EOF
apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'FAILOVER'
      secLbMethod: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 1
      - destination: 'app1.default.west.cluster2'
        primary: false
        weight: 1
      monitor:
      - monType: http
        uri: ''
        respCode: 200
EOF

例3：RTT展開

このポリシーを使用して、ネットワークのリアルタイムステータスを監視し、クライアント要求を最も低いRTT値を持つターゲット宛先に動的に転送します。
以下は、ラウンドトリップタイム展開のグローバルなトラフィックポリシーの例です。
kubectl apply -f - <<EOF
apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'RTT'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: tcp
EOF

例4：カナリア展開

アプリケーションの新しいバージョンを本番環境に移行する前に、選択したクラスターに展開する場合は、カナリア展開を使用します。
このセクションでは、カナリア展開を使用したグローバルなトラフィックポリシーの例について説明します。このポリシーでは、アプリケーションの新しいバージョンを本番環境に展開する前にロールアウトする必要があります。
この例では、アプリケーションはwestリージョンのクラスターcluster2に展開されています。アプリケーションの新しいバージョンは、eastリージョンの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: 'app1.com'
    policy:
      trafficPolicy: 'CANARY'
      secLbMethod: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 40
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: http
        uri: ''
        respCode: 200
EOF

例 5: 静的近接性

このポリシーを使用して、近接基準に最も一致するサービスを選択します。
以下のGTPは、静的近接性デプロイメントの例です。
注:
静的近接性の場合、すべてのGSLBデバイスにロケーションデータベースを手動で適用する必要があります: 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: 'app1.com'
    policy:
      trafficPolicy: 'STATICPROXIMITY'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.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: 'app1.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      sourceIpPersistenceId: 300
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 2
      - destination: 'app1.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200
EOF

グローバルサービスエントリ (GSE) の例

GSE構成は、クラスタエンドポイント情報に基づいて特定のクラスタに適用されます。GSE名は、グローバルなトラフィックポリシーのターゲット宛先名と同じである必要があります。
注:
GSEの作成はオプションです。GSEが作成されていない場合、NetScaler Ingress Controllerは、<svcname>.<namespace>.<region>.<cluster> 形式に一致するホストを持つ一致するイングレスを探します。
前のセクションで述べたグローバルなトラフィックポリシーの場合、cluster1のグローバルサービスエントリは次のとおりです。この例では、グローバルサービスエントリ名 app1.default.east.cluster1 は、作成されたグローバルなトラフィックポリシーのターゲット宛先名の1つです。
kubectl apply -f - <<EOF
apiVersion: "citrix.com/v1beta1"
kind: globalserviceentry
metadata:
  name: 'app1.default.east.cluster1'
  namespace: default
spec:
  endpoint:
    ipv4address: 10.102.217.70
    monitorPort: 33036
EOF

GSLBのマルチモニターサポート

GSLBセットアップでは、同じホストのサービスを監視するために複数のモニターを構成できます。モニターは、サービスのヘルスチェックに使用されるリクエストプロトコルに応じて、異なるタイプにすることができます。例えば、HTTP、HTTPS、TCPなどです。
複数のモニターを構成することに加えて、モニターに対して以下の追加パラメータを定義できます。
  • Destination port: モニターがヘルスチェックに使用するサービスポート。
  • SNI: このモニターのSNIステータス。指定可能な値はTrueとFalseです。
  • CN: SNIリクエストで使用される共通名 (CN)。共通名は通常、監視対象サーバーのドメイン名です。
要件に応じて、各モニターのパラメーターの組み合わせを定義することもできます。マルチモニターをサポートするGTPでは、各サービスを監視でき、いずれかのサービスがダウンした場合、サイトはダウンとマークされ、トラフィックは別のサイトに転送されます。次のGTP YAML例には、複数のモニターが含まれています。
kubectl apply -f - <<EOF
apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'STATICPROXIMITY'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: HTTPS
        uri: ''
        respCode: '200,300,400'
        destinationPort: 1000
      - monType: HTTP
        uri: ''
        respCode: '200,300,400'
        destinationPort: 3000
      - monType: HTTPS
        uri: ''
        respCode: '200,300,400'
        destinationPort: 4000
      - monType: TCP
        uri: ''
        destinationPort: 5000
        respCode: '200'
      - monType: HTTPS
        uri: 'test.com'
        sni: True
        respCode: '200,300,400'
        destinationPort: 6000
      - monType: HTTPS
        uri: 'test.com'
        sni: True
        commonName: 'testabc.com'
        respCode: '200,300,400'
        destinationPort: 7000
  status:
    {}
EOF