マルチクラスターイングレス

最終公開日 : Oct 02, 2026
Related information
NetScaler ingress controller を展開する

はじめに

マルチクラスターKubernetesソリューションは、複数のクラスターにワークロードを分散するのに理想的です。NetScalerマルチクラスターイングレスソリューションは、単一のフロントエンドIPアドレスを使用して、クラスター全体に分散されたアプリケーションをNetScalerがロードバランシングできるようにします。ロードバランシングされたアプリケーションは、同じアプリケーション、同じドメインの異なるアプリケーション、またはまったく異なるアプリケーションのいずれかになります。
以前は、複数のクラスターでアプリケーションをロードバランシングするには、クラスターで実行されているNetScaler Ingress Controller (NSIC) の各インスタンスに対して、NetScaler上に専用のコンテンツスイッチング仮想サーバーが必要でした。NetScalerマルチクラスターイングレスソリューションを使用すると、複数のイングレスコントローラーがコンテンツスイッチング仮想サーバーを共有できます。したがって、クラスター全体にデプロイされたアプリケーションは、同じコンテンツスイッチング仮想サーバーIP (VIP) アドレスを使用してロードバランシングできます。
要約すると、マルチクラスターイングレスソリューションは、ロードバランシングリソースの使用を最適化し、それによって運用コストを削減します。
注:
マルチクラスターイングレスソリューションは、NSICバージョン2.0.6以降でサポートされています。

デプロイメントトポロジー

次の図は、データセンター/サイトにおける2つのKubernetesクラスターのマルチクラスターイングレスデプロイメントトポロジーを示しています。ここでは、NetScalerが単一のフロントエンドIPアドレスを使用して、クラスター全体に分散されたアプリケーションをロードバランシングします。
マルチクラスターイングレス
  • 両方のクラスターにNSICがデプロイされます。両方のNSICインスタンスは同じNetScalerを構成します。
  • クラスターにデプロイされるアプリケーションの性質に応じて、通常、次のユースケースがあります。
    • 各Kubernetesクラスターにデプロイされた同じドメイン (company.website.com) の異なるアプリケーション: cluster1のApp-Bとcluster2のApp-C。
      ここでは、NetScaler上のコンテンツスイッチング仮想サーバーがApp-BとApp-C間でトラフィックをロードバランシングします。各アプリケーションに対して個別のコンテンツスイッチングポリシーが構成されます。
    • 両方のKubernetesクラスターにデプロイされた同じアプリケーション。
      ここでは、NetScaler上のコンテンツスイッチング仮想サーバーが、両方のクラスターにデプロイされた同じアプリケーション App-A のトラフィックをロードバランスします。App-A 用に作成されるコンテンツスイッチングポリシーは1つだけで、これはアプリケーションの実行中のインスタンス（エンドポイント）の両方で使用されます。
以下の図で、同じフロントエンドIPアドレスがcluster1とcluster2にデプロイされたアプリケーション App-B と App-c へのトラフィックをロードバランスするためにどのように使用されるかを理解しましょう。
マルチクラスター設定でのロードバランシング
次のリソースを構成すると、マルチクラスターイングレスソリューションが有効になります: リスナー と イングレス。

リスナー

  • クラスターにデプロイされたリスナーリソースは、リスナーYAMLで指定されたVIPを使用してNetScaler上にコンテンツスイッチング仮想サーバーを作成します。マルチクラスターイングレス設定では、同じリスナーリソースがすべてのクラスターにデプロイされます。
    マルチクラスターイングレスソリューションのリスナーリソースは、フロントエンドのトラフィック管理を処理します。コンテンツスイッチング仮想サーバーに必要なすべてのシークレット、暗号、およびフロントエンドプロファイル構成を提供する必要があります。リスナーCRDの詳細については、リスナー を参照してください。マルチクラスターイングレス設定用のリスナーリソースのデプロイに関する詳細は、マルチクラスターイングレスソリューションをデプロイする手順 セクションで入手できます。

