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

最終公開日 : Oct 02, 2026
NetScalerは、組織の境界を補完する強力で柔軟なトポロジーで組み合わせることができます。デュアルティアデプロイメントでは、第1層に大容量のハードウェアまたは仮想化されたNetScaler（NetScaler MPXおよびVPX）を採用し、セキュリティ機能をオフロードし、比較的静的な組織ポリシーを実装しながら、ネットワークオペレーターとKubernetesオペレーターの間で制御を分割します。
デュアルティアデプロイメントでは、第2層はKubernetesクラスター内（NetScaler CPXを使用）にあり、サービスオーナーの管理下にあります。この設定は、ネットワークオペレーターに安定性を提供しつつ、Kubernetesユーザーが高頻度の変更を実装できるようにします。シングルティアトポロジーは、高頻度の変更を処理する必要がある組織に適しています。

シングルティアトポロジー

シングルティアトポロジーでは、NetScaler MPXまたはVPXデバイスがクライアントからクラスター内のマイクロサービスへの（南北）トラフィックをプロキシします。NetScaler Ingress Controllerは、Kubernetesクラスター内にスタンドアロンポッドとしてデプロイされます。このコントローラーは、マイクロサービスまたはIngressリソースへの変更に基づいて、NetScaler（MPXまたはVPX）の設定を自動化します。
シングルティア(/en-us/netscaler-k8s-ingress-controller/media/singletopology.png)

デュアルティアトポロジー

デュアルティアトポロジーでは、Tier-1のNetScaler MPXまたはVPXデバイスが、クライアントからTier-2のNetScaler CPXへの（南北）トラフィックをプロキシします。その後、Tier-2のNetScaler CPXがKubernetesクラスター内のマイクロサービスにトラフィックをルーティングします。スタンドアロンポッドとしてデプロイされたNetScaler Ingress ControllerがTier-1デバイスを設定します。また、1つ以上のNetScaler CPXポッド内のサイドカーコントローラーが、同じポッド内の関連するNetScaler CPXを設定します。
デュアルティア(/en-us/netscaler-k8s-ingress-controller/media/dualtier.png)

クラウドトポロジー

Amazon Web Services (AWS)、 Google Cloud、 Microsoft AzureなどのパブリッククラウドのKubernetesクラスターは、 AWS Elastic Load Balancing、 Google Cloud Load Balancing、 Microsoft Azure NLBなどのネイティブロードバランシングサービスを、NetScaler CPXの第2層へのロードバランシングの最初の（比較的静的な）層として使用できます。NetScaler CPXは、サイドカーIngressコントローラーとともにKubernetesクラスター内で動作します。Kubernetesクラスターは、NetScaler CPXをIngressとして使用しながら、セルフホスト型またはクラウドプロバイダーによって管理されているもの（例えば、 AWS EKS、 Google GKE、 Azure AKS）のいずれかです。クラウドベースのKubernetesクラスターがセルフホスト型またはセルフマネージド型の場合、NetScaler VPXをデュアルティアトポロジーの最初の層として使用できます。
Tier-1にNetScaler (VPX) を使用したクラウドデプロイメント: Tier-1にVPXを使用したクラウドデプロイメント(/en-us/netscaler-k8s-ingress-controller/media/cloud-deploy-vpx-tier-1.png)
Tier-1にCloud LBを使用したクラウドデプロイメント: Tier-1にCLBを使用したクラウドデプロイメント(/en-us/netscaler-k8s-ingress-controller/media/cloud-deploy-clb-tier-1.png)

サービスメッシュライト

Ingressソリューションは通常、クライアントからKubernetesクラスター内のマイクロサービスへのトラフィック（南北トラフィック）に対してレイヤー7プロキシ機能を実行します。サービスメッシュライトアーキテクチャは、同じIngressソリューションを使用して、Kubernetesクラスター内のサービス間のトラフィック（東西トラフィック）も管理します。通常、サービスメッシュソリューションは東西トラフィックの管理に使用されますが、より重く、管理が複雑です。サービスメッシュライトソリューションは、サービスメッシュアーキテクチャの簡素化されたバージョンであり、南北および東西トラフィック管理の両方を管理する必要がある場合に理想的です。サービスメッシュでは、アプリケーションの数と同じ数のサイドカープロキシが存在します。しかし、サービスメッシュライトアーキテクチャでは、プロキシは複数の東西接続を管理するスタンドアロンプロキシとしてデプロイされます。したがって、サービスメッシュライトソリューションは、サービスメッシュと比較して軽量です。 なぜなら、必要なプロキシの数が少ないためです。
標準的なKubernetesデプロイメントでは、East-Westトラフィックは各ノードにデプロイされた組み込みのkube-proxyを通過します。Kube-proxyはL4プロキシであるため、L7プロキシの利点なしにTCP/UDPベースのロードバランシングしかできません。
NetScaler (MPX、VPX、またはCPX) は、East-Westトラフィックに対して次のような利点を提供できます。
  • 相互TLSまたはSSLオフロード
  • HTTPまたはHTTPSヘッダーパラメーターに基づくコンテンツベースのルーティング、トラフィックの許可またはブロック
  • 高度なロードバランシングアルゴリズム（例：最小接続数、最小応答時間など）
  • ゴールデンシグナル（エラー、遅延、飽和、トラフィック量）を測定することによるEast-Westトラフィックの可観測性。(/ja-jp/citrix-application-delivery-management-service.html) Service Graphは、マイクロサービスを監視およびデバッグするための可観測性ソリューションです。
