NetScaler Ingress Controller for Kubernetes:
You can now specify a custom header that you want to add to the GSLB-endpoint monitoring traffic by adding the "customHeader" argument under the monitor parameter in the global traffic policy (GTP). Earlier, the host URL specified in the GTP YAML was added to the custom header of GSLB-endpoint monitoring traffic by default.
The following GTP excerpt shows the usage of customHeader argument under monitoring.
monitor:
- monType: HTTPS
uri: ''
customHeader: "Host: <custom hostname>\r\n x-b3-traceid: afc38bae00096a96\r\n\r\n"
respCode: '200,300,400'
redirect-status-code and redirect-reason, were not configured on the corresponding virtual server on NetScaler. This issue is fixed now.lookup: nodes is forbidden error. This failure was because of a lack of ClusterRole permission to run API calls to get node-specific information. This issue is fixed now.NetScaler Ingress Controller (NSIC) now accepts default-ssl-sni-certificate argument using which you can provide a secret that is used to configure SSL SNI certificate on NetScaler for HTTPS ingresses and routes.
Configure default-ssl-sni-certificate argument in the NSIC deployment YAML by providing the secret name and the namespace where the secret has been deployed in the cluster as following: --default-ssl-sni-certificate <NAMESPACE>/<SECRET_NAME>.
NSIC can now be deployed at the namespace level in the OpenShift cluster. In this deployment mode, NSIC processes resources pertaining to the given namespace instead of managing all the resources across the entire cluster.
Note:
If NSIC requires access to clusterwide resources such as
config.openshift.io,network.openshift.io, etc., it must be deployed with ClusterRole privileges.
ImagePullSecret support for GSLB ControllerThe GSLB controller Helm chart now supports the imagePullSecret option that ensures smooth integration with container registries that require authentication. Before deploying the Helm chart, you must ensure the corresponding Kubernetes secret is created within the same namespace to enable seamless image pull during helm installation.
ingressClass annotation was not supported when NSIC was deployed with a local RBAC role. This issue is fixed now.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.
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.
From this release, single-site deployment of the GSLB controller is supported.
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.
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
```
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.
NetScaler ingress controller now supports directly exporting metrics from NetScaler to Prometheus. For more information, see Exporting metrics directly to Prometheus.
The existing Multi-cluster ingress and load balancing solution is now renamed to NetScaler GSLB controller for applications deployed in distributed Kubernetes clusters.
The following enhancements are introduced for NetScaler GSLB controller:
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.
kind: IngressClass to associate a particular ingress resource with the ingress controller.ExternalName is enhanced to access services across different namespaces in a Kubernetes cluster.
For more information, see Support for external name service.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.
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.
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.
device_fingerprint in the BOT CRD definition due to which BOT CRDs were not getting applied. This issue is fixed now.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.