イングレス

  • マルチクラスター設定でアプリケーションにトラフィックをルーティングするために各クラスターにデプロイされたイングレスリソースは、共有VIPアドレスを持つ同じリスナーリソースを参照します。したがって、NSICは既存の同じコンテンツ仮想サーバーを参照し、NetScaler上にコンテンツスイッチングポリシーのみを作成し、これらは後でコンテンツスイッチング仮想サーバーにバインドされます。
この場合、各アプリケーションのコンテンツスイッチングポリシー、つまりCSPOL-App-BとCSPOL-App-Cは、同じコンテンツスイッチング仮想サーバーにバインドされます。例えば、company.website/App-B のリクエストがコンテンツスイッチング仮想サーバーのIP（VIP）アドレスに送信されると、コンテンツスイッチング仮想サーバーはCSPOL-App-Bポリシーを適用し、リクエストを LBvserver-App-B にルーティングし、それがApp-Bサービスに送信します。

マルチクラスターイングレスのデプロイ

この手順では、同じHTTPSアプリケーションを2つのクラスターにデプロイし、両方のクラスターに必要なリスナーリソースとイングレスリソースをデプロイします。これにより、NetScaler VPXまたはNetScaler MPXが単一のフロントエンドIPアドレスを使用してこれらのアプリケーションをロードバランスします。

前提条件

  • クラウドまたはオンプレミスでホストされているKubernetesクラスターへのアクセス。クラウド内のKubernetesクラスターは、マネージドKubernetes（例：GKE、EKS、AKS）またはカスタム作成されたKubernetesデプロイメントのいずれかです。KubernetesまたはOpenShiftは適切に構成され、運用可能である必要があります。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アドレス。詳細については、IP Addressing in NetScalerを参照してください。
    • SNIP (高可用性モードのアプライアンスの場合) - サブネットIPアドレス。詳細については、IP Addressing in NetScalerを参照してください。
    • CLIP (クラスターモードのアプライアンスの場合) - クラスターNetScalerデプロイメントのクラスター管理IP (CLIP) アドレス。詳細については、IP addressing for a clusterを参照してください。
  • NetScaler VPXまたはNetScaler MPXのユーザーアカウント。NetScaler Ingress Controllerは、NetScaler MPXまたはNetScaler VPXを構成するために、NetScalerのシステムユーザーアカウントを使用します。NetScalerでシステムユーザーアカウントを作成する手順については、Create System User Account for NetScaler Ingress Controller in NetScalerを参照してください。
    ユーザー名とパスワードを直接渡すか、Kubernetesシークレットを使用できます。Kubernetesシークレットを使用する場合は、次のコマンドを使用してユーザー名とパスワードのシークレットを作成します。
    kubectl create secret generic nslogin --from-literal=username=<username> --from-literal=password=<password>

マルチクラスターイングレスソリューションをデプロイする手順

