Release 1.9.2

Version 1.9.2

What's New

Multi-cluster ingress and load balancing solution using the Citrix ingress controller

Citrix provides a multi-cluster ingress and load balancing solution which globally monitors applications, collect, and share metrics across different clusters, and provides intelligent load balancing decisions. It ensures better performance and reliability for your Kubernetes services that are exposed using Ingress or using type LoadBalancer.

For more information, see Multi-cluster ingress and load balancing solution using the Citrix ingress controller.

Configuring web application firewall policies with the Citrix ingress controller

Now, you can configure the web application firewall policies with the Citrix ingress controller on the Citrix ADC using the WAF CRD. The WAF CRD enables communication between the Citrix ingress controller and Citrix ADC for enforcing web application firewall policies in a Kubernetes environment.

For more information, see Configuring web application firewall policies with the Citrix ingress controller

Support for cookie based persistence configuration using ConfigMap

You can now enable cookie based persistence configuration using ConfigMap.
For more information, see ConfigMap support for the Citrix ingress controller.

Authorization policy support

The Citrix ingress controller now supports configuring authorization policies on Citrix ADCs using the Citrix Auth CRD.
For more information, see Define authentication policies on the Ingress Citrix ADC.

Fixed issues

• Earlier, when a service type is changed from ClusterIP or NodePort to LoadBalancer, the IP address was not allocated by the Citrix IPAM controller for the service of type LoadBalancer. Now, the IP address is allocated to the service of type LoadBalancer when you change the type of service. You can change the service type using the kubectl patch command.

• Automatic static route configuration of the associated Ingress device using the feature-node-watch argument was not supported in OpenShift deployments. Now, automatic static route configuration is supported.

• Earlier, the Citrix ingress controller was failing for endpoints which do not have information about backing pods while using LoadBalancer type of services. With this fix, the Citrix ingress controller handles endpoints with no backing pod information correctly.

Release 1.8.28

Version 1.8.28

This release is a bug fix only release and there are no new features included in this release.

Fixed issues

• Service group member bindings were not getting configured due to the loss of Kubernetes endpoint events during the Citrix ingress controller boot up. With this fix, service group members are correctly configured without any event loss.

• When the rewrite and responder CRD is applied on a service with multiple ports, rewrite rules were applied on only one of the load balancing virtual servers. With this fix, rewrite rules are applied on all load balancing virtual servers representing a given service.

Release 1.8.19

Version 1.8.19

What's New

Direct Server Return deployment mode support

Now, the Citrix ingress controller supports Citrix ADC deployment in Direct Server Return (DSR) mode.
In a DSR deployment the load balancer forwards the client request to the server, but the back-end server directly sends the response to the client. Using a DSR deployment, you can improve response time between the client and the server and also reduce some extra load from the load balancer.

For more information, see Deploy Direct Server Return.

TCP profile support for services of type LoadBalancer

A TCP profile is a collection of TCP settings. Instead of configuring the settings on each entity, you can configure TCP settings in a profile and bind the profile to all the required entities. Now, you can apply TCP profiles for services of type LoadBalancer.

For more information, see TCP profile support for services of type LoadBalancer.

TLS server authentication support

Server authentication allows a client to verify the authenticity of the web server that it is accessing. Usually, the Citrix ADC device performs SSL offload and acceleration on behalf of a web server and does not authenticate the certificate of the web server. However, you can authenticate the server in deployments that require end-to-end SSL encryption.

For more information, see TLS server authentication support in Citrix ADC using the Citrix ingress controller.

oAuth introspection support

The Citrix ingress controller now supports oAuth introspection. Using this feature, Citrix ADC can check the validity of access tokens, and find out other information such as which user and which scopes are associated with the token.

For more information, see Define authentication policies on the Ingress Citrix ADC.

GoTo Priority Expression support

Earlier, when you bind multiple policies to a service and the ongoing policy evaluation turns True, the other rewrite policies were not evaluated.
The go-to-priority expression feature allows the evaluation of multiple policies within the RewritePolicy CRD, even when the ongoing policy evaluation turns True.

For more information, see Use Rewrite and Responder policies in Kubernetes.

Automated deployment of applications in Service mesh lite

When you want to deploy multiple applications that consist of several microservices in a Service Mesh lite architecture, you may need an easier way you deploy your services. Citrix provides you an automated way to generate ready to deploy YAMLs out of your application YAMLs for Service Mesh lite deployment.

For more information, see Automated deployment of applications in Service Mesh lite
.

Anthos platform support

Anthos is a hybrid and multi-cloud platform that lets you run your applications on existing on-prem hardware or in the public cloud. It provides a consistent development and operation experience for cloud and on-premises environments.

The Citrix ingress controller can be deployed in Anthos GKE on-premises. For more information, see Deploy the Citrix ingress controller in Anthos.

Support for Citrix observability exporter configuration using ConfigMap

You can now enable Citrix observability exporter configuration using ConfigMap.

For more information, see Support for Citrix observability exporter configuration using ConfigMap.

Updating the Ingress status for the Ingress resources with the specified IP address

You can now update the Status.LoadBalancer.Ingress field of the Ingress resources managed by the Citrix ingress controller with the allocated IP addresses by specifying the command line argument --update-ingress-status yes when you start the Citrix ingress controller. This feature is only supported for the Citrix ingress controller deployed as a stand-alone pod for managing Citrix ADC VPX or MPX. For Citrix ADC CPXs deployed as sidecars, this feature is not supported.

For more information, see Updating the Ingress status for the Ingress resources with the specified IP address.

Release 1.7.46

Version 1.7.46

What's New

Support for volume mount to pass the Citrix ADC credentials

