NetScaler® Operator release notes
Version 3.6.0
What’s new
Note:
During reconcilation of old config to the new config, you might observe downtime for Citrix CRDs configuration due to config change.
Support for NetScaler IPAM Controller
NetScaler Kubernetes Gateway Controller supports IP address allocation for Kubernetes Gateway resources using our own NetScaler IPAM controller. When IPAM is enabled, Gateways that do not have a static IP address configured in spec.addresses automatically receive a Virtual IP (VIP) from the IPAM controller. This eliminates the need to manually assign and track IP addresses for each Gateway.
For more information, see https://docs.netscaler.com/en-us/netscaler-kubernetes-gateway-controller/ipam-controller.
Exposing a TCP/UDP application by using Gateway and TCPRoute/UDPRoute CRDs
NetScaler Kubernetes Gateway Controller supports exposing a TCP/UDP-based application by using the Kubernetes Gateway API with NetScaler.
For more information, see Deploy NetScaler Kubernetes Gateway Controller and Deploy NetScaler CPX Kubernetes Gateway Controller.
NetScaler CPX configuration persistence during upgrade
NetScaler CPX configuration persistence significantly reduces the time required for new pods to go live by saving the running configuration to a Kubernetes ConfigMap during pod shutdown. This enhancement ensures that when a replacement pod starts, whether due to a Helm upgrade, rolling update, or any other replacement, the configuration is automatically restored. Because the new pod initializes with most settings pre-loaded, the delay in becoming ready to handle traffic is minimized.
Previously, the running configuration accumulated through ingress and service resources was lost whenever a NetScaler CPX pod restarted. This required the NetScaler Ingress Controller (NSIC) to re-push every resource from scratch through the NITRO API. In large-scale ingress deployments, this reconciliation process caused a lengthy delay before the NetScaler CPX was fully ready to manage traffic.
For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/accelerate-cpx-upgrade-process.
Configure OWASP Top 10 protection policies with the OWASP CRD
NetScaler Ingress Controller now supports configuring OWASP Top 10 Protection Policies with the OWASP CRD. The OWASP Top 10:2025 represents the most critical security risks to web applications. Using the OWASP CRD (owasppolicy), you can configure comprehensive WAF and Bot management protections aligned with the OWASP Top 10 categories in a single Kubernetes custom resource.
For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/crds/owasp-top-10-protection-policies.
BIND DNS integration with IPAM controller and ingress controller
BIND 9 is a complete implementation of the DNS protocol. BIND 9 can be configured as an authoritative name server, a resolver, and, on supported hosts, a stub resolver. For more information, see Bind 9.
NetScaler Ingress Controller supports assigning IPs to Ingresses and Services of type LoadBalancer by using the ipam-range annotation. The IPAM controller requires the VIP CustomResourceDefinition (CRD) provided by NetScaler. The VIP CRD is used for internal communication between NetScaler Ingress Controller and the IPAM controller. From this release there is a change in the VIP CRD. The VIP CRD now supports the hostname field which is associated with the VIP.
For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/bind-dns-integration.
Optimized NetScaler Resource configuration during NetScaler Ingress Controller reboot
NetScaler Ingress Controller (NSIC) now supports an optimized startup sequence to minimize operational lag. This feature accelerates the configuration of NetScaler resources during reboots or upgrades, and enables the controller to reach a running state faster.
OVN-CNI support for OpenShift using NetScaler node controller The node controller and router pod support OVN-Kubernetes, the default CNI in OpenShift 4.x clusters. VXLAN overlay network is established between the OpenShift nodes and the Citrix ADC using the ovn-k8s-mp0 interface.
For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/network/ovn-kubernetes-cni-support.
Supporting ingressHostName, multipleIPResponse and emptyDownResponse in the GTP CRD
-
ingressHostName— A new optional field under globaltrafficpolicy.spec.hosts[] lets you match an Ingress by its rule hostname independently of the GTP’s Host (DNS) field, so a single GSLB domain can be backed by an Ingress that publishes a different hostname. -
multipleIPResponse(MIR) andemptyDownResponse(EDR) — New optional [policy fields multipleIPResponse (MIR) and `emptyDownResponse (EDR), that propagate to the corresponding -MIR/-EDR parameters on the auto-created GSLB vserver, enabling multi-IP DNS responses and empty-down behaviour directly from the CRD.
For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/gslb/gslb#gtp-crd.
Entity name change for CRDs
When a NetScaler Custom Resource Definition (CRD) instance is created, the NetScaler Ingress Controller generates multiple NetScaler entities associated with that CRD instance. The NetScaler Ingress Controller maintains unique names for each entity to preserve its association with the CRD instance. Since entity naming is based directly on CRD names, some NetScaler entity names exceeded the maximum character limit.
Starting with NetScaler Ingress Controller 4.0.16, the naming convention is optimized by using the following approach to generate shorter entity names during CRD creation:
- Hashed naming: A portion of the entity name is hashed to reduce the overall length.
- -Preserved information: The necessary Kubernetes related metadata is retained in the entity’s comment field, if the entity comment is supported by NetScaler.
- Improved compatibility: Names comply with NetScaler character restrictions while maintaining full traceability. For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/entity-name-change-for-crds.
GSLB controller improvements
GSLB controller is enhanced to include the following improvements:
-
Added support for GSE auto-creation for all Ingress resource types, including TCP, UDP, SSL, and others.
-
GslbConfigSyncMonitor is now enabled by default on the master GSLB node to improve GSLB site monitoring efficiency. For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/gslb/gslb.
ServicetypeLB: Event modification for smart annotations
Starting with NetScaler Ingress Controller release 4.0.16, if you modify any of the following annotations in ServiceTypeLB, the NetScaler Ingress Controller modifies the configuration rather than deleting and recreating it in 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-'
<!--NeedCopy-->
SSL passthrough support for NetScaler multi-cluster ingress deployment
SSL passthrough feature allows you to pass incoming secure sockets layer (SSL) requests directly to a server for decryption, rather than decrypting the request using a load balancer. SSL passthrough is widely used for web application security, and it uses the TCP mode to pass encrypted data to servers.
Starting with NetScaler Ingress Controller 4.0.16, the SSL passthrough feature is supported for NetScaler multi-cluster ingress deployment. For more information, see https://docs.netscaler.com/en-us/netscaler-k8s-ingress-controller/configure/ssl-passthrough-multicluster.
Fixed issues - NetScaler Kubernetes Gateway Controller
- WebSocket is disabled by default. You can now use the HTTPProfile CRD for this use case.
- Issues observed in the HTTPProfile CRD controller when GatewayClass is provided in the profile. The GatewayClass name provided in the profile might cause no attribute ‘ref_manager’ error.
- Host names are not getting the correct precedence over wildcards when they share the same parent domain. As a fix for this issue, routing priority for overlapping host names on the same content switching virtual server is enhanced.
- RequestHeaderModifier.set works only if the header already exists.
- URLRewrite.replacePrefixMatch produces double slashes, and therefore path normalization is not handled correctly.
- Any two HTTP Routes whose names are the same up to 20 characters create one load balancing virtual server instead of two. Conflicts are observed in load balancing virtual server naming.
- Load balancing virtual server service group binding is lost after controller restart or service event is received after the HTTP route.
- During GET calls to the Kubernetes API, the 429 errors are observed.
Fixed issues - NetScaler Ingress Controller
- Custom monitor creation fails if more than one service is mentioned in the ingress, and the monitor is created only for one of them.
- During CRUD operations, multiple bot profile parameters in the bot CRD are missed.
- Incorrect exception handling is observed while logging errors.
- When a NetScaler Ingress Controller pod restarts, the controller fails to delete the configuration for ingress(es), which are deleted when the controller is down.
- Any two HTTP Routes whose names are the same up to 20 characters create one load balancing virtual server instead of two.
- NetScaler Ingress Controller tries to bind service group members to a non-existent service group even before IPAM provides IP address for the content switching virtual server.
- NetScaler Ingress Controller tries to bind service group members to a non-existent service group even before IPAM provides IP address for the content switching virtual server.
- 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 could receive HTTP 429 (Too Many Requests) errors from the Kubernetes API server under load, causing some watch events to be missed. The Helm chart now ships a dedicated FlowSchema and PriorityLevelConfiguration (API Priority and Fairness) so NSIC’s API traffic is given a reserved concurrency share and is no longer rate-limited alongside other clients.