NetScalerと共有フロントエンドIPアドレスを使用して、2つのKubernetesクラスターにデプロイされたCloud Native Networking (CNN) アプリケーションを公開するマルチクラスターイングレスソリューションをデプロイするには、次の手順に従います。
注記:
マルチクラスターイングレスソリューションをセットアップするには、両方のクラスターで次の手順を繰り返します。特定のクラスターで何を行う必要があるかを強調する例外がいくつかの手順で追加されています。それに応じて手順を実行してください。
  1. 以下のYAMLを使用してNetScaler CNNアプリケーションをデプロイします。
    CNNアプリケーションは、NetScaler®クラウドネイティブポートフォリオで提供されるソリューションを一覧表示するHTTPベースのアプリケーションです。
    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デプロイメントの場合、サービスアカウントに特定のSecurity Context Constraint (SCC) を付与するには、次のコマンド oc adm policy add-scc-to-user anyuid system:serviceaccount:<namespace>:default を実行します。<namespace> を、CNNアプリケーションをデプロイした実際の名前空間に置き換えてください。
  2. 次のコマンドを使用して、NetScaler Helmチャートリポジトリをローカルレジストリに追加します。
    helm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/
    NetScaler Helmチャートリポジトリがすでにローカルレジストリに追加されている場合は、次のコマンドを使用してリポジトリを更新します。
    helm repo update netscaler
  3. NetScaler Ingress Controllerを次のように構成するには、values.yaml を更新します。
    cluster1の例 values.yaml
    license:
      accept: yes
    adcCredentialSecret: nslogin # K8s Secret Name
    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
    multiClusterPrefix: mc # Multi-cluster prefix for the NSIC instance. Same value must be specified for a set of NSIC instances configuring NetScaler in multi-cluster setup.
    # serviceClass- To use service type LB, specify the service class
    cluster2の例 values.yaml
    license:
      accept: yes
    adcCredentialSecret: nslogin # K8s Secret Name
    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
    multiClusterPrefix: mc # Multi-cluster prefix for the NSIC instance. Same value must be specified for a set of NSIC instances configuring NetScaler in multi-cluster setup.
    # serviceClass- To use service type LB, specify the service class
    注:
    OpenShiftデプロイメントの場合、values.yaml で openshift パラメータを true に設定します。
    NSICのインストール中に構成できる必須およびオプションのパラメータについては、構成 を参照してください。
  4. 変更された values.yaml を使用してNetScaler Ingress Controllerをデプロイします。
    helm install nsic netscaler/netscaler-ingress-controller -f values.yaml
    注:
    以前のバージョンのNSICがすでにクラスターにデプロイされている場合は、次のコマンドを使用してリスナーCRD仕様をデプロイします: kubectl apply -f https://raw.githubusercontent.com/netscaler/netscaler-k8s-ingress-controller/master/crd/contentrouting/Listener.yaml。
  5. 以下のリスナーCRDリソースをデプロイします。
    kubectl apply -f - <<EOF
    apiVersion: citrix.com/v1
    kind: Listener
    metadata:
      name: mc-listener
    spec:
      multicluster: True
      ingressclass: nsic-vpx
      protocol: 'https'
      vip: <Provide the shared front-end IP address>
      certificates:  
      #  you need to specify either secret name or pre-configured cert-keyname
        - secret:
            name: <Provide k8s secret name>  # provide k8s secret containing cert-key of the application
          default: true
        - preconfigured: <ADC-certkeyname> # provide pre-configured cert-key from ADC.
    EOF
    • vipを、両方のクラスターにデプロイされたアプリケーションを公開するために使用される仮想IPアドレスで更新します。
    • multiclusterはTrueとして設定する必要があります。
    • NetScalerで作成されたSSL証明書キー名で事前設定されたシークレットを更新するか、secret.nameセクションでKubernetes TLSシークレットの名前を更新します。Listener.certificatesを参照してください。
    この例では、リスナーリソースmc-listenerはVIPやシークレットなどのフロントエンド構成を指定します。NetScalerにHTTPSトラフィック用のポート443でコンテンツスイッチング仮想サーバーを作成します。
  6. CNNアプリケーションを公開するために、以下のイングレスリソースをデプロイします。
    kubectl apply -f - <<EOF
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend-ingress
      annotations:
        ingress.citrix.com/listener: mc-listener
    spec:
      ingressClassName: nsic-vpx
      rules:
        - http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: cnn-website
                    port:
                      number: 80
    ---
    apiVersion: networking.k8s.io/v1
    kind: IngressClass
    metadata:
      name: nsic-vpx
    spec:
      controller: citrix.com/ingress-controller
    EOF
    • 前のステップで作成されたリスナーリソースは、ingress.citrix.com/listenerアノテーションを使用して渡す必要があります。 この例では、イングレスリソースfrontend-ingressはリスナーリソースmc-listener（ステップ5で作成）を参照しています。
    • イングレスクラスはnsic-vpxとして言及されています。
    Ingressは、コンテンツスイッチングポリシー、ロードバランシング仮想サーバー、サービスグループを作成し、アプリケーションポッドのIPアドレスをサービスグループメンバーとしてバインドします。
    注記：
    • マルチクラスターイングレス設定で異なるアプリケーションをロードバランシングする場合、各アプリケーションに対して個別のコンテンツスイッチングポリシーが作成されます。このような場合、ポリシーバインディングに特定の順序が必要な場合は、ingress.citrix.com/multicluster-policy-priority-orderアノテーションを使用してコンテンツスイッチングポリシーに優先度番号を割り当てる必要があります。詳細については、ポリシーバインディングを参照してください。
    • マルチクラスターイングレス設定で異なるアプリケーションをロードバランシングする場合のリスナーおよびイングレスリソースに関する情報については、異なるアプリケーションを使用したマルチクラスターイングレス設定を参照してください。
  7. 構成を検証するには、<VIP>をステップ5のリスナーリソースで提供されている仮想IPアドレスに置き換えます。
    curl -kv https://<VIP>