The Citrix ingress controller supports using Kubernetes secrets to store the Citrix ADC credentials. You can now use a secret volume mount to pass the credentials to the Citrix ingress controller.

For more information, see How to use Kubernetes secrets for storing Citrix ADC credentials.

Support for Citrix ADC certificate validation in the Citrix ingress controller

The Citrix ingress controller now supports validating the SSL server certificate provided by the Citrix ADC. You can ensure secure communication between the Citrix ingress controller and Citrix ADC by using the HTTPS protocol. But, this option is introduced as an extra security measure to avoid any possible man-in-the-middle (MITM) attack.

For more information, see Enable Citrix ADC certificate validation in the Citrix ingress controller.

Support for troubleshooting the Citrix ingress controller during runtime

This feature introduces support for debugging the Citrix ingress controller based on events and logs.
For more information, see Troubleshooting the Citrix ingress controller during runtime.

Content routing CRD

Kubernetes native Ingress offers basic host and path-based routing. But, other advanced routing techniques like routing based on header values or query strings are not supported in the Ingress structure. Using content routing CRDs, you can expose the advanced content routing abilities provided by Citrix ADC as a custom resource definition (CRD) API for Kubernetes.

For more information, see Advanced content routing for Kubernetes with Citrix ADC.

Enhancement: Secure credential management with the Citrix ingress controller

Earlier, when the credentials of Citrix ADC (VPX, MPX, or CPX) are not provided in the deployment YAML for the Citrix ingress controller, nsroot/nsroot is considered as the default user name and password. Now, it is mandatory to pass credentials while deploying the Citrix ingress controller.

Release 1.7.6

What's New

SSL passthrough

SSL passthrough feature allows you to pass incoming security sockets layer (SSL) requests directly to a server for decryption rather than decrypting the request using a load balancer. SSL passthrough is widely used for web application security and it uses the TCP mode to pass encrypted data to servers.

For more information, see Configure SSL passthrough using Kubernetes Ingress.

ConfigMap support in the Citrix ingress controller

Using ConfigMaps, you can easily change and manage your workload configurations and reduce the need to hardcode configuration data to pod specifications. The Citrix ingress controller now supports ConfigMaps. ConfigMaps allow you to update the Citrix ingress controller configuration while keeping the Citrix ingress controller pod running without restarting the pod.

For more information, see ConfigMap support in the Citrix ingress controller.

TLS client authentication support in Citrix ADC

In TLS client authentication, a server requests a valid certificate from the client for authentication and ensures that it is only accessible by authorized machines and users. Now, you can enable TLS client authentication support in the Ingress Citrix ADC using the Citrix ingress controller.

For more information, see TLS client authentication support in Citrix ADC.

Enhancements for Kubernetes service of type LoadBalancer support in the Citrix ingress controller

Route health injection (RHI) allows the Citrix ADC to advertise the availability of a virtual IP address (VIP) as a host route throughout the network using BGP. However, you had to manually perform the configuration on Citrix ADC to support RHI.

With this enhancement:

• You can automate the configuration on Citrix ADCs to advertise VIPs using Citrix ingress controllers deployed in a Kubernetes environment.
• Advertise and recall VIPs based on the availability of application pods in a zone.

For more information, see Enhancements for Kubernetes service of type LoadBalancer support in the Citrix ingress controller.

Canary support in Citrix ADC

Canary release is a technique to reduce the risk of introducing a new software version in production by first rolling out the change to a small subset of users. After the user validation, the application is rolled out to the larger set of users. Citrix ADC Integrated Canary Deployment Solution stitches together all components of continuous delivery (CD) and makes canary deployment easier for the application developers.

For more information, see Deploy Citrix ADC-Integrated Canary Deployment Solution.

Fixed issues

In previous versions, 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.
This issue is fixed in Citrix ADC CPX release version 13.0-47.103.

Release 1.6.1

What's new

Deploy the Citrix ingress controller for a namespace

By default, the Citrix ingress controller monitors Ingress resources across all namespaces in the Kubernetes cluster. Now, you can deploy a Role-based Citrix ingress controller to monitor only ingress resources belongs to a specific namespace. In this deployment, the Citrix ingress controller listens only for events from the specified namespace and then configures the Citrix ADC accordingly.

For more information, see Deploy the Citrix ingress controller for a namespace.

OAuth authentication support

Using the Auth CRD with the Citrix ingress controller, you can define authentication policies on the ingress Citrix ADC. The Auth CRD now supports OAuth authentication.
For more information, see Define authentication policies on the Ingress Citrix ADC.

Support for linking a certificate chain on the Citrix ADC

A certificate chain is an ordered list of certificates which contains an SSL certificate and certificate authority (CA) certificates. It enables the receiver to verify that the sender and CAs are trustworthy. The chain or path begins with the SSL certificate, and each certificate in the chain is signed by the entity identified by the next certificate in the chain.
Now, you can install and link a certificate chain on the Citrix ADC using the Citrix Ingress controller.

For more information, see Install, link, and update certificates on a Citrix ADC using the Citrix ingress controller.

Release 1.5.25

What's new

Support for using Citrix ADC credentials stored in a Vault server

If your Citrix ADC ingress devices and Kubernetes clusters are managed by different teams, you may not want to include the Citrix ADC credentials in the Citrix ingress controller specification. In such situations, you can now pass Citrix ADC credentials stored in a Vault server to the Citrix ingress controller during the start up to minimize any security risk. For more information, see Use Citrix ADC credentials stored in Vault server.

Fixed issues

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.

General issues:

• If there is a time change in Citrix ADC CPX, the Citrix ingress controller incorrectly reports the Citrix ADC CPX as rebooted.

• The Citrix ingress controller throws exception with a key error for service YAML definitions that does not include port information.

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.

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