Release 1.39.6

Version 1.39.6

What’s new

Enhanced security posture

In our ongoing commitment to security and reliability, this release introduces a significant upgrade to NetScaler Ingress Controller. We have transitioned to a new underlying base image, meticulously selected and optimized to ensure that all installed packages are patched against known Common Vulnerabilities and Exposures (CVEs). This strategic update strengthens the security framework of NetScaler Ingress Controller.

Compatibility with OVN CNI-based OpenShift v4.13+ environments

This release addresses and resolves a previously identified issue affecting NetScaler Ingress Controller when operating on OpenShift v4.13 with the OVN CNI. The OpenShift v4.13 has certain major changes w.r.t. OVN CNI. NetScaler Ingress Controller needed an enhancement to ensure compatibility and smooth operation within the specified environment, enhancing stability and performance. Users running NetScaler Ingress Controller on OpenShift v4.13+ with OVN CNI are encouraged to update to this release for continued support and seamless user experience.

Release 1.38.27

Version 1.38.27

What's new

Support for single-site deployment of NetScaler GSLB controller

From this release, single-site deployment of the GSLB controller is supported.

Support to trigger an HTTP response code

A new ingress annotation ingress.citrix.com/default-response-code: '{response-code: "<code>"}' is introduced. This annotation enables you to configure NetScaler to generate an HTTP response code when any one of the following conditions is met on receiving an HTTP request.

-  None of the content switching policies match.
-  All the backend service endpoints are unavailable.

Note:

If the default backend service is added in the ingress, the response code is sent from NetScaler when all the backend service endpoints are down.

Acceptable values for code are 404 and 503. For example, ingress.citrix.com/default-response-code: '{response-code: "404"}'.

For more information, see Annotations.

Support for subnet and IP address range in the rewrite and responder CRD dataset

The rewrite and responder CRD dataset now supports the inclusion of subnet and IP address ranges. This enhancement enables you to add IP address entries efficiently for IPv4, IPv6, and MAC addresses within the CRD dataset.

An example of a dataset with IP address, IP address range, and subnet values for IPv4:

```
dataset:
 - name: redirectIPs
   type: ipv4
   values:
    - 10.1.1.100
    - 1.1.1.1 - 1.1.1.100
    - 2.2.2.2/10
```

Support to configure IP parameters

NetScaler Ingress Controller already supports the BGP advertisement of external IP addresses for type LoadBalancer services.
A new annotation service.citrix.com/vipparams is introduced for services of the type LoadBalancer. This annotation enables you to configure additional parameters such as "metrics" for the advertised IP address.

For information on the supported IP parameters, see nsip configuration.

Fixed Issues

• When multiple ingress controllers coexist within a cluster and the ingress class specified for a controller is switched to another controller, the newly associated NetScaler Ingress Controller was not updating the ingress status correctly when VIP CRD is deployed in the cluster. This issue is now fixed.

Release 1.37.5

Version 1.37.5

Enhancements

• Earlier, the global server load balancing (GSLB) site configuration had to be done manually. Now, the global server load balancing (GSLB) site configuration on NetScaler is done automatically.

Fixed issues

• When multiple ingress controllers coexist within a cluster and the ingress class specified for a controller is switched to another controller, the newly associated NetScaler Ingress Controller does not update the ingress status correctly. This issue is fixed.

Release 1.36.5

Version 1.36.5

What's new

Direct export of metrics to Prometheus

NetScaler ingress controller now supports directly exporting metrics from NetScaler to Prometheus. For more information, see Exporting metrics directly to Prometheus.

Fixed issues

• When you modify the Ingress or service class of an Ingress resource or a load balancer service from a supported to an unsupported class, NetScaler ingress controller now automatically clears stale VIP addresses on the respective Ingress and service resources.
• Multiple NetScaler ingress controllers in the same cluster were causing a loop of creating and deleting VIPs. Now, this issue is fixed.

Release 1.35.6

Version 1.35.6

What's new

The existing Multi-cluster ingress and load balancing solution is now renamed to NetScaler GSLB controller for applications deployed in distributed Kubernetes clusters.

Enhancements

The following enhancements are introduced for NetScaler GSLB controller:

• Optimized the GSE CRD instance reference handling in global traffic policy (GTP).
• Improvement in handling of GTP destination fields such as region, and cluster name.

Release 1.34.16

