Skip to content

Helm Chart Release Notes for NetScaler Ingress Controller/ GSLB Controller v4.2.26

Choose a tag to compare

View all tags
@subashd subashd released this 26 Aug 16:59
nsic-v4.2.26
ee69d79
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

What's New

Restrict node-watch route programming to specific nodes

A new Helm chart value, nodeWatchLabelSelector, allows you to restrict node-watch route and PBR programming to specific nodes. You can set it to a label selector such as kubernetes.io/os: linux. With this selector, the feature programs only the Linux nodes and skips the Windows nodes, preserving back-end connectivity. The default value {} keeps the existing behavior and programs all nodes. For the Gateway Controller chart, the equivalent value is gatewayController.nodeWatchLabelSelector.

Updated security controls for bot and web application policies

NetScaler now allows precise tuning of rate limits, transactions per second, CAPTCHA challenges, and client fingerprinting. Several policy creation fields are now optional to simplify your setup. To prevent partial policy failures, using these new fields requires NetScaler version 14.1 build 72.57 or later. If you use Kubernetes, make sure to install the updated custom resource definitions before upgrading.

Customizable default response for unmatched traffic

NetScaler Ingress Controller now lets you customize the response served when incoming traffic does not match any ingress rule, using the ingress.citrix.com/default-response-code annotation.
With this feature, you can:
Set any valid 3-digit HTTP status code (for example, 404, 503, or 521), instead of being limited to 404 and 503.
Choose the responder action type:

  • respondwith (default) – return a response with the specified status code.
  • respondwithhtmlpage – serve an uploaded HTML maintenance page with a custom status code.
  • redirect – redirect unmatched traffic to a specified URL.

Fixed issues in NSIC and GSLB

  • When configuration persistence is enabled on NetScaler CPX, the persisted configuration is not restored at pod startup. As a result, NetScaler Ingress Controller re-pushes the entire configuration on every restart, making NetScaler CPX recovery as slow as provisioning a new pod.
  • When you restart NetScaler Ingress Controller, the servicegroup annotations with netprofile are not applied.
  • When the Kubernetes API server throttles requests (for example, with API Priority & Fairness enabled or during high resource churn), the NetScaler Ingress Controller does not handle it correctly. Instead of waiting and retrying, it treats the throttling as a fatal error and restarts. The restart reloads all resources, triggering even more throttling. This loop leaves the ingress configuration temporarily out of sync and causes intermittent service disruption on NetScaler until the ingress controller recovers.
  • When a hardened FRONTEND_SSL_PROFILE has Diffie-Hellman (DH) enabled and references a missing DH file, NetScaler Ingress Controller silently drops the entire SSL profile update.
  • NetScaler Ingress Controller 4.x.x build fails to apply Cross-Origin Resource Sharing (CORS) CRDs even after getting a "success" status message, because the generated responder policy references a non-existent pattern set name.
  • When you upgrade the NetScaler Kubernetes GSLB controller from a 2.2.x build to a 4.x build, the old GSLB configuration stays on NetScaler. Due to this issue, the DNS record for the GSLB domain keeps pointing to the old virtual server, which is now down, until you restart the controller pod. An old load balancing monitor also stays behind, and restarting the pod does not remove it.
  • When you configure forms-based authentication in the authpolicy CRD using the authentication_host_cert field, NetScaler Ingress Controller creates an SSL-type authentication (AAA) virtual server. However, the controller does not upload the certificate from the referenced TLS secret to NetScaler. The sslcertkey is therefore missing. As a result, the authentication virtual server has no certificate bound to it.
  • When configuration persistence is enabled on NetScaler CPX, the persisted configuration is not restored at pod startup. As a result, NetScaler Ingress Controller re-pushes the entire configuration on every restart, making NetScaler CPX recovery as slow as provisioning a new pod.
  • During a rolling restart of NetScaler CPX with config persistence enabled, the new pod starts too early. This issue happens when the application label and the deployment name differ. The new pod does not wait for the outgoing pod to save its configuration. So the saved configuration is not available. As a result, the NetScaler Ingress Controller provisions the entire configuration again.
  • When the Kubernetes API server throttles requests (for example, with API Priority & Fairness enabled or during high resource churn), the NetScaler Ingress Controller does not handle it correctly. Instead of waiting and retrying, it treats the throttling as a fatal error and restarts. The restart reloads all resources, triggering even more throttling. This loop leaves the ingress configuration temporarily out of sync and causes intermittent service disruption on NetScaler until the ingress controller recovers.
  • In the NetScaler Ingress Controller authpolicy CRD handler, two name references pass the wrong NITRO object to get name. This generates a name that does not match the actual Authentication, Authorization, and Auditing virtual server. As a result, SSL certificate bind and unbind operations for forms-based Authentication, Authorization, and Auditing target a virtual server that does not exist on NetScaler.
  • When the host name and service name in an Ingress match the traffic policy, GSLB automatically creates a global service entry. After the entry is created, if the user changes the service name in the Ingress to a different value, GSLB rejects the change because the new service name no longer matches the traffic policy. As a result, the automatically created global service entry stays in place, and the controller takes no action to correct or remove it.
  • When the NetScaler Kubernetes Gateway Controller runs with an RBAC role that lacks permission for one resource type, such as the NetScaler CRDs, the entire controller repeatedly restarts instead of skipping only that resource. As a side effect, other features that have the correct permissions, such as the Kubernetes Gateway API HTTPRoute handling, also stop working. This failure makes the issue confusing and larger than the actual misconfiguration.
  • When you change a Global Traffic Policy between the local first and canary traffic policies, NetScaler GSLB controller leaves stale content switching and GSLB objects behind. The controller does not clean up these objects even after you reboot it. As a result, stale configuration remains on NetScaler.
  • Updating an existing HTTPS listener that uses a preconfigured certificate and a default action fails with NetScaler error 695. This issue occurs because the default policy binding is re-sent without a priority.
  • When you add IP addresses through the NetScaler Ingress Controller configuration, an invalid value is accepted instead of being rejected. For example, a plain number such as "12345678" is treated as a valid IP address and programmed onto NetScaler. As a result, an incorrect IP address is applied to NetScaler.
  • In a Citrix Listener with Citrix HTTPRoute configuration, updating an HTTPRoute and reapplying it does not take effect and might report a "certificate already bound to the service" error.
  • GSE cleanup in the GSLB controller is driven entirely from in-memory state. If an Ingress backend serviceName change lands while the controller process is restarting, the old service's GSE is never cleaned up and stays orphaned indefinitely.
Assets 2
Loading