詳細については、(/ja-jp/netscaler-k8s-ingress-controller/deploy/service-mesh-lite.html)を参照してください。
(/en-us/netscaler-k8s-ingress-controller/media/dual-tier-topology-with-hairpin-E-W.png)
サービスメッシュライトトポロジが推奨されるシナリオを以下に示します。
  • マイクロサービスに対してNorth-SouthおよびEast-Westの両方のトラフィック管理が必要な場合。
  • マイクロサービスへのサイドカープロキシとしてではなく、スタンドアロンプロキシとしてデプロイされたプロキシを介したEast-Westトラフィック管理が必要な場合。
  • Kubernetesクラスター内のプロキシがNorth-SouthおよびEast-Westの両方のトラフィック管理を実行する必要がある場合。
  • サービスメッシュの利点が必要だが、より軽量でシンプルなソリューションを望む場合。

LoadBalancerタイプのサービス

KubernetesのLoadBalancerタイプのサービスを使用すると、イングレスリソースを使用せずにサービスを外部に直接公開できます。これは、独自のネイティブクラウドロードバランサーを起動し、サービスがアクセスされる外部IPアドレスを割り当てるクラウドプロバイダーによってのみ提供されます。これにより、マイクロサービスを簡単にデプロイし、Kubernetesクラスターの外部に公開できます。
ベアメタルKubernetesクラスターでは、デフォルトで、LoadBalancerタイプのサービスは、サービスに対してNodePortsを公開するだけです。そして、外部ロードバランサーは構成しません。
NetScaler Ingress Controllerは、LoadBalancerタイプのサービスをサポートしています。LoadBalancerタイプのサービスを作成し、Tier-1のイングレスNetScalerを使用して公開できます。イングレスNetScalerはサービス用のロードバランサーをプロビジョニングし、外部IPアドレスがサービスに割り当てられます。NetScaler Ingress Controllerは、NetScaler IPAMコントローラーを使用してIPアドレスを割り当てます。
詳細については、LoadBalancerタイプのサービスを公開するを参照してください。
LoadBalancerタイプのサービス

NodePortタイプのサービス

デフォルトでは、KubernetesサービスはクラスターIPアドレスを使用してアクセスできます。クラスターIPアドレスは、Kubernetesクラスター内でアクセスできる内部IPアドレスです。Kubernetesクラスターの外部からサービスにアクセスできるようにするには、NodePortタイプのサービスを作成できます。
NetScaler Ingress Controllerは、NodePortタイプのサービスをサポートしています。イングレスNetScalerとNetScaler Ingress Controllerを使用すると、NodePortタイプのサービスを外部に公開できます。
詳細については、NodePortタイプのサービスを公開するを参照してください。
NodePortタイプのサービス

トポロジーを選択するためのガイドライン

以下の情報は、ニーズに基づいて、シングルティアとデュアルティアのトポロジーの中から適切なデプロイメントを選択するのに役立ちます。

シングルティア (統合イングレス)

シングルティア (統合イングレス) トポロジーが推奨されるシナリオと利点を以下に示します。
  • 既存のNetScaler®をKubernetesクラスターの前面にあるイングレスプロキシとして使用できるため、開始と導入が簡単です。
  • ネットワークチームがNetScalerとKubernetesデプロイメントの両方を管理する場合。
  • マイクロサービスとして実行されているワークロードが少なく、Kubernetesクラスター内のKubernetesプロキシは不要です。
  • ノースサウストラフィックのデプロイメントにより適しています。

デュアルティア

デュアルティアイングレストポロジが推奨されるシナリオと利点の一部を以下に示します。
  • マイクロサービスとして実行されているワークロードが大量にある場合、Kubernetesクラスター内にプロキシが必要になります。
  • 外部プロキシ（ネットワークチームが管理）とKubernetesプロキシ（プラットフォームチームが管理）が2つの異なるチームによって管理されている場合。
  • Kubernetes外部のプロキシとKubernetes内部のプロキシで機能の分離が必要です。例えば、外部NetScalerでのWAFとSSLオフロード、およびKubernetesプロキシでのポリシー適用とレート制限などです。
  • Kubernetesクラスター内のプロキシは、ノースサウストラフィック管理のみを実行します。

Helmチャートを使用したデプロイ

NetScalerクラウドネイティブトポロジをデプロイするには、YAMLとHelmチャートを使用したさまざまなオプションがあります。Helmチャートは、Kubernetes環境でのデプロイに最も簡単な方法の1つです。Helmチャートを使用してデプロイする場合、各パラメータを引数として提供する代わりに、設定可能なパラメータの値を指定するためにvalues.yamlファイルを使用できます。