VMware クラウドファンデーション上の vSphere Kubernetes サービスにおけるネットスケーラー

最終公開日 : Oct 02, 2026
NetScaler は、NetScaler Ingress Controller および NetScaler Kubernetes Gateway Controller を介して、VMware Cloud Foundation (VCF) 上の VMware vSphere Kubernetes Service (VKS) と統合します。両方のコントローラーは Kubernetes リソースを監視し、NetScaler 上での手動設定なしに、南北アプリケーション トラフィックを処理するように NetScaler VPX を自動的にプログラムします。
プラットフォームチームは、ロードバランシング、TLSオフロード、WAF、レート制限、および書き換えポリシーをすべてKubernetesマニフェストを通じて管理できます。このドキュメントでは、共同ソリューションの検証済み展開アーキテクチャについて説明します。
Related information
プラットフォーム統合

vSphere Kubernetes Service の概要

vSphere Kubernetes Service (VKS) は、VMware Cloud Foundation (VCF) に組み込まれている Kubernetes ランタイムです。これは、プラットフォームエンジニアがVCFクラウドサービスの全セットと並行して展開および管理できる、CNCF認定のKubernetesディストリビューションを提供します。クラウド管理者は、N-2 Kubernetes バージョンサポート、自動アップグレード、およびコンピューティング、ストレージ、ネットワークにわたる単一のライフサイクル管理プレーンを利用できます。
VMware Cloud Foundation 上の vSphere Kubernetes Service の展開トポロジ
TCO の削減。 VKS は、既存の vSphere ツール、スキル、および運用プロセスを再利用することで、インフラストラクチャのサイロを削減します。統合されたライフサイクル管理により、最小限の手動作業でクラスターを最新の状態に保ちます。
運用の簡素化。 自動化されたクラスタープロビジョニング、アップグレード、およびライフサイクル管理により、運用後のオーバーヘッドが削減され、チームはインフラストラクチャの維持ではなくアプリケーションに集中できます。
大規模な Kubernetes。 VKS は、自己管理型 Kubernetes の運用上の負担なしに、初期プロビジョニングから継続的なアップグレードまで、本番環境で複数のクラスターを実行する完全なライフサイクルを処理します。

Kubernetes 向け NetScaler

NetScaler は、VKS ワークロードのイングレスプロキシとして機能し、SSLオフロード、ロードバランシング、およびL7ポリシー適用により南北アプリケーション トラフィックを処理します。NetScaler は Kubernetes Ingress API と Kubernetes Gateway API の両方をサポートしているため、チームは環境に合ったモデルを選択できます。
マイクロサービスアプリ配信のためのNetScaler
コントローラー API 使用条件
NetScaler Kubernetes Gatewayコントローラー Kubernetes ゲートウェイ API 新規デプロイ。プラットフォームチームがGatewayリソースを管理し、アプリケーションチームがHTTPRouteルールを管理します
NetScaler Ingressコントローラー Kubernetes イングレス API 既存のIngressベースのワークロード。HTTPおよびTCP/SSLトラフィック
NetScalerは両方のコントローラーを提供しており、必要なのはどちらか一方だけです。既にKubernetes Ingressリソースを実行している場合、NetScaler Ingress Controller は既存のマニフェストを変更せずに動作します。新規に開始する場合は、NetScaler Kubernetes Gateway Controller が推奨される選択肢です。これはKubernetesプロジェクトによって定義された標準であるKubernetes Gateway APIを実装しており、標準のGatewayおよびHTTPRouteリソースを通じて、プラットフォームチームとアプリケーションチームに明確な責任分担を提供します。
両方のコントローラーは、外部ロードバランサーとしてNetScaler VPX を使用します。アプリケーションポッドには、VKSワーカーノード上のNodePortを使用して到達します。NetScalerとKubernetesクラスターノードがL2ネットワークを共有している場合、NetScaler Ingress Controllerで nodeWatch=true を設定すると、各ノードのポッドCIDRへの静的ルートが自動的にプログラムされます。L3で分離されている場合は、NetScaler Node Controller を使用してください。これはVXLANオーバーレイを構築し、ポッドIPに到達可能にします。
ロードバランシング、TLSオフロード、WAF、レスポンダーおよび書き換えポリシー、レート制限、可観測性など、すべてがKubernetesマニフェストを通じて構成されます。