高度なユースケース

同じアプリケーションが複数のクラスターにデプロイされている場合、トラフィック分散要件が異なる多様なデプロイシナリオが発生します。Active-Activeとして知られるデフォルトの動作では、ロードバランシング方法に基づいて、アプリケーションのすべてのインスタンスがトラフィックを受信します。ここでは、同じアプリケーションが2つのクラスターにデプロイされている場合の高度なユースケースを見てみましょう。

アクティブ-バックアップモード

このモードでは、1つのアプリケーションが常にアクティブであり、常にトラフィックを受信します。他のアプリケーションは、このクラスターまたはアプリケーションがダウンしている場合にのみトラフィックを受信します。ingress.citrix.com/multicluster-backup-order イングレスアノテーションを使用して、どのアプリケーションをバックアップとして機能させるかを定義できます。
注:
同じリスナーリソースを両方のクラスターにデプロイする必要があります。リスナーリソースの例については、マルチクラスターイングレスソリューションをデプロイする手順 セクションのステップ5を参照してください。
クラスター1 (アクティブ) クラスター2 (バックアップ)
イングレスアノテーション ingress.citrix.com/multicluster-backup-order: "1" ingress.citrix.com/multicluster-backup-order: "2"
情報 デフォルトはアクティブ (1) です。アノテーションはスキップできます。 アプリケーションをバックアップと見なすには、アノテーションが必須です。
  • クラスター1にデプロイされたアプリケーションはアクティブにトラフィックを受信し、クラスター2はバックアップとして機能します。クラスター2のアプリケーションは、クラスター1またはクラスター1のアプリケーションがダウンしている場合にのみトラフィックを受信します。

カナリアモード

注:
以下のデプロイメントでは、各クラスターに同じリスナーリソースをデプロイする必要があります。リスナーリソースの例については、「マルチクラスターIngressソリューションをデプロイする手順」セクションのステップ5を参照してください。
カナリアデプロイメントは、「重みによるカナリア」と「ヘッダーによるカナリア」という2つの異なる戦略をサポートしています。
重みによるカナリアデプロイメント
アプリケーションのインスタンスに異なる重みを割り当てることで、カナリアデプロイメントを実装できます。たとえば、2つのクラスターがあり、アプリケーションの新しいバージョンがロールアウトされている場合、トラフィックの特定の割合を新しいバージョン（カナリア）に割り当て、残りのトラフィックを既存のバージョンに割り当てることができます。このカナリアモードにより、新しいバージョンのパフォーマンスを制御された方法で段階的にロールアウトし、監視することができます。
クラスター1 (バージョン1) クラスター2 (バージョン2)
Ingressアノテーション NA ingress.citrix.com/multicluster-canary-weight: "10"
情報 アノテーションは不要です アノテーションは必須です。このアプリケーションはクライアントトラフィックの10%を受け取ります。
ヘッダーによるカナリアデプロイメント
特定のHTTPヘッダーに基づいてカナリアデプロイメントを実装できます。たとえば、「X-Canary-Version」のようなHTTPリクエスト内の特定のヘッダーを使用して、トラフィックのルーティングを制御できます。この場合、「X-Canary-Version」ヘッダーを持つリクエストはアプリのカナリアバージョンに転送され、それ以外のリクエストは安定版にルーティングされます。このカナリアモードは、カナリアデプロイメントをよりきめ細かく制御し、テスト目的で特定のユーザーまたはリクエストのサブセットをターゲットにすることを可能にします。
クラスター1 (バージョン1) クラスター2 (バージョン2)
アノテーション NA ingress.citrix.com/multicluster-canary-by-header: "version2"
情報 アノテーションは不要です アノテーションはカナリアアプリケーションに必須です。version2 ヘッダーを持つすべてのクライアントトラフィックはクラスター2に送信されます。

