This is the third installment in our series on Citrix’s cloud-native solutions for Kubernetes admins, DevOps, Developers and SREs (read part 1 and part 2). Here, we’ll describe Citrix’s enterprise-grade Ingress solution, which allows you to manage and route end-user traffic destined for a Kubernetes cluster. The 15+ years of application delivery performance is now available for your cloud-native application environments hosted inside the Kubernetes cluster, providing the same level of performance that drives business for your customers and your users.
This solution is composed of two core components — Citrix ADC and Citrix Ingress Controller. Citrix ADC in various form factors including hardware, multi-tenant, virtualized, containerized, and bare-metal, acts as an Ingress resource, and Citrix Ingress Controller dynamically configures the Citrix ADC (Ingress resource) according to policies defined by you.
Earlier in this series, we examined various ways to bring end user traffic inside a Kubernetes cluster such as NodePort, LoadBalancer, and Ingress, and why Ingress is recommended. Now that we’ve covered the basics, let’s dive deep into our Ingress solution.
Start with the Right Deployment Topology for Ingress
We typically see two ways of deploying Ingress solutions — single or dual Ingress (read more about these topologies here). “Single,” or Unified Ingress, is a simple architecture used to perform traffic management functions like Load Balancing, TLS termination, and HTTP/TCP protocol optimizations on inbound traffic before routing it to the correct microservice within a Kubernetes cluster, as shown in figure 1. This architecture is best suited where the same team manages the Kubernetes platform and other networking infrastructure including application delivery controllers (ADCs).
Figure 1
The Dual Ingress Approach, or Two-Tiered Ingress, as shown in figure 2, is more suited for organizations where different teams manage the Kubernetes platform and other networking infrastructure. Kubernetes platform teams use Tier 2 Citrix ADC (CPX) for Layer 7 (HTTP/HTTPS) load balancing, mutual TLS, and observability/monitoring of microservices. CPX is a containerized form factor of the Citrix ADC and, like any other container, it runs on a Kubernetes pod. Networking/IT teams use Tier 1 Citrix ADC for traditional use cases such as GSLB, TLS termination on hardware platform, and TCP load balancing.
This two-tiered architecture offers the best of both worlds: high velocity of application development for developers using Tier 2 ADC and high performance, secure traffic management for networking teams using Tier 1 ADC.
Figure 2
Basics for a Kubernetes Ingress Solution – L4-L7 Traffic Management Features
Citrix Ingress Controller (CIC) is designed to bring battle-tested L4-L7 traffic management features of Citrix ADC to the Kubernetes environment. While it is extensively documented on GitHub documentation, here are the key highlights that you expect in any production-grade Ingress solution.
- Setup basic Citrix ADC configurations, such as virtual IP address, using annotations
- Configure load balancing methods, route based on request content (URL, HTTP headers), and monitor applications using Nitro annotations
- Apply advanced policies to manage HTTP/TCP protocol using CRDs (CustomResourceDefinition) such as Rewrite and Responder CRD
- Enable TLS termination by certificates and key management from Kubernetes cluster or pre-configured certkeys on Citrix ADC
Makings of a Production-Grade Ingress Solution
Citrix’s Ingress solution solves several pain points that enterprises face when moving their production traffic to Kubernetes. Below are common requirements heard from stakeholders managing critical production traffic:
- TCP/UDP Ingress – Enterprises want to expose to production traffic TCP/UDP-based applications including databases such as MongoDB, MySQL; message buses such as Kafka; caches such as Redis, Memcache; or other legacy apps based on RPC/SOAP. This support is missing from most Ingress solutions in the Kubernetes ecosystem. Citrix ADC provides TCP, TCP-SSL, and UDP Ingress solutions in addition to standard HTTP/HTTPS ingress. For example, the following YAML snippet exposes a Redis cluster to Ingress traffic.
- CRD first approach – Citrix Ingress Controller exposes key Citrix ADC features through CRD (CustomResourceDefinitions) rather than annotations. Both are valid, but CRDs are recommended as annotations tend to become clunky if you want to specify more metadata such as key:value information to Ingress resources. We’ve observed that production-level Ingress rules are a complex way to manage various policies you want to apply to inbound traffic. CRDs helps to create, maintain, and modify policies such as rewrite request/response, Web Application Firewall, Authentication, Mutual TLS, and more. For example, you may want to append an X-Forwarded-For header in incoming HTTP request to pass on information to backend microservices. The below CRD is an elegant way to achieve this. Managing the same policies using Annotations could lead to errors. See more examples about CRDs on Citrix Ingress Controller’s GitHub page.
- Multi tenancy – You want to provide separate Ingress solutions to manage inbound traffic to different applications owned by different teams. Using admin partitions and multiple ingress classes, you can create logical separation for different teams on the same Citrix ADC instance. For example, Team A and Team B can use the same Ingress device and can have completely different Ingress rules without interfering with each other. The first code snippet declares Ingress classes for each team in the same Citrix Ingress Controller, while the second code snippet shows how Team A can use their ingress class meant for them. See more details in our GitHub documentation.
- Integrations with other cloud native technologies – Any production-grade Ingress solution needs to talk to various monitoring, logging, and tracing tools to monitor, diagnose, and troubleshoot microservices. Citrix’s Ingress solution exports data to Prometheus, Grafana, EFK (Elasticsearch, Fluentd, Kibana), Zipkin, and OpenTracing, with more such integrations in the pipeline. This means that Citrix’s Ingress solution can easily fit into most popular cloud-native technology stacks used by enterprises. These integrations are extensive, and we’ll cover them in future blog posts highlighting the value addition to individual cloud-native technologies. This example shows various metrics that Citrix Ingress Controller exports to Prometheus and Grafana.
This was an introduction to our Ingress solutions composed of the familiar Citrix ADC and Citrix Ingress Controller. We’ll continue to cover our cloud-native solutions in upcoming posts. Please share your feedback and questions in the comments below.