ソリューションアーキテクチャ

NetScaler VPXは、VCF上の仮想マシンとしてVKSクラスターの外部に配置されます。これは、すべての南北トラフィック（SSL終端、ルーティング、アプリケーションポッドへのロードバランシング）を処理します。これは、検証済みの両方のVKSネットワークトポロジーで機能します。
NetScaler Ingress ControllerとNetScaler Kubernetes Gateway ControllerはVKSクラスター内で実行され、トラフィックパスにはありません。これらはKubernetesリソースを監視し、目的のNetScaler構成を計算し、NITRO REST APIを通じて変更をプッシュします。開発者が新しいIngressまたはGateway APIリソースを適用すると、手動介入なしでNetScalerが数秒以内に更新されます。
検証済みのVKSネットワークトポロジー:

ソリューションの検証

ソフトウェアバージョン：
コンポーネント バージョン
ヴイエムウェア クラウド ファンデーション 9.0
ヴイスフィア クバネティス サービス (VKS) 3.6
ヴイスフィア クバネティス リリース (VKr) 1.35
NetScaler VPX 14.1
ネットスケーラー クバネティス ゲートウェイ コントローラー 2.1.0
ネットスケーラー イングレス コントローラー 4.1.17
検証済み構成:
構成 結果
ゲートウェイコントローラー / ゲートウェイAPI VPC / NSX — NodePort 検証済み
ゲートウェイコントローラー / ゲートウェイAPI Foundation LB / vDS — NodePort 検証済み
イングレスコントローラー / HTTP VPC / NSX — NodePort 検証済み
イングレスコントローラー / HTTP Foundation LB / vDS — NodePort 検証済み
イングレスコントローラー / TCP/SSL VPC / NSX — NodePort 検証済み
イングレスコントローラー / TCP/SSL Foundation LB / vDS — NodePort 検証済み
Ingress リソースまたは Gateway/HTTPRoute の定義は、どちらのネットワークトポロジでも同じです。

VKS に NetScaler をデプロイする

前提条件

VKS クラスター

  • VCF 9.0 以降の VKS ワークロードクラスター (どちらのネットワークトポロジでも可)
  • cluster-admin 権限を持つ kubectl アクセス
  • ワークステーション上の HELM 3。

NetScaler VPX

  • VPX は、ノードと同じサブネットに SNIP が構成されている VKS ワーカーノードから到達可能である必要があります
  • イングレスフロントエンド用に少なくとも1つの空き VIP
  • NetScaler アカウントには書き込みアクセス権が必要です。コントローラーは NITRO API を介して仮想サーバーとサービスグループを作成および更新するため、読み取り専用アカウントでは機能しません。

ネットワーク

  • VKS ノードはポート 443 で NetScaler NSIP に到達できる必要があります。NetScaler SNIP は NodePort 範囲 (30000～32767) で VKS ノードに到達できる必要があります。
注:
このガイドでは、両方のデプロイオプションについて説明します。パートIではGateway Controller (Gateway API)について、パートIIではIngress Controller (Ingress API)について説明します。本番環境では、どちらか一方のみが必要です。決定する前に両方を評価したい場合は、同じクラスターで両方のパートを実行できます。

パートI: ゲートウェイAPI — ネットスケーラー Kubernetes ゲートウェイコントローラー

Gateway ControllerはKubernetes Gateway APIを実装します。プラットフォームチームはGatewayリソースとセキュリティポリシーを管理します。アプリケーションチームはHTTPRouteルールを管理します。すべての設定はKubernetesマニフェストにあります。誰もNetScalerにログインしません。

