Citrix recently announced Istio support for the Citrix ADC portfolio. It was an exciting development because the integration can help you better secure, manage, and monitor your microservices traffic.
In this blog post, I’ll highlight how you can deploy Citrix ADC as an Istio Ingress Gateway.
Traditionally, an Ingress resource in a Kubernetes environment allows external traffic inside the cluster, and the Kubernetes Ingress resource provides basic L7 capabilities. Istio provides a superior gateway resource that, along with VirtualService, offer various L4 to L7 functionality. The Istio Gateway resource is used to configure L4-L6 functionalities such as, TLS certification, host and port exposure, type of protocol to use, SNI configuration, and more. The VirtualService resource is used to configure routing inside the service mesh. You can associate the gateway resource with the VirtualService and enable Istio to provide the same set of capabilities at the edge of the service mesh as well as inside the mesh.
Please note that Istio Gateway and Istio Ingress Gateway are different. Istio Ingress Gateway is a load balancer (such as Citrix ADC), which acts as a front-end proxy to the Istio service mesh. Istio Gateway is a resource to configure the Istio Ingress Gateway.
Deployment of Citrix ADC as an Ingress Gateway
Citrix ADC comes in various form factors — hardware-based (MPX), virtualized (VPX), and container-based (CPX). You can use traditional methods to deploy hardware-based and virtualized devices, but deployment of the container solution differs slightly. Let’s take a look at each:
Deploying Citrix ADC MPX or VPX as Istio Ingress Gateway
Before deploying Citrix ADC MPX/VPX as an Ingress Gateway, you need to establish connectivity between Citrix ADC and the Kubernetes cluster nodes. You can achieve this with a route-based configuration on Citrix ADC or by using the Citrix K8s Node Controller (CNC). This connectivity is required so the ADC can send packets to application pods inside the Kubernetes cluster. Citrix ADC also monitors application pods’ health status so requests go to healthy pods.
When Citrix ADC MPX/VPX is deployed as an Ingress Gateway device, the Istio-adaptor container primarily runs inside a pod managed by the Ingress Gateway deployment. Keep reading for more on the Istio-adaptor.
Deploying Citrix ADC CPX as Istio Ingress Gateway
When Citrix ADC CPX is deployed as Ingress Gateway, the CPX and Istio-adaptor both run as containers inside the Ingress Gateway Pod, as shown above.
Ingress Gateway Service
As part of our deployment, we need to create a Kubernetes service for Ingress Gateway. This service should listen to all necessary ports such as HTTP (80), HTTPS (443), as well as all other ports on which applications should be exposed.
The YAML files for the Ingress Gateway Service for MPX/VPX and CPX are below. The Citrix ADC CPX load balancer is exposed as a NodePort service. This is a port of the cluster node on which the Ingress Gateway pod will receive external traffic.
This yaml file will deploy Citrix ADC MPX/VPX as an Istio Ingress Gateway:
apiVersion: v1
kind: Service
metadata:
name: citrix-ingressgateway
annotations:
labels:
app: citrix-ingressgateway
spec:
selector:
app: citrix-ingressgateway
ports:
-
name: http2
port: 80
targetPort: 80
-
name: https
port: 443
targetPort: 443This yaml file will deploy Citrix ADC CPX as an Istio Ingress Gateway:
apiVersion: v1
kind: Service
metadata:
name: citrix-ingressgateway
annotations:
labels:
app: citrix-ingressgateway
spec:
type: LoadBalancer
selector:
app: citrix-ingressgateway
ports:
-
name: http2
nodePort: 30080
port: 80
targetPort: 80
-
name: https
nodePort: 30443
port: 443
targetPort: 443Ingress Gateway Deployment
The Ingress Gateway deployment is the most important aspect of the Citrix ADC Ingress Gateway. All the magic around the configuration of Citrix ADC happens inside a pod, which is managed by the Kubernetes deployment. The Ingress Gateway Pod, shown in Figures 1 and 2, is made up of a container called the Citrix Istio Adaptor, an open source software developed in Golang by Citrix. It automatically configures the Citrix ADC deployed for Istio service mesh. Let’s take a look at how it works.
Istio-adaptor
Components such as Istio Pilot, Citadel, Mixer, and more comprise the Istio control plane. Pilot is the control plane component that provides service discovery to proxies in the mesh. It’s essentially a gRPC xDS server, and it’s also responsible for configuring proxies at runtime.
Istio-adaptor is a gRPC client to the xDS server and receives xDS resources such as clusters, listeners, routes, and endpoints from the xDS server over a secure gRPC channel. After receiving these resources, the Istio-adaptor converts them to the equivalent Citrix ADC configuration blocks and configures the associated Citrix ADC using RESTful NITRO calls.
When a Gateway or VirtualService resource is created or updated, the Istio Pilot detects these changes. Istio-Pilot sends this information to the Istio-adaptor, which in turn configures the Citrix ADC device acting as an Ingress Gateway.
When an application is deployed in the cluster, its certificates and keys are stored in Kubernetes Secret. These application certificates are mounted in the Istio-adaptor from the Kubernetes Secret resource. The Istio-adaptor also monitors SSL/TLS certificates issued for applications and takes appropriate action when a change in certificate/key is done. It enables Citrix ADC to be vigilant and always provides secure access, if configured, to applications deployed in service mesh.
Please note, Kubernetes Secret must be created before deploying Gateway and Ingress Gateway. Also, you must create and mount in Istio-adaptor a secret with the credentials of the Citrix ADC MPX/VPX device. This enables the Istio-adaptor to securely configure Citrix ADC.
Istio-adaptor accepts the URL or IP address of the Citrix ADC device. In the case of Citrix ADC MPX/VPX, it also accepts the virtual server IP (vserverIP) that will be configured on Citrix ADC device. All the external traffic destined to the service mesh will be sent to this vserverIP.
In the snippet of the YAML file used for Ingress Gateway deployment, shown below, you can see arguments of the Istio-adaptor.
piVersion: apps/v1
kind: Deployment
metadata:
name: citrix-ingressgateway
labels:
app: citrix-ingressgateway
spec:
replicas: 1
selector:
matchLabels:
app: citrix-ingressgateway
template:
spec:
containers:
- name: istio-adaptor
image: quay.io/citrix/citrix-istio-adaptor:1.0.0
imagePullPolicy: Always
args:
- -pilot-location
- istio-pilot.istio-system:15011
- -proxy-type
- router
- -pilot-SAN
- spiffe://cluster.local/ns/istio-system/sa/istio-pilot-service-account
- -netscaler-url
- https://<ip>:port # In case of CPX, localhost is fine
- -vserver-ip
- <vserverIP> # Mention Vserver IP to be configured on Citrix ADC MPX/VPX
volumeMounts:
- mountPath: /etc/certs
name: istio-certs
readOnly: true
- mountPath: /etc/nslogin
name: nslogin
readOnly: true
- mountPath: /etc/istio/ingressgateway-certs # Make sure that Gateway definition has this path mentioned in server.tls section for SIMPLE TLS
name: citrix-ingressgateway-certs
readOnly: true
volumes:
- name: nslogin
secret:
optional: true
secretName: nslogin # Kubernetes Secret storing Citrix ADC MPX/VPX credentials
- name: istio-certs
secret:
optional: true
secretName: istio.default
- name: citrix-ingressgateway-certs
secret:
optional: true
secretName: "citrix-ingressgateway-certs" # IMPORTANT: This secret MUST BE created before deploying gateway and ingress-gatewayWhat’s Next?
In this post, I covered Istio resources, the difference between gateway and Ingress Gateway, the Citrix Istio Adaptor container, and how to deploy various form factors of Citrix ADC as an Ingress Gateway in the Istio service mesh. Learn more about Citrix ADC and Istio, and stay tuned for part two, where I’ll take a look at ways to configure Citrix ADC for various types of applications.
