Release 1.26.7

Version 1.26.7

What's new

Enhancements

• 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.

Helm chart-specific changes

For Helm chart-specific changes, see the Helm chart release notes.

Release 1.25.6

Version 1.25.6

What's new

Consistent hashing algorithm support

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.

AppQoE 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.

Enhancements

• Citrix ingress controller logs are enhanced to indicate the missing subnet IP address (SNIP) information on Citrix ADC.
• A new key service is added under the endpoint parameter for analytics configuration using ConfigMap. You can specify an IP address or service name of the Citrix ADC observability exporter service depending on whether the service is running on a virtual machine or as a Kubernetes service.
• Now, you can configure the NS_NITRO_READ_TIMEOUT parameter to configure the Citrix ingress controller timeout for NITRO API calls. The default value for timeout is 20 seconds.

Fixed issues

• 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.

Helm chart specific changes

For Helm chart-specific changes, see the Helm chart release notes.

Release 1.24.4

Version 1.24.4

What's new

Auth expression support

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.

Fixed issues

• When a Kubernetes service is deployed on OpenShift with OVN CNI, Citrix ingress controller was failing with an exception. Now, this issue is fixed.

Helm chart specific changes

For Helm chart-specific changes, see the Helm chart release notes.

Release 1.23.10

Version 1.23.10

What's new

Listener CRD support for Ingress using annotations

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.

Support for setting log format as JSON

Now, you can view Citrix ingress controller log messages in JSON format. For more information, see ConfigMap support.

Fixed issues

• 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.

Release 1.22.7

Version 1.22.7

What's new

Apply CRDs through annotations

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.

Fixed issues

• For deployments where Citrix ADC CPX acts as tier 1 ADC, endpoints were not getting added if Citrix IPAM controller is not deployed. This issue is fixed now.

Release 1.21.9

Version 1.21.9

Enhancements

• Citrix ingress controller now supports WAF features such as request side streaming, configuring RFC profile, and grammar-based SQL injection detection support. For more information, see the example YAML file. See, configuring web application firewall policies for information on how to configure WAF.
• Previously Ingress status was updated with an external IP address only when Citrix ingress Controller is started with the –update-ingress-status argument configured as yes. Now, Ingress status is updated with an external IP address by default for tier-1 deployments. This argument –update-ingress-status configured as yes is required for tier-2 deployments with Citrix ADC CPX for updating the ingress status with external IPs.
• For multi-cluster Ingress, Citrix ingress controller now supports HTTPS monitors with SNI enabled by default during the TLS handshake.
• For multi-cluster Ingress, Citrix ingress controller now supports source IP persistence. For more information, see the multi-cluster ingress documentation.
• Citrix ingress controller feature-node-watch now supports OpenShift OVN CNI.

Fixed issues

• Earlier, OpenShift feature-node-watch was not configuring the correct routes on the Citrix ADC after the node modify event for OpenShift-SDN CNI. This issue is now fixed.
• Sometimes Listener CRD was failing to create cipher groups due to the name size limit of 39 characters. This issue is fixed by using the hash to limit the name size to 39 characters.
• The ingress.citrix.com/csvserver annotation was getting applied only when the first ingress belonging to the content switching virtual server is created. Now, this annotation gets applied regardless of the order of ingresses.
• In the Citrix ADC CPX BGP deployment, the service of type LoadBalancer status was not getting updated with external IP sometimes. This issue is fixed.
• Citrix ingress controller now supports the modification of service of type LoadBalancer by clearing the stale entries in Citrix ADC. This modification includes any port group and annotation modifications.
• While adding domain name servers through ConfigMap for tier 1 Citrix ADC, the existing domain name server configuration on Citrix ADC VPX was getting deleted if the existing configuration was not specified as part of the ConfigMap. Now, this issue is fixed.
• Earlier, When Citrix ingress controller was configuring existing alternate backend routes on OpenShift during boot-up, an error keyError: 'weighted_abpol' may occur. Now, it is fixed.

Release 1.20.5

Version 1.20.5

What's New

Traffic management for external services

Sometimes, the available services of an application may be deployed outside the Kubernetes cluster. In such cases, you need a way to resolve domain names for external services and require features such as traffic management. Now, you can configure Citrix ADC as the domain name resolver for external services and enable traffic management. For more information, see Traffic management for external services.

Enhancements

• You can now disable API certificate verification while communicating with the API server from Citrix ingress controller or multi-cluster ingress. For more information, see Disable API certificate verification.

Known issues

From Citrix ingress controller version 1.20.5, the support for adding domain name servers through ConfigMap is added for tier 1 Citrix ADC. However, the existing domain name server configuration on Citrix ADC VPX may get deleted if not specified as part of the ConfigMap. As a workaround, you should make sure that all the domain name servers that are expected in Citrix ADC VPX (including the domain names which are already present) are added to the ConfigMap by specifying the domain name server IP addresses. These domain name servers are automatically configured and managed by Citrix ingress controller.

Release 1.19.6

Version 1.19.6

What's New

Support for alternate backends for OpenShift routes

When an OpenShift route is supported by multiple services, alternate backends are used for specifying the additional services.
Alternate backends for OpenShift routes are now supported by Citrix ingress controller. Citrix ADC is configured according to the weights provided in the routes definition and traffic is distributed among the service pods based on those weights. For more information, see Alternate Backend Support.