ステップ1：GatewayClassを作成する

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: gateway-class
spec:
  controllerName: citrix.com/nsgw-controllerkubectl apply -f gatewayclass.yaml

ステップ2：サンプルアプリケーションをデプロイする

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  labels:
    name: webapp
    app: webapp
spec:
  selector:
    matchLabels:
      app: webapp
  replicas: 2
  template:
    metadata:
      labels:
        name: webapp
        app: webapp
    spec:
      containers:
      - name: webapp
        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: webapp
  labels:
    app: webapp
spec:
  type: NodePort
  ports:
  - name: http-80
    port: 80
    targetPort: 80
  - name: https-443
    port: 443
    targetPort: 443
    appProtocol: ssl
  selector:
    name: webappkubectl apply -f webapp.yaml

ステップ3：TLS Secretを作成する

openssl genrsa -out webapp_key.pem 2048
openssl req -new -key webapp_key.pem -out webapp_csr.pem \
  -subj "/CN=webapp.demonetscaler.com"
openssl x509 -req -in webapp_csr.pem -sha256 -days 365 \
  -extensions v3_ca -signkey webapp_key.pem \
  -CAcreateserial -out webapp_cert.pem
kubectl create secret tls webapp-secret \
  --key webapp_key.pem --cert webapp_cert.pem
本番環境では、自己署名証明書をCAからのものに置き換えてください。残りの手順は同じです。

ステップ4：NetScaler Credential Secretを作成する

kubectl create secret generic nslogin \
  --from-literal=username=<username> \
  --from-literal=password=<password>
専用のシステムユーザーアカウントの作成方法については、NetScaler Ingress Controllerのシステムユーザーアカウントを作成するを参照してください。

ステップ5：Gateway Controllerをデプロイする

values.yaml:
netscaler:
 adcCredentialSecret: "nslogin"
 nsIP: "<NSIP/SNIP/CLIP>" #NSIP for standalone VPX, SNIP with management access enabled for HA VPX or CLIP for VPX cluster mode

gatewayController:
 entityPrefix: gwy
 gatewayControllerName: "citrix.com/nsgw-controller"

license:
 accept: yes

nodeWatch: truehelm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/
helm install gateway-controller \
  netscaler/netscaler-kubernetes-gateway-controller \
  -f values.yaml
kubectl get pods -l app=gateway-controller

ステップ6：GatewayとHTTPRouteをデプロイする

NetScalerの空いている仮想IPを<VIP_ADDRESS>に置き換えてください。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: vpx-gateway
spec:
  gatewayClassName: gateway-class
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: webapp-secret
  addresses:
  - type: IPAddress
    value: <VIP_ADDRESS>
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-route
spec:
  parentRefs:
  - name: vpx-gateway
  hostnames:
  - "webapp.demonetscaler.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: webapp
      namespace: default
      port: 443kubectl apply -f gateway.yaml
kubectl get gateway vpx-gateway
kubectl get httproute http-route

ステップ7：テスト

curl -vik --resolve webapp.demonetscaler.com:443:<VIP_ADDRESS> \
  https://webapp.demonetscaler.com
期待される結果：NetScaler VIPからHTTPS経由で提供されるHTTP/2 200。

セキュリティユースケース: 不正なURLパスをブロックする

rewritepolicy CRDを使用してNetScaler Responderポリシーを適用し、ExtensionRefフィルターを使用してHTTPRouteにアタッチします。アプリケーションの変更は不要です。
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: blacklisturls
spec:
  responder-policies:
  - responder-policy:
      respondwith:
        http-payload-string: >
          "HTTP/1.1 403 Forbidden\r\n\r\n" +
          "Client: " + CLIENT.IP.SRC +
          " is not authorized to access URL:" +
          HTTP.REQ.URL.HTTP_URL_SAFE + "\n"
      respond-criteria: 'http.req.url.equals_any("blacklistUrls")'
      comment: 'Blacklist certain URLs'
    patset:
    - name: blacklistUrls
      values:
      - '/.hidden'
      - '/.password'
