You can now power your Kubernetes platform by auto-deploying policy configurations for redirect and rewrite features like redirecting HTTP traffic, blocking URLs, or responding to a request that requires policy evaluation. To perform this kind of evaluation, the appliance requires you to add the appropriate libraries in a microservice or to manually configure the policies.
A simple solution is to use the Kubernetes Custom Resource Definition (CRD) for deploying rewrite and responder policies in an Ingress Citrix ADC appliance.
To ease your deployment and to extend the Kubernetes API, you can use a Kubernetes CRD template, which defines your objects and lets the API server handle the entire lifecycle. Deploying a CRD into the cluster causes the Kubernetes API server to begin serving the specified custom resource.
A CRD template contains a list of attributes that you can use for defining a responder or rewrite policy, datasets, patsets, audit logging, and string maps. Each CRD attribute is mapped to Citrix ADC rewrite or responder policy and its attributes. This way, you don’t have to configure the feature on the ADC appliance manually and instead can automate the configuration and deployment of these policies on the Ingress Citrix ADCs.
Consider a scenario where you want to rewrite all URLs for an application. You must first deploy the rewrite and responder CRD in the Kubernetes cluster. You then create a YAML file called rewrite-policy.yaml, which has the appropriate CRD attributes to define the rewrite policy configuration. Once you deploy the rewrite-policy.yaml file in the Kubernetes cluster, you’ll find that the Citrix Ingress Controller (CIC) applies the policy configuration on the Ingress Citrix ADC device.
By doing this, any update or modification you want to make to the policy configuration can be made in the YAML file instead of modifying the rewrite policy on the appliance. Also, you can add multiple policy configurations to a single YAML file and apply all the configurations to the Citrix ADC appliance.
Adding or Modifying a Rewrite or Responder Configuration in a CRD
To modify or write a responder policy for blocking access to a specific URL using CRD:
- Deploy microservices in Kubernetes cluster.
- Deploy Citrix ADC as an Ingress appliance.
- Deploy the CRD YAML file in a Kubernetes cluster.
- Define the responder policy configuration in the .yaml file (e.g. responder-block-URL-acess.yaml) and deploy it.
- The CIC applies the responder policy configuration on the Ingress Citrix ADC device.
- All ingress traffic for a specified URL will be blocked from Ingress Citrix ADC LB virtual server.
To write a rewrite policy for inserting the HTTP header in an HTTP response using CRD:
- Deploy microservices in Kubernetes cluster.
- Deploy Citrix ADC as an Ingress appliance.
- Deploy the CRD YAML file in a Kubernetes cluster.
- Define the rewrite policy configuration in .yaml file (e.g. rewrite-insert-header.yaml) and deploy it.
- The CIC applies the rewrite policy configuration on the Ingress Citrix ADC device.
- The Ingress Citrix ADC LB virtual server will insert the header in egress HTTP traffic.
By now, you probably understand how CRDs are used in Kubernetes for responder and rewrite policy deployment. Now, let’s look at how a CRD is different from the aggregate APIs that were used.
Comparing CRDs to Aggregated APIs
We recommend Kubernetes CRD over Kubernetes annotation. Annotation enables you to add a new key-value pair entity into the existing Kubernetes objects. For example, in the case of Prometheus, prometheus.io/port: “9102”, annotation defines the port HTTP request to make. But CRD enables users to add their own/custom objects to the Kubernetes cluster. For example, the Rewrite and Responder CRD Citrix provides is designed to expose a set of tools used in frontline Citrix ADCs to rewrite the header and payload of ingress and egress HTTP traffic, as well as respond to HTTP traffic on behalf of a microservice.
Deploying Rewrite/Responder Configuration as a CRD in Kubernetes
To learn how to deploy your rewrite or responder configuration using CRD in Kubernetes, see the end-to-end microservice two-tier deployment topic.
What’s Next
CRD extensions for rewrite and responder policies are a great start. We can make them more robust by adding more custom resources for other policy configurations such as HTTP callout and rate limiting policy so you’re able to store and retrieve structured data for policies configured on a Citrix ADC appliance.
Click here to read our series on Citrix’s cloud-native solutions for Kubernetes admins, DevOps, developers, and SREs.
Citrix Tech Bytes – Created by Citrix experts, made for Citrix technologists! Learn from passionate Citrix experts and gain technical insights into the latest Citrix technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
