Release 4.0.16

What's New

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-'

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.

Release 3.5.0

What's New

Optimized NetScaler Resource configuration during NSIC reboot

To minimize operational lag, the NetScaler Ingress Controller (NSIC) now features an optimized startup sequence. This improvement accelerates the configuration of NetScaler resources during reboots/upgrade, allowing the controller to move to a running state faster.

Release 3.4.4

What's New

Fixed Issues

• SSL profiles provided through ConfigMaps are applied incorrectly while upgrading to NetScaler Ingress Controller version 3.3.2.
• The NetScaler ingress controller does not configure the SSL profile present in the ConfigMap for a service of type LoadBalancer.
• While using the listener for front-end configuration, the NetScaler Ingress Controller fails to apply the SSL profile defined in the ConfigMap, if the profile includes cipher configurations.
• The NetScaler Ingress Controller only updates the ConfigMap once and ignores subsequent changes made to the profiles provided in the ConfigMap for Listener.
• NetScaler Ingress Controller continuously throws NITRO exception errors due to version incompatibility between NetScaler version 13.1 and NetScaler Ingress Controller version 3.3.2.
• During initial bootup, when there is processing of Ingresses, NetScaler Ingress Controller incorrectly reports the following message even when no listener is referenced: “IngressOnHold:Referred".
• NetScaler Ingress Controller sometimes bootup due to liveness probe failure.

Release 3.3.2

What's New

SSL CA certificate bundle Support

NetScaler Ingress Controller now supports SSL CA certificate bundle binding to virtual server and service groups based on Ingress or serviceTypeLB.
You can create the Kubernetes secret for the CA certificate bundle and provide the Kubernetes secret in the ingress and serviceTypeLB using the annotation. You can also create a CA certificate bundle in NetScaler and provide the same in ingress and serviceTypeLB using the annotations. For more info, refer this.

Fixed Issues

• When two namespaces with names having a common prefix have services with the same name, deleting an endpoint of a service in one namespace unintentionally removes the service group member bindings of another service deployed in another.
• During startup, the NetScaler Ingress Controller unbinds and rebinds SSL certificates when processing secure ingresses that share the same virtual server IP address and port.

Known Issues

• Upgrading NetScaler Ingress Controller to version 3.3.2 for any build of NetScaler 13.1 fails.

Release 3.2.22

Release 3.2.22

Fixed Issues

• Creating a content switching virtual server can fail due to issues, such as IP address conflicts. When the NetScaler Ingress Controller attempts to bind certificates and policies to a non-existent virtual server, there are misleading, cascading errors in the logs.
• The NetScaler Ingress Controller creates a new SSL profile, overriding the preconfigured SSL profiles provided in the listener instance. This issue occurs when both of the following conditions are met:
  • A preconfigured SSL profile exists in the listener
  • The default SSL SNI certificate is used in the NetScaler Ingress Controller
• With each ingress creation, the NetScaler Ingress Controller deletes the existing SSL profile and creates an SSL profile instead of reusing the existing profile. This change impacts the traffic flow as the status of the SSL content switching virtual server changes from UP to DOWN and then UP again.
• When the NetScaler Ingress Controller receives a virtual IP (VIP) address with an incorrect format, it throws an error but continues to process the remaining configuration. The invalid VIP address prevents the initial creation of the content switching virtual server (CSVS), leading to numerous subsequent errors.
• If an HTTP route that references the same backend service multiple times exists in the cluster before deploying the NetScaler Ingress Controller or NetScaler Kubernetes Gateway Controller, some of the routing rules for that service are missed in the NetScaler configuration.
• During reconciliation of configurations by NetScaler Ingress Controller, the rewrite responder policy bindings for HTTPRoute configuration might get deleted and then added back.

Release 1.2.0

What's New

Expose services of type LoadBalancer

You can create a service of type LoadBalancer and expose it externally using the ingress Citrix ADC. You can manually assign an IP address to the service using the service.citrix.com/frontend-ip annotation. Else, you can also automatically assign IP address to service using the IPAM controller provided by Citrix. The Citrix ingress controller configures the assigned IP address as virtual IP (VIP) in the ingress Citrix ADC. And, the service is exposed using the IP address. For more information, see Expose services of type LoadBalancer.

RedHat OpenShift router sharding support

OpenShift router sharding allows distributing a set of routes among multiple OpenShift routers. By default, an OpenShift router selects all routes from all namespaces. In router sharding, labels are added to routes or namespaces and label selectors to routers for filtering routes. Each router shard selects only routes with specific labels that match its label selection parameters.

Citrix ADC supports OpenShift router sharding when you deploy it as an OpenShift router. For more information, see Deploy the Citrix ingress controller with OpenShift router sharding support.

Establish network connectivity between Kubernetes nodes and Ingress Citrix ADC using Citrix node controller

