NetScaler Ingress Controller for Kubernetes:
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.
ANY as protocol and port as * in the Ingress resource. This issue is now fixed.SCOPE is introduced. You can set the value of the SCOPE environment variable as local or cluster. When you set this variable as local, Citrix ingress controller is deployed with a Role binding that has limited privileges. You can use this option when you want to deploy Citrix ingress controller with minimal privileges for a particular namespace with Role binding. By default, the value of SCOPE is set as cluster and Citrix ingress controller is deployed with the ClusterRole binding. For more information, see deploy Citrix ingress controller for a namespace.NS_VIP and NS_SVC_LB_DNS_REC, DNS records were getting created spuriously even for virtual IP addresses assigned using NS_VIP. This behavior was occurring for services of type LoadBalancer. Now, DNS address records are added on Citrix ADC only for the IP addresses assigned by Citrix IPAM controller.Role does not support kind: IngressClass.Wildcard DNS domains are used to handle requests for non-existent domains and subdomains. Now, Citrix ingress controller supports configuring wildcard DNS domains on a Citrix ADC. A new CRD wildcarddnsentry is introduced to support wildcard DNS domains.
For more information, see Configuring wildcard DNS domains through Citrix ADC ingress controller.
Open policy agent (OPA) is an open source, general-purpose policy engine that unifies policy enforcement across different technologies and systems. Now, Citrix ingress controller supports OPA through the HTTP callout.
For more information, see Open policy agent support for Kubernetes with Citrix ADC.
service parameter was mandatory in the analytics configuration ConfigMap. If the service parameter is missing, distributed tracing was not working. This issue is fixed now.OPTIMIZE_ENDPOINT_BINDING is introduced to enable or disable binding of back-end endpoints to a service group in a single API call. This variable is recommended when there are a large number of endpoints (pods) per application. This enhancement is applicable only for Citrix ADC release 13.0–45.7 and higher versions.For HTTP header value-based canary deployments, Citrix ingress controller now supports multiple canary header values as a list of strings. Previously, only one HTTP header value was supported. For more information, see Simplified canary deployment using Ingress annotations.
You can now add DNS records for a service of type LoadBalancer on Citrix ADC by configuring the NS_SVC_LB_DNS_REC environment variable. Earlier, adding DNS records on Citrix ADC was supported only for Ingress resources. For more information, see Adding DNS records for services of type LoadBalancer.
For Helm chart-specific changes, see the Helm chart release notes.
Consistent hashing algorithms are mostly used for load balancing cache servers to achieve stateless persistency. Consistent hashing can ensure that when a cache server is removed, only the requests cached in that specific server is rehashed and the rest of the requests are not affected. You can now configure the consistent hashing algorithm on Citrix ADC using Citrix ingress controller.
For more information, see the consistent hashing algorithm support.
You can configure the request-retry feature on Citrix ADC to forward the client request to the next available backend server whenever there is a connection failure to the backend server. Using the AppQoE CRD provided by Citrix, you can now configure request-retry policies on Citrix ADC with Citrix ingress controller. The AppQoE CRD enables the communication between the Citrix ingress controller and Citrix ADC for enforcing AppQoE policies.
For more information, see the AppQoE support documentation.
NS_NITRO_READ_TIMEOUT parameter to configure the Citrix ingress controller timeout for NITRO API calls. The default value for timeout is 20 seconds.Earlier, Citrix ingress controller was configuring services even when the service port information is incorrect in the Ingress resource definition. This issue is fixed now.
The functionality for logging packets to support observability was missing in the Ratelimit CRD. This issue is fixed now.
Ingress class for associating the rewrite and responder CRD to the ingress controller was missing. This issue is fixed now.
The servicenames section was made non-mandatory for the Auth CRD so that the Auth CRD can be referred via annotation in the Ingress.
For Helm chart-specific changes, see the Helm chart release notes.
Auth CRD now supports authentication and authorization policies with Citrix ADC expression syntax. For more information, see Authentication and authorization policies for Kubernetes with Citrix ADC.
For Helm chart-specific changes, see the Helm chart release notes.
Citrix ingress controller already provides content routing CRDs such as the Listener CRD for front-end configurations and HTTProute for back-end routing logic. Now, Listener CRD can be applied for Ingress resources using an annotation provided by Citrix. Through this feature, you can use the Listener CRD for your Ingress resource and separate the creation of the front-end configuration from the Ingress definition. Hence, NetOps can separately define the Listener resource to configure front-end IP, certificates, and other front-end parameters (TCP, HTTP, and SSL). Any configuration changes can be applied to the listener resources without changing each Ingress resource.
For more information, see Listener CRD support for Ingress using annotation.
Now, you can view Citrix ingress controller log messages in JSON format. For more information, see ConfigMap support.
Earlier, if an Ingress resource and an OpenShift route have the same name and the OpenShift route does not belong to a valid route sharding then the ingress resource was getting unconfigured. This issue is fixed now.
When a service of the type LoadBalancer was modified and the IPAM controller was used for the IP address configuration, Citrix ingress controller was repeatedly configuring and unconfiguring the service earlier. This issue is fixed now
Earlier, while deploying the latest version of the multi-cluster ingress controller the following error was getting displayed:
AttributeError: 'IngressCRDInstance' object has no attribute 'listener_mode'. Now, this issue is fixed.
When Citrix ADC was rebooting, the following traceback was getting displayed earlier:
TypeError: ‘NoneType’ object is not iterable. Now, this issue is fixed.
After the re-creation of Ingress, CRD policies were not getting bound to load balancing virtual servers. This issue is now fixed.
You can now apply policies such as rewrite responder, rate limit, auth, WAF, and bot for ingress resources and services of type load balancer by referring them using annotations. Using this feature, when there are multiple services in an Ingress resource, you can apply CRDs for a specific service or all the services based on your requirements. For more information, see Apply CRDs through annotations.