NetScaler® Operator リリースノート
バージョン 3.6.0
新機能
注:
古い設定から新しい設定への調整中に、設定変更によりCitrix CRD設定でダウンタイムが発生する可能性があります。
NetScaler IPAM Controller のサポート
NetScaler Kubernetes Gateway Controller は、独自の NetScaler IPAM コントローラーを使用して、Kubernetes Gateway リソースの IP アドレス割り当てをサポートします。IPAM が有効になっている場合、
spec.addresses で静的 IP アドレスが設定されていないゲートウェイは、IPAM コントローラーから自動的に仮想 IP (VIP) を受け取ります。これにより、各ゲートウェイの IP アドレスを手動で割り当てて追跡する必要がなくなります。
詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-kubernetes-gateway-controller/ipam-controller> を参照してください。
Gateway および TCPRoute/UDPRoute CRD を使用した TCP/UDP アプリケーションの公開
NetScaler Kubernetes Gateway Controller は、NetScaler を使用した Kubernetes Gateway API を介して、TCP/UDP ベースのアプリケーションの公開をサポートします。
詳細については、NetScaler Kubernetes Gateway Controller の展開 および NetScaler CPX Kubernetes Gateway Controller の展開 を参照してください。
アップグレード時の NetScaler CPX 設定の永続化
NetScaler CPX の設定永続化により、ポッドのシャットダウン時に実行中の設定を Kubernetes ConfigMap に保存することで、新しいポッドが稼働するまでの時間を大幅に短縮します。この機能強化により、Helm アップグレード、ローリングアップデート、またはその他の置き換えによって代替ポッドが起動した場合でも、設定が自動的に復元されます。新しいポッドはほとんどの設定が事前にロードされた状態で初期化されるため、トラフィックを処理する準備が整うまでの遅延が最小限に抑えられます。
以前は、NetScaler CPX ポッドが再起動するたびに、イングレスおよびサービスリソースを通じて蓄積された実行中の設定が失われていました。このため、NetScaler Ingress Controller (NSIC) は、NITRO API を介してすべてのリソースを最初から再プッシュする必要がありました。大規模なイングレス展開では、この調整プロセスにより、NetScaler CPX がトラフィックを管理する準備が完全に整うまでに長い遅延が発生していました。
詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/accelerate-cpx-upgrade-process> を参照してください。
OWASP CRD を使用して OWASP Top 10 保護ポリシーを構成する
NetScaler Ingress Controller は、OWASP CRD を使用した OWASP Top 10 保護ポリシーの構成をサポートするようになりました。OWASP Top 10:2025 は、Web アプリケーションに対する最も重大なセキュリティリスクを表しています。OWASP CRD (owasppolicy) を使用すると、OWASP Top 10 カテゴリに準拠した包括的な WAF およびボット管理保護を単一の Kubernetes カスタムリソースで構成できます。
詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/crds/owasp-top-10-protection-policies> を参照してください。
IPAM コントローラーおよびイングレスコントローラーとの BIND DNS 統合
BIND 9 は、DNS プロトコルの完全な実装です。BIND 9 は、権威ネームサーバー、リゾルバー、およびサポートされているホストではスタブリゾルバーとして構成できます。詳細については、Bind 9 を参照してください。
NetScaler Ingress Controller は、ipam-range アノテーションを使用して、Ingress および LoadBalancer タイプのサービスに IP を割り当てることをサポートしています。IPAM コントローラーには、NetScaler が提供する VIP CustomResourceDefinition (CRD) が必要です。VIP CRD は、NetScaler Ingress Controller と IPAM コントローラー間の内部通信に使用されます。このリリースから、VIP CRD に変更があります。VIP CRD は、VIP に関連付けられた hostname フィールドをサポートするようになりました。
詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/bind-dns-integration> を参照してください。
NetScaler Ingress Controller の再起動中の NetScaler リソース構成の最適化
NetScaler Ingress Controller (NSIC) は、運用上の遅延を最小限に抑えるために最適化された起動シーケンスをサポートするようになりました。この機能により、再起動またはアップグレード時の NetScaler リソースの構成が高速化され、コントローラーがより迅速に実行状態に到達できるようになります。
NetScaler ノードコントローラーを使用した OpenShift の OVN-CNI サポート ノードコントローラーとルーターポッドは、OpenShift 4.x クラスターのデフォルト CNI である OVN-Kubernetes をサポートしています。OpenShift ノードと Citrix ADC の間に、ovn-k8s-mp0 インターフェースを使用して VXLAN オーバーレイネットワークが確立されます。
詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/network/ovn-kubernetes-cni-support> を参照してください。
GTP CRD での ingressHostName、multipleIPResponse、および emptyDownResponse のサポート
-
multipleIPResponse(MIR) およびemptyDownResponse(EDR) — 新しいオプションのポリシーフィールド multipleIPResponse (MIR) と `emptyDownResponse (EDR) は、自動作成された GSLB 仮想サーバー上の対応する -MIR/-EDR パラメーターに伝播され、CRD から直接マルチ IP DNS 応答と空ダウン動作を可能にします。
詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/gslb/gslb#gtp-crd> を参照してください。
CRDのエンティティ名変更
NetScaler Custom Resource Definition (CRD) インスタンスが作成されると、NetScaler Ingress Controller はその CRD インスタンスに関連付けられた複数の NetScaler エンティティを生成します。NetScaler Ingress Controller は、CRD インスタンスとの関連付けを維持するために、各エンティティに一意の名前を保持します。エンティティの命名は CRD 名に直接基づいているため、一部の NetScaler エンティティ名が最大文字数制限を超えていました。
NetScaler Ingress Controller 4.0.16 以降、CRD 作成時に短いエンティティ名を生成するために、以下の方法を使用して命名規則が最適化されています。
-
ハッシュ化された命名: エンティティ名の一部がハッシュ化され、全体の長さが短縮されます。
-
情報保持: 必要な Kubernetes 関連のメタデータは、NetScaler がエンティティコメントをサポートしている場合、エンティティのコメントフィールドに保持されます。
-
互換性の向上: 名前は NetScaler の文字制限に準拠しつつ、完全なトレーサビリティを維持します。詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/entity-name-change-for-crds>を参照してください。
GSLBコントローラーの改善
GSLBコントローラーは、以下の改善を含むように強化されました。
-
TCP、UDP、SSLなど、すべてのIngressリソースタイプに対するGSE自動作成のサポートを追加しました。
-
GslbConfigSyncMonitor は、GSLB サイト監視の効率を向上させるため、マスター GSLB ノードでデフォルトで有効になりました。詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/gslb/gslb>を参照してください。
ServicetypeLB: スマートアノテーションのイベント変更
NetScaler Ingress Controller リリース 4.0.16 以降、ServiceTypeLB で以下のいずれかのアノテーションを変更すると、NetScaler Ingress Controller は NetScaler で構成を削除して再作成するのではなく、構成を変更します。
"service.citrix.com/lbvserver",
"service.citrix.com/csvserver",
"service.citrix.com/servicegroup",
"service.citrix.com/monitor",
"service.citrix.com/analyticsprofile",
"service.citrix.com/insecure-redirect",
"service.citrix.com/secret",
"service.citrix.com/preconfigured-certkey",
"service.citrix.com/ca-secret",
"service.citrix.com/preconfigured-ca-certkey",
"service.citrix.com/backend-secret",
"service.citrix.com/preconfigured-backend-certkey",
"service.citrix.com/backend-ca-secret",
"service.citrix.com/preconfigured-backend-ca-certkey"
'service.citrix.com/ssl-termination-',
'service.citrix.com/frontend-tcpprofile-',
'service.citrix.com/backend-tcpprofile-',
'service.citrix.com/frontend-httpprofile-',
'service.citrix.com/backend-httpprofile-',
'service.citrix.com/frontend-sslprofile-',
'service.citrix.com/backend-sslprofile-'
NetScalerマルチクラスターIngressデプロイメントのSSLパススルーサポート
SSLパススルー機能を使用すると、受信するセキュアソケットレイヤー (SSL) リクエストを、ロードバランサーで復号化するのではなく、サーバーに直接渡して復号化できます。SSLパススルーはWebアプリケーションのセキュリティに広く使用されており、TCPモードを使用して暗号化されたデータをサーバーに渡します。
NetScaler Ingress Controller 4.0.16 以降、NetScaler マルチクラスター Ingress デプロイメントで SSL パススルー機能がサポートされます。詳細については、
<https://docs.netscaler.com/ja-jp/netscaler-k8s-ingress-controller/configure/ssl-passthrough-multicluster> を参照してください。
修正された問題 - NetScaler Kubernetes Gateway Controller
WebSocket はデフォルトで無効になっています。このユースケースには、
HTTPProfile CRD を使用できるようになりました。
プロファイルで
GatewayClass が提供された場合に、HTTPProfile CRD コントローラーで問題が確認されました。プロファイルで提供された GatewayClass 名により、「ref_manager」属性がないというエラーが発生する可能性があります。
ホスト名が同じ親ドメインを共有している場合、ワイルドカードよりも正しい優先順位が適用されません。この問題の修正として、同じコンテンツスイッチング仮想サーバー上の重複するホスト名のルーティング優先度が強化されました。
RequestHeaderModifier.set は、ヘッダーが既に存在する場合にのみ機能します。
URLRewrite.replacePrefixMatch は二重スラッシュを生成するため、パスの正規化が正しく処理されません。
名前が20文字まで同じ2つのHTTPルートは、2つではなく1つの負荷分散仮想サーバーを作成します。負荷分散仮想サーバーの命名で競合が確認されています。
コントローラーの再起動後、またはHTTPルートの後にサービスイベントが受信された後、負荷分散仮想サーバーのサービスグループバインディングが失われます。
Kubernetes API への GET 呼び出し中に、
429 errors が確認されました。
修正された問題 - NetScaler Ingress Controller
-
イングレスで複数のサービスが指定されており、そのうちの1つに対してのみモニターが作成される場合、カスタムモニターの作成は失敗します。
-
CRUD 操作中に、ボット CRD 内の複数のボットプロファイルパラメーターが見落とされます。
-
エラーのログ記録中に、誤った例外処理が確認されています。
-
NetScaler Ingress Controller ポッドが再起動すると、コントローラーがダウンしている間に削除されたイングレスの構成をコントローラーが削除できません。
-
名前が20文字まで同じ2つのHTTPルートは、2つではなく1つの負荷分散仮想サーバーを作成します。
-
NetScaler Ingress Controller は、IPAM がコンテンツスイッチング仮想サーバーの IP アドレスを提供する前であっても、存在しないサービスグループにサービスグループメンバーをバインドしようとします。
-
When multiple pods share the same pod IP address, deleting one pod can remove the active pod’s endpoint state on NetScaler. In some cases, this can cause NetScaler Kubernetes Ingress Controller to crash with a key error.
-
Kubernetes entities (namespace, services, etc) containing hyphens (-) caused configuration failures for NetScaler entities such as authpolicy and patset, since these entity names do not permit hyphens on the NetScaler.
-
NSIC/GSLB Controller は、負荷がかかると Kubernetes API server から HTTP 429 (Too Many Requests) エラーを受け取り、一部のウォッチイベントが見逃される可能性がありました。Helm chart は現在、専用の FlowSchema と PriorityLevelConfiguration (API Priority and Fairness) を提供しており、これにより NSIC の API トラフィックには予約された同時実行共有が与えられ、他のクライアントと並んでレート制限されることがなくなりました。