Kubernetes provides an ingress resource that enables content switching based on Hostname and URL Path attributes. There are many scenarios where the user needs to route to a service based on HTTP parameters other than Hostname and Path such as HTTP headers or cookies. Unfortunately, advanced routing techniques like routing based on header values or query strings are not supported in the ingress structure.
Citrix Ingress Controller provides content routing custom resource definitions (CRDs) through which you can expose your apps with content switching based on advanced techniques like routing based on Header or Query parameters. Content routing CRDs are a superset of the ingress resource and provide advanced routing in addition to what the ingress resource supports.
In this blog post, I will explain content routing CRDs and cover a sample use case.
Content-routing CRDs
Using content-routing CRDs, you can route traffic based on the following HTTP parameters:
- Hostname
- URL path
- HTTP headers
- Cookie
- Query parameters
- HTTP method
- Citrix ADC policy expression
The advanced content routing feature is exposed in Kubernetes with the following two CRDs:
Listener CRD — A Listener CRD object represents the endpoint information like virtual IP address, port, certificates, and other front-end configurations. It also defines default actions like sending default traffic to a back-end or redirecting the traffic. A Listener CRD object can refer to HTTPRoute CRD objects, which represents HTTP routing logic for the incoming HTTP request as shown in the diagram below.
HTTPRoute CRD — An HTTPRoute CRD object represents the HTTP routing logic for the incoming HTTP requests. You can use a combination of various HTTP parameters like host name, path, headers, query parameters, and cookies to route the incoming traffic to a back-end service. An HTTPRoute object can be attached to one or more Listener objects that represent the endpoint information. You can have one or more rules in an HTTPRoute object, with each rule specifying an action associated with it. The order of evaluation of the rules within an HTTPRoute object is same as the order mentioned in the object.
Query-Based Routing: An Example Deployment
Now that we’ve covered content routing CRDs, let’s look at a use case with query-based routing.
The query string component starts after the first “?” in the uniform resource identifier (URI) and is terminated by a number sign by the end of the URI, as shown below.
scheme://host:port/path?query_parameters#fragment
Typically query parameters contains a key value pair as shown in the example below.
https://example.com?key1=value1&key2=value2
Routing based in query parameters can be used for canary releases, A/B testing, and blue-green deployments.
Let’s go through a simple example to show how we can deploy content routing CRDs for query parameter-based routing for A/B testing. In this example, we are running a service — “hotdrinks” — that we have exposed the application on a domain “hotdrinks.beverages.com.” But now we have a new version of the application — “hotdrinks-v2” — and we want to do A/B testing by routing the traffic coming with specific query parameters as shown below.
https://hotdrinks.beverages.com?version=v2
By default, the data traffic to “hotdrinks.beverages.com” is expected to be served by the “hotdrinks” Kubernetes Service; but when “version=v2” query parameter is specified, it is expected to be served by “hotdrinks-v2” service, as shown here.
Please note, this blog post assumes you have deployed Citrix Ingress Controller with custom resource definitions installed. You can use the helm chart to install the Citrix Ingress Controller.
Step 1: Deploy Listener Custom Resource
A Listener custom resource configures the front-end parameters like IP address and certificates. It also must specify the HTTPRoute resources that are attached to the listener resource. As shown in the below spec, you can use LabelSelector to link all HTTPRoute resources with a given label to a Listener resource. In this example, Listener “beverages” will link all the HTTP resources with a label — “app: hotdrink.” You can also use the name and namespace of the HTTPRoute resource to link to a Listener resource.
Create a file Listener_resource.yaml with the following YAML content.
apiVersion: citrix.com/v1alpha1
kind: Listener
metadata:
annotations:
name: beverages
namespace: default
spec:
vip: "x.x.x.x"
protocol: https
certificates:
- secret:
name: my-secret
port: 443
routes:
- labelSelector:
app: hotdrinkDeploy the Listener custom resource:
Kubectl apply -f Listener_resource.yaml
Step 2: Deploy HTTPRoute Custom resource
This step involves deploying a HTTPRoute custom resource that will use query parameter-based routing to route the traffic to “hotdrink-v2” if the request contains a query parameter “version=v2.” All other traffic must be sent to the “hotdrink” app.
Create a file HTTPRoute_resource.yaml with following YAML content.
apiVersion: citrix.com/v1alpha1
kind: HTTPRoute
metadata:
name: hotdrink-route
namespace: default
labels:
app: hotdrink
spec:
hostname:
- hotdrink.beverages.com
rules:
- name: hotdrinks-v2
match:
- queryParams:
- name: version
exact: v2
action:
backend:
kube:
service: hotdrinks-v2
port: 80
- name: hotdrinks-v1
match:
- path:
prefix: /
action:
backend:
kube:
service: hotdrinks
port: 80Deploy HTTPRoute_Resource.yaml
This will configure the Citrix ADC to content switch the traffic to VIP based on the HTTP query parameter.
Learn More
You can achieve routing based on various HTTP parameters for apps deployed in Kubernetes clusters using content-routing CRDs with Citrix Ingress Controller and Citrix ADC, which isn’t possible with Kubernetes standard ingress resources. This supports use cases like A/B testing and canary deployments. You can also use these CRDs to route client traffic to different services based on the client form factors.
For more information about content routing CRDs, check out our product documentation. If there are features you’d like to see in Citrix Ingress Controller, please let us know in the comments below.