In Kubernetes environments, when you expose the services for external access through the Ingress device, to route the traffic into the cluster, you need to appropriately configure the network between the Kubernetes nodes and the Ingress device. Configuring the network is challenging as the pods use private IP addresses based on the CNI framework. Without proper network configuration, the Ingress device cannot access these private IP addresses. Also, manually configuring the network to ensure such reachability is cumbersome in Kubernetes environments.

Citrix provides a microservice called as Citrix k8s node controller that you can use to create the network between the cluster and the Ingress device. For more information, see Citrix node controller and Establish network between Kubernetes nodes and Ingress Citrix ADC using Citrix node controller.

Ability to match the ingress path

The Citrix ingress controller now provides an annotation ingress.citrix.com/path-match-method that you can use to define the Citrix ingress controller to consider the path string in the ingress path has prefix expression or as an exact match. For more information, see Annotations.

Ability to customize the prefix for Citrix ADC entities

By default, the Citrix ingress controller adds "k8s" as prefix to the Citrix ADC entities such as, content switching (CS) virtual server, load balancing (LB) virtual server and so on. You can now customize the prefix using the NS_APPS_NAME_PREFIX environment variable in the Citrix ingress controller deployment YAML file. You can use alphanumeric characters for the prefix and the prefix length should not exceed 8 characters.

Fixed issues

• Preconfigured certificates with "." in the certificate name is not supported. For example, hotdrink.cert.
• Citrix ingress controller fails to configure Citrix ADC if it is being deployed in standalone mode after rebooting Citrix ADC VPX.

Known issues

• Red Hat OpenShift support:

Automatic route configuration using the Citrix Ingress Controller (feature-node-watch) is not supported in OpenShift.
When you frequently modify the OpenShift route configuration, the Citrix ingress controller might crash with the following SSL exception: SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC.

After modifying the OpenShift route configuration, applying those changes using the oc apply command does not work.
Workaround: Delete the existing OpenShift route and recreate the route.

• Rewrite policy CRD:

When you apply the rewrite policy CRD deployment file on the Kubernetes cluster, Citrix ingress controller requires 12 seconds to process the CRD deployment file.

Release 3.1.34

Version 3.1.34

What's new

Certificate key bundle support in NetScaler by using the NetScaler Ingress Controller

NetScaler Ingress Controller now supports certificate bundle (certkeybundle) functionality, which is supported on NetScaler starting from release 14.1 build 21.x. With this functionality, the issue with the certificate chain and the additional handling that is required when two certificates share an intermediate CA are resolved. For more information on certificate key bundle support in NetScaler, see Support for SSL certificate key bundle.

Enhanced WAF policy control with the exclude option

You can now use the exclude option to define which URLs, headers, and methods the WAF policy must ignore. If this option is not configured, the WAF inspects all URLs or the targets by default.

This enhancement improves the efficiency of managing WAF policies for microservices-based applications. You can create detailed lists of URLs to be excluded from WAF scanning, allowing for more precise policy enforcement. For example, you can configure the WAF to scan the URL /a while excluding /a/c from inspection. Also, this enhancement allows specifying headers and HTTP methods to be excluded, offering greater flexibility and control over WAF policy configuration.

For more information, see Configure web application firewall policies with the NetScaler Ingress Controller.

Fixed Issues

• NetScaler ingress controller does not work as expected for ingresses if SSL profile settings are present in the ConfigMap.

• The Policy-Based Routing (PBR) configurations performed by the NetScaler Ingress Controller (NSIC) on VPX might not work as expected in the following scenarios:

  • When the Kubernetes worker node, for which NSIC has configured the PBR route on VPX, is deleted.
  • When SNIPs of NetScaler VPX provided for the PBR route are not in the correct format in the NSIC ConfigMap.

• During reconciliation, NetScaler ingress controller expects that the certificate binding is present in the content switching virtual server. But, NetScaler ingress controller does not check if the binding exists.

• If there are multiple references to the same HTTPRoute within the ingress configuration, then the content-switching policy bindings are removed.

• During reconciliation of configurations by NetScaler Ingress Controller, the rewrite responder policy bindings for HTTPRoute configuration might get deleted and then added back.

Release 3.0.5

Version 3.0.5

What's new

ConfigMap for configuring local site preference

GSLB controller now has an option to support local site selection order for GSLB decision. Choosing the virtual IP addresses and applications deployed in the Kubernetes or OpenShift Cluster that is geographically closest to the ADNS IP address ensures efficient traffic routing and minimized latency.

