In my previous post, we learned about Istio Gateway, virtual service resources, Citrix Istio Adaptor, and how you can deploy the various form factors of Citrix ADC as an Ingress Gateway in the Istio service mesh. Here, we’ll look at what goes into configuring Citrix ADC Ingress Gateway for various applications.
Now you know how to deploy resources to enable Citrix ADC to act as Ingress Gateway. But for each application that needs to be exposed via Ingress Gateway device, you must create Gateway and VirtualService resources in the application namespace. VirtualService should mention the relevant Gateway resource name in “gateways” field, and Gateway should mention “app: citrix-ingressgateway” in the selector field so that Citrix ADC is configured as expected.
You can deploy either HTTP-based application or a TCP based one. In either case, you can configure Ingress Gateway to expose the application to end user traffic. And this application can be exposed in both secure and regular fashion. In other words, Citrix ADC can expose an HTTP-based application using HTTP and/or HTTPS and a TCP-based application using TCP and/or SSL-TCP.
Configuring Gateway for HTTP Applications
As an example, we’ll expose bookinfo through Citrix ADC as an Istio Ingress Gateway. We’ll look at how to create a secure (HTTPS) and an insecure (HTTP) ingress gateway. You’ll need Gateway and VirtualService to expose an application. The YAML file snippets you’ll need to expose the bookinfo application via Citrix ADC are below.
Gateway
This YAML file exposes both HTTP and HTTPS endpoints of the bookinfo application in the same file. You can split these into separate files.
# Source: bookinfo-citrix-ingress/templates/bookinfo_https_gateway.YAML
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: bookinfo-gateway
spec:
selector:
app: citrix-ingressgateway
servers:
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- "www.bookinfo.com"
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "www.bookinfo.com"VirtualService
But Gateway alone isn’t sufficient; it works in tandem with the VirtualService. The Citrix ADC is configured to expose the bookinfo application only after the Gateway and VirtualService are created.
VirtualService provides a way to configure traffic management inside the service mesh, including request routing, traffic shifting, and fault injection.
The YAML file below creates a VirtualService and associates it with the ‘bookinfo-gateway’ created earlier. Here the traffic destined to www.bookinfo.com, ‘http[s]://vserverIP/productpage’, or ‘http[s]://vserverIP’ will go to the productpage service. Productpage is the front-end service of the bookinfo application.
# Source: bookinfo-citrix-ingress/templates/productpage_vs.YAML
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- "www.bookinfo.com"
gateways:
- bookinfo-gateway
http:
- match:
- uri:
exact: /productpage
- uri:
prefix: /
route:
- destination:
host: productpageIn addition to Gateway and VirtualService resources, you can add the Destination Rule resource for finer control over traffic management in the mesh. You can do this by applying policies such as the LB algorithm, session affinity, max connections, or others before sending traffic to the final destination service.
Configuring Secure Gateway for Multiple Hosts
The example above shows how to create a gateway for traffic destined to ports 80 and 443 of the bookinfo application URL www.bookinfo.com.
You can expose multiple applications deployed in the same cluster using server name indication (SNI) support on Citrix ADC. In this case, you should create a separate gateway for each application. Also, you should redeploy the Istio Ingress Gateway service with the certificates of each application.
Assume that you’ve deployed one more application — ‘httpbin’ — in addition to the bookinfo application in the service mesh, and it will be accessed using the URL httpbin.example.com. This httpbin application can also be exposed using port 443 of the same vserverIP of Citrix ADC. In such a case, Citrix ADC looks at the indicated hostname in SSL ‘Client Hello’ during the handshake and returns the appropriate certificate to the caller. Once this SSL handshake is successfully completed, the request is forwarded to the appropriate back-end service.
Click here for more detail on configuring gateways for multiple hosts.
Configuring Gateways for TCP Applications
So far we’ve looked at ways to expose HTTP-based applications. We can also expose TCP-based applications in a secure and an insecure fashion. For our purposes here, you’ll need to assume that a tcp-echo server is deployed on port 9000 in the Istio service mesh.
TCP-based Ingress Gateway
The YAML file below has Gateway and VirtualService resources for exposing the tcp-echo server running inside the service mesh. Here, Citrix ADC will receive requests on tcp port 8000, then forward these requests to the tcp-echo server on port 9000.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tcp-echo-gateway
spec:
selector:
istio: ns-ingressgateway
servers:
- port:
name: tcp-echo
number: 8000
protocol: TCP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tcp-echo
spec:
hosts:
- "*"
gateways:
- tcp-echo-gateway
tcp:
- match:
- port: 8000
route:
- destination:
host: tcp-echo
port:
number: 9000TLS-based Ingress Gateway
To expose a TCP-based application in a secure fashion, you should specify the protocol as ‘TLS’, and the server certificate and private key must be provided to the Ingress Gateway. Citrix ADC will do the TLS termination of the incoming request. If the TLS is disabled in service mesh, then Citrix ADC will forward the request over the insecure TCP connection to the backend service. If TLS is enabled, the request will be forwarded over the secure TCP channel.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tcp-echo-gateway
spec:
selector:
istio: ns-ingressgateway
servers:
- port:
name: tcp-echo
number: 8000
protocol: TLS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ing-certs/tls.crt
privateKey: /etc/istio/ing-certs/tls.key
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: tcp-echo
spec:
hosts:
- "*"
gateways:
- tcp-echo-gateway
tcp:
- match:
- port: 8000
route:
- destination:
host: tcp-echo
port:
number: 9000Other Features Supported on Citrix ADC
Citrix ADC is a versatile application delivery controller that can support a variety of other features while acting as an Istio Ingress Gateway. These include:
- Load balancing
- Secure Ingress
- Weighted clusters
- HTTP Rewrite
- HTTP Redirect
- HTTP Fault Injection
- mTLS
- Authentication Policy (End-user authentication or origin authentication using JWT Auth; transport authentication or service-to-service authentication using mutual TLS)
You can learn more these capabilities here.
In a Nutshell
We’ve covered configuring Gateway for HTTP applications, as well as configuring secure Gateway for multiple hosts. So what happens when a request arrives from outside the cluster on a Citrix ADC Ingress Device? Here’s how the different resources interact:
- A client sends a request on a port that’s exposed on the Ingress Gateway Device. If it is a Citrix ADC MPX or VPX device, the request will be sent on the vserverIP and port mentioned in the Ingress Gateway Service. If it is a Citrix ADC CPX, the request will be sent on the Kubernetes cluster’s any node’s IP (master or worker doesn’t matter), and the nodePort mentioned in the Ingress Gateway Service.
- Citrix ADC will forward the request to one of the worker nodes on the Kubernetes Service Port (i.e. the port mentioned in the Gateway Service) .
- This service forwards the request to an application pod on a port mentioned in VirtualService.
- The response follows the same path in reverse fashion.
Learn More
You can find Helm charts and a script to generate deployment YAML files from template-YAMLs on the Citrix Istio Adaptor github page. There you’ll find detailed steps (and quick steps, too) for deploying Citrix ADC as an Ingress Gateway, as well as a sample Helm chart for deploying the bookinfo application and exposing it using Citrix ADC.
Give the deployment of Citrix ADC in Istio service mesh a try. If you run into an issues, reach out in the discussion forum or Slack channel that are linked on the Citrix Istio Adaptor github page.
