Citrix ADC delivers operational consistency with a single code base across its various form factors: heavy appliances (MPX), virtualized (VPX), baremetal (BLX), and containerized (CPX). This means that all Citrix ADC appliances can provide the same feature set.

In the emerging world of service mesh, Citrix ADC CPXs are deployed next to every application unit (pods) to support the application. These containerized ADCs must be adapted yet again for this deployment scale by optimizing their size and performance. This blog post will cover some of the work we’ve done to enable Citrix ADC to perform well in multiple domains.

Service Mesh and Proxy

In the microservices world, east-west traffic in cloud-native apps accounts for the majority of traffic. It also has similar traffic routing, observability, and security needs as north-south traffic with traditional ADCs. By placing the proxy closer to the microservice, the service mesh ensures that east-west traffic can be automatically controlled without explicit action from the microservices developer.

In a sidecar deployment, one sidecar proxy is usually deployed per application pod to achieve the service mesh. Each proxy takes up memory, consumes CPU, incurs control plane overhead, and introduces an extra bit of latency. As the Kubernetes cluster scales to thousands of pods, the overhead increases. It’s important for the proxy to have a minuscule runtime-memory footprint while providing a rich set of features and maintaining low latency under demanding conditions.

A containerized proxy, Citrix ADC CPX is used in cloud-native deployments such as Kubernetes environments. By optimizing its memory footprint while maintaining the same code base, Citrix ADC CPX can be used as a sidecar proxy for service-mesh deployments. With this memory optimization, a single Kubernetes node can run thousands of sidecar CPX instances while delivering exceptionally low latency performance.

Memory Footprint of Citrix ADC CPX

The RAM usage of a single CPX instance includes all memory that the processes can access, including memory that is swapped out, memory that is allocated but not used, and memory from shared libraries. This is usually referred to as the Virtual Set Size (VSS).

But as more CPXs are spawned, much of the memory gets amortized over all the instances. To get the actual per-CPX memory footprint, we create a sufficiently large number of CPX instances on a node while maintaining the stability of the system. The memory swapping is disabled and then the per instance memory is measured as Total Memory usage of the node/Total proxy instances.

Because Citrix ADC has a single code base across all form factors, reducing the memory footprint for Citrix ADC CPX is a delicate engineering task. The reboot of a Citrix ADC (MPX/VPX) usually happens after couple of months. It serves multi-gigabit per second traffic and provides high sustained throughput. These appliances also need a wide variety of control interfaces — REST API, SNMP, SSH, and more. To cater to these use cases, we do some upfront memory allocations and use a lot of control daemons.

But, as an API-driven sidecar, the proxy is short-lived and rarely exceeds a few Mbps. Hence, the optimizations are done with the above proxy requirements in mind. For example:

  • Deferring the memory allocations to when the specific feature is enabled because a sidecar doesn’t require all the features
  • Scaling the hash tables and buffers allocated on bootup appropriately for a sidecar’s anticipated load
  • Reducing the startup costs not required in a microservices environment
  • Eliminating the daemons not required in a microservices environment
  • Changing the static allocations to dynamic, reducing the BSS portion of the data segment of the CPX process

Instantiating the Memory Optimized Mode of CPX

The deployment of CPX’s light mode is no different from deploying the regular CPX. Just use an additional env of NS_CPX_LITE=1 and you’ll instantiate the lighter version of CPX.

docker run ‒ dt -P –privileged=true -e NS_CPX_LITE=1  <image>:<tag>

Learn more about instantiating Citrix ADC CPX on our Product Documentation site.

Citrix ADC CPX Deployments

The memory-optimized mode of Citrix ADC CPX is appropriate for:

  • Ingress deployment: Citrix ADC CPX can be configured as a load balancer for the Kubernetes services. It is used to load balance the north-south traffic to your K8s services sent by clients outside the K8s cluster.
  • Sidecar deployment: Each pod contains Citrix ADC CPX as a sidecar, which can intercept all incoming and outgoing traffic of the app running in the pod. CPX can isolate the main app from all the auxiliary tasks while acting as a sidecar.

Citrix ADC CPX is designed to be a multifaceted proxy. Customers can use the same feature set across the data center, service mesh, and in the cloud while relying on the same code base forged by two decades of serving the world’s most innovative companies.

Keep an eye out for more Citrix cloud-native posts that will give you detailed views of various deployments of Citrix ADC CPX in service mesh. For more information on Citrix ADC as sidecar, check out the Citrix Github page.