The localSiteSelection parameter is added to the [Netscaler-gslb-controller](https://github.com/netscaler/netscaler-helm-charts/tree/master/netscaler-gslb-controller) Helm chart to enable local site preference. Setting this parameter to true automatically adds the configuration to the GSLB device. The parameter creates a ConfigMap for the GSLB controller, which supports on-the-fly addition, modification, and deletion of the configuration.

For more information, see ConfigMap for configuring local site preference.

Fixed issues

• When a load balancing virtual server is bound to a service group, the order is automatically set to 1. This behavior might triggers an SNMP trap on the client’s side, which might cause unexpected notifications.
• The GSLB controller is incompatible with the NetScaler 13.1-57.x release due to the mandatory GSLB site password requirement.

Release 2.3.15

Version 2.3.15

What's new

Support to bind preconfigured monitors to Kubernetes backend services

You can now bind preconfigured monitors in NetScaler to Kubernetes services using the existing annotation ingress.citrix.com/monitor. This enhancement enables you to perform the following actions:

• Bind the same preconfigured monitor to multiple backend services.

• Bind a different preconfigured monitor to each backend service.

You can now bind preconfigured monitors in NetScaler to services of type LoadBalancer using the existing service annotation service.citrix.com/monitor.

For more information, see annotations.

Enhanced security for communication between GSLB sites

For NetScaler GSLB controller deployment, an additional key sitesyncpassword is supported when creating a secret that GSLB controller uses to connect to GSLB devices and push the configuration. This key enhances the security of communication between the GSLB sites. For more information, see Deploy NetScaler GSLB controller.

Fixed issues

• The service account token generated in Kubernetes for Kubernetes API authentication expires periodically. As a result, the controller restarts periodically to retrieve the newly generated token for continued authentication.

• Configuring the default SSL profile ns_default_ssl_profile_frontend using the annotation service.citrix.com/frontend-sslprofile in services of type LoadBalancer does not bind the default SSL profile to the content switching virtual server.

• GSLB monitor modifications fail intermittently. As a result, changes are not reflected in NetScaler.

Release 2.2.10

Version 2.2.10

What's new

Remote content inspection or content transformation service using ICAP

The Internet Content Adaptation Protocol (ICAP) is a simple lightweight protocol for running a value-added transformation service on HTTP messages. In a NetScaler setup, NetScaler (ICAP client) forwards HTTP requests and responses to one or more ICAP servers for processing. The ICAP servers perform content transformation on the requests and send back responses with an appropriate action to take on the request or response.

In a Kubernetes environment, to enable ICAP on NetScaler through NetScaler Ingress Controller, NetScaler provides the ICAP Custom Resource Definition (CRD). By enabling ICAP, you can perform the following actions:

• Block URLs with a specified string
• Block a set of IP addresses to mitigate DDoS attacks
• Mandate HTTP to HTTPS

For more information, see Remote content inspection or content transformation service using ICAP.

Infoblox integration with NetScaler IPAM Controller

With Infoblox integration, NetScaler IPAM controller assigns IP addresses to services, ingress, or listener resources from Infoblox.
Infoblox integration helps in the following ways:

• Request an available IP address from the specified range.
• Request the IP address associated with a domain name, ensuring the retrieval of a pre-existing IP address.
• Guarantee that the application deployed across various clusters can be accessed using a single, consistent IP address.

Note: After you upgrade to NetScaler IPAM Controller 2.2.10, make sure to upgrade the VIP CRD.

For more information, see Infoblox integration with IPAM controller.

Listener is now supported with NetScaler IPAM Controller

Listener is now supported with NetScaler IPAM Controller. To configure listener support for IPAM, specify the annotation listeners.citrix.com/ipam-range: (<range>) in the listener CRD resource.

Note: After you upgrade to NetScaler IPAM Controller 2.2.10, make sure to upgrade the VIP CRD.

Address field of the ingress resource is updated

In an NSIC sidecar deployment, in which the NetScaler CPX is exposed using a service of type ClusterIP, NodePort, or LoadBalancer, the Address (Status.LoadBalancer.IP) field of the ingress is updated. To enable the ingress status update, specify the updateIngressStatus Helm chart parameter as True.

For more information, see ingress status update for sidecar deployments.

Fixed issues

• After the NSIC upgrade, the CRD specifications in the cluster are deleted, causing the liveness and readiness probes to fail repeatedly. As a result, the NSIC pod gets stuck in a restart loop.

  For information on how to upgrade NSIC, see Upgrade NetScaler Ingress Controller.

• Canary deployment configuration using an ingress annotation such as ingress.citrix.com/canary-weight does not work in a namespace containing a hyphen ("-") in its name.

• When an NSIC pod restarts, SSL profiles are deleted for services of type LoadBalancer.

• NSIC creates a duplicate route entry with the same gateway on NetScaler when there is a change in the node pod CIDR.

  This fix ensures that NSIC deletes the stale route entry before creating a new one for any gateway, preventing duplicate route entries.