ポリシーを参照するようにHTTPRouteを更新します:
filters:
- type: ExtensionRef
  extensionRef:
    group: citrix.com
    kind: rewritepolicy
    name: blacklisturls
ブロックされたパスが403 Forbiddenを返すことをテストします:
curl -vik --resolve webapp.demonetscaler.com:443:<VIP_ADDRESS> \
  https://webapp.demonetscaler.com/.hidden

第II部: イングレスAPI — NetScalerイングレスコントローラー

このセクションでは、同じクラスター上の2つのサービスタイプについて説明します。HTTPアプリケーション (Apache) とTCP/SSLアプリケーション (tcp-echo) の両方が、標準のKubernetes Ingressリソースを使用してNetScaler VPXを介して公開されます。

ステップ1: アプリケーションのデプロイ

アパッチ HTTP:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: apache
  labels:
    name: apache
spec:
  selector:
    matchLabels:
      app: apache
  replicas: 2
  template:
    metadata:
      labels:
        app: apache
    spec:
      containers:
      - name: apache
        image: httpd:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: apache
spec:
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: apache
TCPエコー (TCP/SSL):
apiVersion: v1
kind: Service
metadata:
  name: tcp-echo
  labels:
    app: tcp-echo
spec:
  type: NodePort
  ports:
  - name: tcp
    port: 9000
  - name: tcp-other
    port: 9001
  selector:
    app: tcp-echo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tcp-echo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tcp-echo
      version: v1
  template:
    metadata:
      labels:
        app: tcp-echo
        version: v1
    spec:
      containers:
      - name: tcp-echo
        image: docker.io/istio/tcp-echo-server:1.3
        args: ["9000,9001,9002", "hello"]
        ports:
        - containerPort: 9000
        - containerPort: 9001kubectl apply -f apache.yaml
kubectl apply -f tcp-echo.yaml

ステップ2: TLSシークレットの作成

# TCP-echo cert
openssl genrsa -out tcp_key.pem 2048
openssl req -new -key tcp_key.pem -out tcp_csr.pem -subj "/CN=*.tcp-echo.com"
openssl x509 -req -in tcp_csr.pem -sha256 -days 365 \
  -extensions v3_ca -signkey tcp_key.pem -CAcreateserial -out tcp_cert.pem
kubectl create secret tls tcp-ssl-cert --key tcp_key.pem --cert tcp_cert.pem

# Apache cert
openssl genrsa -out apache_key.pem 2048
openssl req -new -key apache_key.pem -out apache_csr.pem -subj "/CN=*.demonetscaler.com"
openssl x509 -req -in apache_csr.pem -sha256 -days 365 \
  -extensions v3_ca -signkey apache_key.pem -CAcreateserial -out apache_cert.pem
kubectl create secret tls apache-secret --key apache_key.pem --cert apache_cert.pem

ステップ3: NetScalerクレデンシャルシークレットの作成

パートIでnsloginをすでに作成している場合は、このステップをスキップしてください。
kubectl create secret generic nslogin \
 --from-literal=username=<username> \
 --from-literal=password=<password>

ステップ4: Ingress Controllerのデプロイ

values.yaml:
adcCredentialSecret: nslogin
entityPrefix: unified
ingressClass: ['vpx']
serviceClass: ['vpx']
license:
 accept: yes
nsIP: <NSIP/SNIP/CLIP> #NSIP for standalone VPX, SNIP with management access enabled for HA VPX or CLIP for VPX cluster mode
nodeWatch: truehelm install nsic netscaler/netscaler-ingress-controller \
 -f values.yaml
kubectl get pods
参照先は次のとおりです: netscaler-helm-charts / netscaler-ingress-controller

ステップ5: Ingressリソースの作成