Version 1.34.16

For NetScaler version 13.1-49.13 or later, Citrix ingress controller version 1.34.16 or later is required. For NetScaler versions prior to 13.1-49.13, older Citrix ingress controller versions are supported.

Fixed issues

• Citrix ingress controller now supports services with target port names. Earlier, services where the target port has a name instead of the port number were not supported and service groups were not configured properly. This issue is fixed now.
• You can now use Citrix ingress controller deployment RBAC Role: kind: IngressClass to associate a particular ingress resource with the ingress controller.
• When Citrix ingress controller receives multiple unknown exceptions, it might terminate event processing. This issue is fixed now.

Enhancements

• Support for services of type ExternalName is enhanced to access services across different namespaces in a Kubernetes cluster.
  For more information, see Support for external name service.

Release version 1.33.4

Version 1.33.4

Enhancements

Support for increased prefix length

The prefix name length for NetScaler entities is enhanced from 7 to 15. When you upgrade Citrix ingress controller to a new version and change the prefix name to a larger value, old entities are not renamed and all entities are newly created. To avoid any stale configuration with the old prefix, you can either delete the ingress and reapply after the upgrade or delete the stale configuration with older prefixes manually from NetScaler.

Support for HTTP PATCH method

PATCH is an HTTP method for changing or adding data to existing resources. Now, the PATCH HTTP method is supported with authentication, authorization, rate limit, BOT, and WAF policy CRDs.

Release version 1.32.7

What's new

NetScaler provides a kubectl plug-in “netscaler-k8s” to inspect ingress controller deployments and aids in troubleshooting operations. You can inspect NetScaler config and related Kubernetes components using the subcommands available with this plug-in.
For more information, see the NetScaler kubectl plugin repository.

Fixed issues

• If an Ingress resource refers to the Listener resource, content-switching policies were getting disassociated from the content-switching virtual server after the Citrix ingress controller restart. This issue is fixed now.
• There was an erroneous entry for device_fingerprint in the BOT CRD definition due to which BOT CRDs were not getting applied. This issue is fixed now.

Enhancements

• Citrix ingress controller now supports multiple response codes in the GTP CRD. Earlier only one response code was allowed in the GTP CRD.
• Citrix ingress controller deployed with the scope namespace is now enhanced to process CRDs in the local namespace. Earlier, it was only supporting Ingress resources.

Note:
You must recreate the BOT CRD instance as per the new definition.

Release v1.31.3

Version 1.31.3

What’s new

Fixed issues

• In this release, Citrix ingress controller is enhanced to handle large-scale services in an improved and optimised approach.

Release v1.30.1

Version 1.30.1

What’s new

Fixed issues

• Earlier, Citrix ingress controller was not binding the policies created for the CORS CRD to the load-balancing virtual server. This issue is now fixed.

• After the Citrix ingress controller reboot, certain entities related to the HTTPRoute were reapplied. This issue is now fixed.

• Citrix ingress controller was skipping service modification events when POD_IPS_FOR_SERVICEGROUP_MEMBERS is enabled for a service of type LoadBalancer. This issue is fixed now.

• While choosing the default certificate, Citrix ingress controller was selecting the certificate in the application namespace instead of the certificate in the namespace provided with the default SSL parameter. Now, Citrix ingress controller selects the certificate in the namespace provided with the default SSL parameter.

• For services of type LoadBalancer, Citrix ingress controller was binding certificates as non-server name indication (SNI) type in the SSL virtual server irrespective of whether SNI is enabled in the SSL profile or not. With this fix, if SNI is enabled in the SSL profile annotation for services of type LoadBalancer, then the certificates get bind as SNI in the SSL virtual server. If SNI is not enabled, certificates are bound as the non-SNI type.

• In the rewrite and responder policy, when the values in two key-value pairs of a string map are identical Citrix ingress controller was considering only one of the key-value pair configurations while applying the policy on the Citrix ADC. This issue is now fixed.

• When the timeslice field was missing in the Rate limit CRD, application configuration was failing on the Citrix ADC appliance. This issue is fixed now.

• Earlier four HTTP methods namely GET, PUT, POST, and DELETE were supported in authentication, authorization, rate limit, BOT, and WAF policies. Citrix ingress controller now supports four additional HTTP methods, HEAD, OPTIONS, TRACE, and CONNECT with these policies.