Release 1.4.392

What's new

Rate limiting support

Citrix provides a Kubernetes CustomResourceDefinition (CRD) called the Rate limit CRD. You can use the Rate limit CRD with the Citrix ingress controller to configure the rate limiting configurations on the Citrix ADCs used as Ingress devices. For more information, see Rate limiting in Kubernetes using Citrix ADC.

For more information on the rate limiting configuration provided by Citrix ADC, see Rate limiting.

Authentication policy support

Citrix provides a Kubernetes CustomResourceDefinition (CRD) called the Auth CRD that you can use with the Citrix ingress controller to define authentication policies on the Ingress Citrix ADC. For more information, see Define authentication policies on the Ingress Citrix ADC.

Ability to assign unique name to the IP address ranges configured on the IPAM controller

You can now assign a unique name to the IP address ranges configured on the IPAM controller. Assigning a unique names to the IP address ranges enables you to differentiate between the IP address ranges. When you create the services of type LoadBalancer you can use the service.citrix.com/ipam-range annotation in the service definition to specify the IP address range that you want to use for IP address allocation. For more information, see Expose services of type LoadBalancer with IP addresses assigned by the IPAM controller.

Integration with ExternalDNS providers

In the previous release, the IP address allocated by the IPAM controller is provided in the spec.externalIPs field in the service of type LoadBalancer definition.

From this release, the IP address allocated by the IPAM controller is provided in the status.loadBalancer.ingress: field in the service definition. This allows you to easily integrate with ExternalDNS providers such as Infoblox.

For more information, see Expose services of type LoadBalancer with IP addresses assigned by the IPAM controller.

Using built-in or existing user-defined profiles on the Ingress Citrix ADC

You can use the smart annotations provided for profiles to configure the built-in profiles or existing user-defined profiles on the Ingress Citrix ADC for the front end and back-end configurations based on your requirement. For more information, see Using built-in or existing user-defined profiles on the Ingress Citrix ADC.

Cipher groups support

The Ingress Citrix ADC ships with a predefined set of cipher groups. Using the annotations for SSL profiles, you can bind the predefined set of cipher groups or user-defined cipher groups to an SSL profile. For more information, see Using cipher groups.

Known issues

Red Hat OpenShift support:

• Automatic route configuration using the Citrix Ingress Controller (feature-node-watch) is not supported in OpenShift.

• When you frequently modify the OpenShift route configuration, the Citrix ingress controller might crash with the following SSL exception: SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC.

Rewrite and Responder policy CRD:

When you apply the rewrite policy CRD deployment file on the Kubernetes cluster, the Citrix ingress controller requires 12 seconds to process the CRD deployment file.

Service of type LoadBalancer:

• In the previous release, the Citrix ingress controller used the IP address allocated by the IPAM controller in the spec.externalIPs field in the service to configure as virtual IP address (VIP) on the Citrix ADC.

  From this release, it uses the IP address allocated by the IPAM controller in the status.loadBalancer.ingress: field of the service definition to configure as virtual IP address (VIP) on the Citrix ADC.

  After you upgrade to version 1.4.392, for the existing service of type LoadBalancer, instead of reconfiguring the IP address stored in the VIP CRD, the Citrix ingress controller requests the IPAM controller for a new IP address for the service.

• If you are using the service of type LoadBalancer with IPAM controller, when you restart the Citrix ingress controller, the Content Switching (CS) virtual server related configuration pertaining to the service is deleted from the Ingress Citrix ADC.

  Workaround: Ensure that you remove the service of type LoadBalancer before you restart the Citrix ingress controller and recreate the service after the Citrix ingress controller is restarted.

Other issues:

In the previous release, the Citrix ingress controller used direct names without a hash for configuring custom monitors on the Citrix ADC. From this release, Citrix ingress controller uses hash based configuration to configure the custom monitors. After you upgrade to 1.4.392, both direct name based configuration and the hash based configuration co-exist in the Citrix ADC.

For example, If you have configured custom monitor using the previous version of Citrix ingress controller, after the upgrade to 1.4.392, you can view two entries of the custom monitor in Citrix ADC. One entry is based on the direct name based configuration and other is based on the hash based configuration.

Release 1.3.0

What's new

Support for HTTP, TCP, or SSL profiles

HTTP, TCP, or SSL parameters for a Citrix ADC appliance can be
specified using entities known as profiles. A profile is a collection of settings pertaining to a protocol. For example, an HTTP profile is a collection of HTTP settings. Profiles offer ease of configuration and flexibility while applying common settings to multiple entities such as servers. Instead of configuring protocol settings on each entity, you can configure them in a profile and bind the profile to all required entities.

