Original source: containerjournal.com (August 2019)
Overview
Citrix announced that its Application Delivery Controllers (ADC) have been validated to run on Red Hat OpenShift, the enterprise Kubernetes platform. As part of the alignment, Red Hat also certified the Citrix Operator—software designed to simplify the deployment and lifecycle management of Citrix ADC instances on OpenShift clusters.
What Is a Citrix ADC and Why Does It Matter for Kubernetes?
An Application Delivery Controller sits between clients and application servers, handling far more than a basic load balancer. A typical ADC provides:
- Layer 4–7 load balancing – distributing traffic intelligently across services
- Web Application Firewall (WAF) – filtering malicious requests before they reach application code
- SSL/TLS offload – terminating encrypted connections at the ADC to reduce backend compute overhead
- Server health monitoring – detecting and routing around unhealthy instances
- Service graphs – visualising the topology and health of microservice dependencies
In a Kubernetes environment, these capabilities complement—and in some cases replace—lighter-weight alternatives such as the Envoy proxy or a standalone Istio service mesh.
Red Hat OpenShift Joins AWS EKS, GKE, and AKS
According to Pankaj Gupta, Senior Director for Product Marketing for Networking at Citrix, Red Hat OpenShift joins Amazon EKS, Google GKE, and Microsoft AKS as validated Kubernetes platforms for Citrix ADC. The addition of OpenShift is strategically significant because OpenShift can be deployed both on-premises and in public clouds, making it a foundation for hybrid and multi-cloud ADC federation—a single, consistent ADC policy spanning data-centre racks and cloud VPCs.
The Role of the Citrix Operator
The Operator pattern—originally defined as a framework by CoreOS (later acquired by Red Hat, which was subsequently acquired by IBM)—packages operational knowledge about a piece of software into a Kubernetes controller. Citrix’s certified Operator automates day-1 and day-2 tasks for ADC instances running on OpenShift, including initial deployment, configuration updates, and scaling, without requiring manual intervention via the ADC management CLI.
Deployment Form Factors
Citrix ADC is available in multiple deployment form factors, giving teams flexibility to match the ADC to their infrastructure:
- CPX – containerised ADC, runs as a sidecar or standalone pod inside Kubernetes
- VPX – virtual machine appliance, deployable on hypervisors or cloud instances
- BLX – software ADC running directly on bare-metal Linux
- MPX / SDX – dedicated hardware appliances for high-throughput data-centre use
Organisations that already own MPX or SDX hardware can extend those assets to front Kubernetes workloads rather than replacing them, reducing capital expenditure during a cloud-native migration.
Integration with the Cloud-Native Observability Ecosystem
Citrix ADC integrates with a range of open-source observability and delivery tooling commonly used in cloud-native stacks, including:
- Prometheus & Grafana – metrics collection and dashboarding
- Spinnaker – continuous delivery pipelines
- Fluentd & Kibana – log aggregation and visualisation
- OpenTracing & Zipkin – distributed request tracing
Citrix Service Graph provides end-to-end visibility across microservice transactions, helping teams track the health of individual services as container versions are updated.
ADCs vs. Service Meshes: A Different Architectural Argument
Gupta’s position is that tools like Envoy-based proxies or Kubernetes-native service meshes such as Istio address only part of the problem: they operate entirely within the Kubernetes boundary and offer no continuity with the existing ADC estate that already handles monolithic application traffic.
Citrix’s argument is that extending ADCs—rather than introducing a parallel proxy layer—enables a single management console to cover both legacy monolithic applications and modern microservices. This matters in practice because most enterprises are not rewriting their entire application portfolio at once. Applications are modernised incrementally: isolated processes are gradually extracted as microservices while the monolithic core continues to run. A unified ADC platform can serve both without requiring separate operational toolchains.
Gupta also signalled that service mesh capabilities are expected to converge into larger ADC platforms over time—positioning ADCs as the long-term unifying layer for application traffic management regardless of deployment model.
Key Takeaways for DevOps and Platform Engineers
- Citrix ADC is now validated on Red Hat OpenShift, making hybrid-cloud ADC deployment more practical for OpenShift users.
- The certified Citrix Operator reduces Day-2 operational overhead when managing ADC instances in Kubernetes.
- Multiple form factors (CPX, VPX, BLX, MPX/SDX) mean existing hardware investments do not need to be abandoned.
- Deep integrations with Prometheus, Grafana, Spinnaker, Fluentd, OpenTracing, and Zipkin align ADC observability with standard cloud-native tooling.
- The ADC-vs-service-mesh debate is not necessarily binary; Citrix’s roadmap hints at service mesh capabilities being absorbed into the ADC platform.
This article is based on reporting originally published by Container Journal in August 2019.