ポリシーバインディング

ポリシーバインディングに特定のシーケンスが必要な場合は、ingress.citrix.com/multicluster-policy-priority-order アノテーションを使用してコンテンツスイッチングポリシーに優先度番号を割り当てる必要があります。数値が小さいほど、優先度が高くなります。
ポリシーバインディングを理解するために、次のイングレスリソースの例を考えてみましょう。
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mc-ing
  annotations:
    ingress.citrix.com/listener: mc-listener
    ingress.citrix.com/multicluster-policy-priority-order: '{"frontend": {"80": "3", "9443": "1"}, "backend": "2"}'
spec:
  ingressClassName: nsic-vpx
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 80
          - path: /abc
            pathType: Prefix
            backend:
              service:
                name: frontend
                port:
                  number: 9443
          - path: /xyz
            pathType: Prefix
            backend:
              service:
                name: backend
                port:
                  number: 80
EOF
このリソースの例には、コンテンツスイッチングポリシーの優先順位を定義する ingress.citrix.com/multicluster-policy-priority-order アノテーションが含まれています。NetScaler Ingress Controller は、優先度をランダムに割り当てるのではなく、提供された優先度値を使用してコンテンツスイッチングポリシーをコンテンツスイッチング仮想サーバーにバインドします。
ingress.citrix.com/multicluster-policy-priority-order: '{"Front end": {"80": "3", "9443": "1"}, "back-end": "2"}' アノテーションの場合、優先度は次のように割り当てられます。
  • frontend:80 サービスに関連付けられたコンテンツスイッチングポリシーは、優先度3でコンテンツスイッチング仮想サーバーにバインドされます。
  • frontend:9443 サービスに関連付けられたコンテンツスイッチングポリシーは、優先度1でコンテンツスイッチング仮想サーバーにバインドされます。
  • backend:80 サービスに関連付けられたコンテンツスイッチングポリシーは、優先度2でコンテンツスイッチング仮想サーバーにバインドされます。
警告:
イングレスリソースで単一のサービスが異なるポートで言及されている場合、各ポートに優先度番号を明示的に指定する必要があります。そうしないと、ランダムな優先度が割り当てられます。

異なるアプリケーションを使用したマルチクラスターイングレスのセットアップ

異なるアプリケーションの負荷分散のためのマルチクラスターイングレス設定では、各クラスターにデプロイされるリスナーリソースは同じである必要があります。各クラスターのイングレスリソースは同じリスナーを参照する必要があります。デプロイメントトポロジセクションで説明されている例では、mc-listenerはcluster1とcluster2の両方にデプロイされたリスナーリソースです。cluster1とcluster2にデプロイされた以下のサンプルイングレスリソースはmc-listenerを参照します。
cluster1でApp-Bを公開するためのイングレスリソース:
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-b
annotations:
  ingress.citrix.com/listener: mc-listener
spec:
ingressClassName: cluster1
rules:
- http:
    paths:
    - path: /App-B
      pathType: Prefix
      backend:
        service:
          name: app-b-svc
          port:
            number: 80
EOF
cluster2でApp-Cを公開するためのイングレスリソース:
kubectl apply -f - <<EOF  
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-c
annotations:
  ingress.citrix.com/listener: mc-listener
spec:
ingressClassName: cluster2
rules:
- http:
    paths:
    - path: /App-C
      pathType: Prefix
      backend:
        service:
          name: app-c-svc
          port:
            number: 80
EOF