Skip to content
  • 1.6.1
  • 516943c
  • Compare
    Choose a tag to compare
    Search for a tag
  • 1.6.1
  • 516943c
  • Compare
    Choose a tag to compare
    Search for a tag

@sreejithgs sreejithgs released this Dec 19, 2019 · 78 commits to master since this release

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.

Assets 2
  • 1.5.25
  • 03dd1fe
  • Compare
    Choose a tag to compare
    Search for a tag
  • 1.5.25
  • 03dd1fe
  • Compare
    Choose a tag to compare
    Search for a tag

@nirmalkn nirmalkn released this Nov 7, 2019 · 118 commits to master since this release

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.

Assets 2
  • 1.4.392
  • 1d47a8f
  • Compare
    Choose a tag to compare
    Search for a tag
  • 1.4.392
  • 1d47a8f
  • Compare
    Choose a tag to compare
    Search for a tag

@nirmalkn nirmalkn released this Oct 9, 2019 · 162 commits to master since this release

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.

Assets 2

@nirmalkn nirmalkn released this Sep 26, 2019 · 174 commits to master since this release

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

@chiradeep chiradeep released this Aug 26, 2019 · 219 commits to master since this release

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.

Assets 2
You can’t perform that action at this time.