The Citrix ingress controller enables you to specify HTTP, TCP, or SSL related configurations on the Ingress Citrix ADC using profiles. For more information, see Configure HTTP, TCP, or SSL profiles.

Support for wildcard host names in Ingress and route

The Citrix ingress controller supports using host names with wildcards in Kubernetes Ingress and OpenShift Ingress or route. For more information, see Wildcard host routing.

Support for modifying an existing OpenShift route (feature enhancement)

With this enhancement, you can modify an existing OpenShift route and apply the updated route configuration using the oc apply command. In previous releases, modifying an existing OpenShift route was not supported.

Known issues

Red Hat OpenShift support:

• Automatic route configuration using the Citrix Ingress Controller (feature-node-watch) is not supported in OpenShift.

• When you frequently modify the OpenShift route configuration, the Citrix ingress controller might crash with the following SSL exception: SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC.

Rewrite policy CRD:

• When you apply the rewrite policy CRD deployment file on the Kubernetes cluster, the Citrix ingress controller requires 12 seconds to process the CRD deployment file.

Release 1.2.0

What's New

Expose services of type LoadBalancer

You can create a service of type LoadBalancer and expose it externally using the ingress Citrix ADC. You can manually assign an IP address to the service using the service.citrix.com/frontend-ip annotation. Else, you can also automatically assign IP address to service using the IPAM controller provided by Citrix. The Citrix ingress controller configures the assigned IP address as virtual IP (VIP) in the ingress Citrix ADC. And, the service is exposed using the IP address. For more information, see Expose services of type LoadBalancer.

RedHat OpenShift router sharding support

OpenShift router sharding allows distributing a set of routes among multiple OpenShift routers. By default, an OpenShift router selects all routes from all namespaces. In router sharding, labels are added to routes or namespaces and label selectors to routers for filtering routes. Each router shard selects only routes with specific labels that match its label selection parameters.

Citrix ADC supports OpenShift router sharding when you deploy it as an OpenShift router. For more information, see Deploy the Citrix ingress controller with OpenShift router sharding support.

Establish network connectivity between Kubernetes nodes and Ingress Citrix ADC using Citrix node controller

In Kubernetes environments, when you expose the services for external access through the Ingress device, to route the traffic into the cluster, you need to appropriately configure the network between the Kubernetes nodes and the Ingress device. Configuring the network is challenging as the pods use private IP addresses based on the CNI framework. Without proper network configuration, the Ingress device cannot access these private IP addresses. Also, manually configuring the network to ensure such reachability is cumbersome in Kubernetes environments.

Citrix provides a microservice called as Citrix k8s node controller that you can use to create the network between the cluster and the Ingress device. For more information, see Citrix node controller and Establish network between Kubernetes nodes and Ingress Citrix ADC using Citrix node controller.

Ability to match the ingress path

The Citrix ingress controller now provides an annotation ingress.citrix.com/path-match-method that you can use to define the Citrix ingress controller to consider the path string in the ingress path has prefix expression or as an exact match. For more information, see Annotations.

Ability to customize the prefix for Citrix ADC entities

By default, the Citrix ingress controller adds "k8s" as prefix to the Citrix ADC entities such as, content switching (CS) virtual server, load balancing (LB) virtual server and so on. You can now customize the prefix using the NS_APPS_NAME_PREFIX environment variable in the Citrix ingress controller deployment YAML file. You can use alphanumeric characters for the prefix and the prefix length should not exceed 8 characters.

Fixed issues

• Preconfigured certificates with "." in the certificate name is not supported. For example, hotdrink.cert.
• Citrix ingress controller fails to configure Citrix ADC if it is being deployed in standalone mode after rebooting Citrix ADC VPX.

Known issues

• Red Hat OpenShift support:

Automatic route configuration using the Citrix Ingress Controller (feature-node-watch) is not supported in OpenShift.
When you frequently modify the OpenShift route configuration, the Citrix ingress controller might crash with the following SSL exception: SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC.

After modifying the OpenShift route configuration, applying those changes using the oc apply command does not work.
Workaround: Delete the existing OpenShift route and recreate the route.

• Rewrite policy CRD:

When you apply the rewrite policy CRD deployment file on the Kubernetes cluster, Citrix ingress controller requires 12 seconds to process the CRD deployment file.