TCP/SSL Ingress — <VIP_ADDRESS>を置き換える:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vpx-tcp-ssl
  annotations:
    ingress.citrix.com/secure-service-type: ssl_tcp
    ingress.citrix.com/frontend-ip: "<VIP_ADDRESS>"
    ingress.citrix.com/secure-port: "6379"
spec:
  tls:
  - secretName: tcp-ssl-cert
  ingressClassName: vpx
  defaultBackend:
    service:
      name: tcp-echo
      port:
        number: 9000
Apache用HTTPS Ingress — <VIP_ADDRESS>を置き換える:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: vpx-ingress-apache
  annotations:
    ingress.citrix.com/frontend-ip: <VIP_ADDRESS>
    ingress.citrix.com/secure-port: '8443'
spec:
  tls:
  - secretName: "apache-secret"
  ingressClassName: vpx
  rules:
  - host: apache.demonetscaler.com
    http:
      paths:
      - backend:
          service:
            name: apache
            port:
              number: 80
        path: /
        pathType: Prefixkubectl apply -f vpx-tcp-ssl-ingress.yaml
kubectl apply -f vpx-apache-ingress.yaml
kubectl get ingress

ステップ6: テスト

# TCP/SSL
openssl s_client -connect <VIP_ADDRESS>:6379 \
  -cert tcp_cert.pem -key tcp_key.pem

# Apache HTTPS
curl -vik --resolve apache.demonetscaler.com:8443:<VIP_ADDRESS> \
  https://apache.demonetscaler.com:8443
期待される結果: ApacheからのHTTP/2 200、TLSハンドシェイクの成功、およびtcp-echoからのエコー応答。

トラブルシューティング

コントローラーログから始めます。ほとんどの障害はそこで説明されています。
# Gateway Controller
kubectl logs -l app=gateway-controller --tail=100

# Ingress Controller
kubectl logs -l app=nsic --tail=100
症状 最も可能性の高い原因 確認事項
コントローラーポッドのCrashLoopBackOff 不正な認証情報またはNSIPに到達不能 ログ; クラスター内からtelnet <NSIP> 443をテスト
NetScaler上に何も作成されていない IngressClassまたはGatewayClassの名前の不一致 kubectl get ingress -o yaml と Helm ingressClass の値
コンテンツスイッチング仮想サーバーがダウンしているか、503エラー NetScaler が VKS ノード上の NodePort に到達できない curl http://<node-ip>:<nodeport>; ポート範囲 30000～32767 のファイアウォールを確認してください
TLSハンドシェイクが失敗する 誤った名前空間のシークレット シークレットは、コントローラーの名前空間ではなく、Ingress または Gateway と同じ名前空間にある必要があります
VIPからの404 ホストヘッダーが一致しない cURL で --resolve が使用されていることを確認してください。HTTPRoute のホスト名または Ingress ルールのホストを確認してください
特定のパスでの403 レスポンダーポリシーが期待どおりに機能している ブロックされていないパスをテストして、基本ルーティングが正常であることを確認してください
VMware VKS 上の NetScaler は、運用上の複雑さを増すことなく、Kubernetes 上でのエンタープライズアプリケーション配信への実用的な道筋をチームに提供します。プラットフォームチームは、すでに知っている NetScaler ポリシーを使い続けます。開発者は Kubernetes マニフェストで作業します。VKS はクラスターのライフサイクルを処理し、NetScaler はトラフィックを処理し、コントローラーは両者を自動的に同期させます。

結論

VMware VKS上のNetScalerは、運用上の複雑さを増すことなく、Kubernetes上でのエンタープライズアプリケーション配信への実用的な道筋をチームに提供します。プラットフォームチームは、すでに知っているNetScalerポリシーを使い続けます。開発者はKubernetesマニフェストで作業します。VKSがクラスターのライフサイクルを処理し、NetScalerがトラフィックを処理し、コントローラーが両者を自動的に同期させます。

リソース