Enhancements

• Now, Citrix ingress controller supports binding default certificates in OpenShift routes.
• The default value for the environment variable NS_PROTOCOL is now changed to HTTPS and the default value for NS_PORT is now changed to 443.
• Earlier, front-end profiles for TCP, HTTP, and SSL were supported but the profile must be specified as part of a separate ingress called the front-end ingress. With this enhancement, you can specify front-end profiles as part of the regular ingress. This enhancement also helps to handle any conflicts that can arise from different ingresses belonging to the same content switching virtual server in a pre-determined way. For more information, see Configure HTTP, TCP, or SSL profiles on Citrix ADC.
• Now, Citrix ingress controller supports configuring global level front-end profiles for TCP, HTTP, and SSL using ConfigMap variables. Three new variables, FRONTEND_TCP_PROFILE, FRONTEND_HTTP_PROFILE, and FRONTEND_SSL_PROFILE, are added which can be used to set the front-end TCP, HTTP, and SSL profiles. For more information, see Configure HTTP, TCP, or SSL profiles on Citrix ADC.

Fixed issues

• In OpenShift routes, the targetPort field in the route represents the port of the pod. However, Citrix ingress controller was treating targtePort as a service port similar to the way it treats ingress. Hence, Citrix ingress controller was unable to handle destination services where targetPort is different from the service port. This issue is fixed now.

Release 1.18.5

Version 1.18.5

What's New

HTTP callout using rewrite and responder CRD

An HTTP callout allows Citrix ADCs to generate and send an HTTP or HTTPS request to an external server as part of the policy evaluation and take the appropriate action based on the response obtained from the external server. Now, you can use the rewrite and responder CRD to initiate HTTP callout requests from a Citrix ADC.
For more information, see the HTTP callout documentation.

Kubernetes version 1.22 support

Citrix ingress controller now supports Kubernetes version 1.22. With Kubernetes version 1.22, support for some of the older API versions are removed. For detailed information on the changes, see the Kubernetes documentation.
Citrix ingress controller deployment YAMLs and Helm charts are updated in this release to support these changes.

Enhancements

Earlier, for WAF CRD spec.application_type attribute can be of type string or array. Now, only type array is supported. If WAF CRD is used, make sure that this attribute is used with the attribute type as array. The WAF policy will fail if the spec.application_type attribute is used as string and not changed to array.

Release 1.17.13

Version 1.17.13

What's New

Configure cross-origin resource sharing policies

Cross-origin resource sharing (CORS) is a mechanism allows a web application running under one domain to securely access resources in another domain. You can configure CORS policies on Citrix ADC using Citrix ingress controller to allow one domain (the origin domain) to call APIs in another domain. For more information, see the cross-origin resource sharing CRD documentation.

Analytics support with GitOps

Web insight based analytics is now supported with GitOps (API Gateway CRD).
When you use GitOps, the following web insight parameters httpurl, httpuseragent, httphost, httpmethod, and httpcontenttype are enabled by default. For more information, see the Deploy API Gateway with GitOps documentation.

Ingress class support for CRDs

For CRDs, the ingress class feature is now supported. Earlier, Citrix CRD instances are applied by all instances of Citrix ingress controllers within a Kubernetes cluster. Now, you can optionally specify the ingress class using the spec.ingressclass field. When the ingress class is specified, only the Citrix ingress controller instance which is started with the given ingress class using the --ingress-classes argument processes the CRD resource. If the ingress class is not specified, then the earlier behavior persists.

DNS resolution on Citrix ADC

Now, you can configure Citrix ADC as a DNS server to resolve host names specified in the Ingress using Citrix ingress controller. A new environment variable NS_CONFIG_DNS_REC is introduced which can be configured as an argument to Citrix ingress controller.

For more information, see deploy Citrix ingress controller.

Logging support with rate limit CRD

You can now enable logging for observability with the rate limit CRD. For more information, see the rate limit CRD documentation.

Added support for protection against SQL injection using the grammar pattern

Now, protection against SQL injection using the grammar pattern is added to WAF CRD. For more information, see the WAF CRD documentation.

Fixed issues

• When Citrix ingress controller is restarted, CRD bindings for a load balancing virtual server created by content routing CRD was lost. This issue is fixed now.

• Earlier, https monitoring was not working when specified in a global traffic policy (GTP). This issue is fixed now.

• A backup content switching virtual server binding was lost in some scenarios when the traffic-policy deployment type is failover. This issue is fixed now.

• Earlier, the monitor configuration was not getting deleted when the GTP was deleted. This issue is fixed now.

• Earlier, multiple ingresses were not supported with WAF and bot CRDs. This issue is fixed now.

• When a service of type load balancer was processed but not configured due to any error and a delete event of that service was received, Citrix ingress controller was crashing. This issue is fixed now.

• Earlier, when the HTTPRoute back-end is used in the Ingress and redirect option is enabled, it worked only for the first host name. This issue is fixed now.

• Earlier, Citrix ingress controller modifies the SNIEnable and ClientAuth fields of a preconfigured SSL profile depending on the certificate binding. Now, Citrix ingress controller is excluded from modifying the preconfigured SSL profile.

• Sometimes, there is inconsistency in service group members of the Listener CRD back-end if the replica goes to zero. This issue is fixed.