NetScaler® ingress controller

Deploy NetScaler Kubernetes Ingress Controller as an OpenShift router plug-in

February 4, 2026

Contributed by:

In an OpenShift cluster, external clients need a way to access services. OpenShift provides the following two resources for communicating with services running in the cluster:

Routes
Ingress

A route exposes the services on a given domain name or associates a domain name with the services. OpenShift routers route external requests to services inside the cluster according to the rules specified in routes. When using the OpenShift router, you must configure external DNS so that the traffic lands on the OpenShift router.

The NetScaler Ingress Controller can be deployed as a router plug-in to integrate with NetScaler deployed in your environment. This deployment enables using advanced load balancing and traffic management capabilities of NetScaler with OpenShift.

Supported route types

OpenShift routes can be secured or unsecured. Secured routes specify the TLS termination of the route.

The NetScaler Ingress Controller supports the following OpenShift routes:

Unsecured Routes: For Unsecured routes, HTTP traffic is not encrypted.
Edge Termination: For edge termination, TLS is terminated at the router. Traffic from the router to the endpoints over the internal network is not encrypted.
Passthrough Termination: With passthrough termination, the router is not involved in TLS offloading and encrypted traffic is sent straight to the destination.
Re-encryption Termination: In re-encryption termination, the router terminates the TLS connection but then establishes another TLS connection to the endpoint.

For detailed information on routes, see the OpenShift documentation.

Deployment options

You can deploy either an appliance outside the OpenShift cluster (NetScaler MPX or VPX) or NetScaler CPX pods inside the cluster. The NetScaler Ingress Controller integrates the NetScaler with OpenShift and configures it automatically from route rules.

Two deployment modes for the router plug-in:

Sidecar: Run NetScaler Ingress Controller as a sidecar container alongside NetScaler CPX in the same pod — the ingress configures the CPX.
Standalone pod: Run NetScaler Ingress Controller standalone to control a NetScaler MPX or VPX appliance outside the cluster.

For information on controlling OpenShift ingress with the NetScaler Ingress Controller, see the Kubernetes deployment instructions.

You can use NetScaler to load-balance the OpenShift control plane (master nodes). NetScaler provides Terraform-based automation for configuring NetScaler. See NetScaler as a load balancer for the OpenShift control plane.

Alternate backend support

OpenShift alternate backends are supported by NetScaler Ingress Controller. The NetScaler is configured according to weights in the route definition and traffic is distributed among service pods based on those weights.

Example route manifest with alternate backends:

kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: r1
  labels:
    name: apache
  annotations:
    route.citrix.com/frontend-ip: "<Frontend-ip>"
spec:
  host: some.alternate-backends.com
  to:
    kind: Service
    name: apache-1
    weight: 30
  alternateBackends:
    - kind: Service
      name: apache-2
      weight: 20
    - kind: Service
      name: apache-3
      weight: 50
  port:
    targetPort: 80
  wildcardPolicy: None
<!--NeedCopy-->

For this route: 30% of traffic goes to apache-1, 20% to apache-2, and 50% to apache-3.

Supported Citrix components on OpenShift

Citrix components	Versions
NetScaler Ingress Controller	Latest
NetScaler VPX	12.1 50.x and later
NetScaler CPX	13.0–36.28 and later

Note:

CRDs provided for the NetScaler Ingress Controller are not supported for OpenShift routes. Use OpenShift ingress to use CRDs.

Example

The following example deploys NetScaler Ingress Controller as a router plug-in to load-balance an application.

Deploy a sample application (apache.yaml) and expose it:

oc create -f https://raw.githubusercontent.com/citrix/citrix-k8s-ingress-controller/master/deployment/openshift/manifest/apache.yaml
<!--NeedCopy-->

Note:

Apache pods might fail on OpenShift because they often run as root or bind to port 80. As a workaround, add the pod’s default service account to privileged SCC and add anyuid:

oc adm policy add-scc-to-user privileged system:serviceaccount:default:default oc adm policy add-scc-to-group anyuid system:authenticated

The content of the apache.yaml file is given as follows:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: apache-only-http
  name: apache-only-http
spec:
  replicas: 4
  selector:
    matchLabels:
      app: apache-only-http
  template:
    metadata:
      labels:
        app: apache-only-http
    spec:
      containers:
      - image: quay.io/sample-apps/apache:1.0.0
        imagePullPolicy: IfNotPresent
        name: apache-only-http
        ports:
        - containerPort: 80
          protocol: TCP
        - containerPort: 5080
          protocol: TCP
        - containerPort: 5081
          protocol: TCP
        - containerPort: 5082
          protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    name: apache-only-ssl
  name: apache-only-ssl
spec:
  replicas: 4
  selector:
    matchLabels:
      app: apache-only-ssl
  template:
    metadata:
      labels:
        app: apache-only-ssl
    spec:
      containers:
      - image: quay.io/sample-apps/apache:1.0.0
        imagePullPolicy: IfNotPresent
        name: apache-only-ssl
        ports:
        - containerPort: 443
          protocol: TCP
        - containerPort: 5443
          protocol: TCP
        - containerPort: 5444
          protocol: TCP
        - containerPort: 5445
          protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
  name: svc-apache-multi-http
spec:
  ports:
  - name: apache-http-6080
    port: 6080
    targetPort: 5080
  - name: apache-http-6081
    port: 6081
    targetPort: 5081
  - name: apache-http-6082
    port: 6082
    targetPort: 5082
  selector:
    app: apache-only-http
---
apiVersion: v1
kind: Service
metadata:
  name: svc-apache-multi-ssl
spec:
  ports:
  - name: apache-ssl-6443
    port: 6443
    targetPort: 5443
  - name: apache-ssl-6444
    port: 6444
    targetPort: 5444
  - name: apache-ssl-6445
    port: 6445
    targetPort: 5445
  selector:
    app: apache-only-ssl
---
<!--NeedCopy-->

Deploy the NetScaler Ingress Controller for NetScaler VPX as a stand-alone pod in the OpenShift cluster using the steps in Deploy the NetScaler Ingress Controller as a pod.

Note:

To deploy the NetScaler Ingress Controller with NetScaler CPX in the OpenShift cluster, perform the steps in Deploy the NetScaler Ingress Controller as a sidecar with NetScaler CPX.

Create an OpenShift route for exposing the application. The options are:

For creating an unsecured OpenShift route unsecured-route.yaml`, use the following command:

apiVersion: v1 
kind: Route 
metadata: 
  name: unsecured-route 
spec: 
  host: unsecured-route.openshift.citrix-cic.com 
  path: "/" 
  to: 
    kind: Service 
    name: svc-apache-multi-http
<!--NeedCopy-->

oc create -f unsecured-route.yaml 
<!--NeedCopy-->

For creating a secured OpenShift route with edge termination secured-edge-route.yaml, use the following command:

apiVersion: v1 
kind: Route 
metadata: 
  name: secured-edge-route 
spec: 
  host: secured-edge-route.openshift.citrix-cic.com 
  path: "/" 
  to: 
    kind: Service 
    name: svc-apache-multi-http 
  tls: 
    termination: edge 
        
    key: |-                       
      ----BEGIN RSA PRIVATE KEY----- 
                  
          [...] 
              
      -----END RSA PRIVATE KEY----- 
        
    certificate: |-               
      -----BEGIN CERTIFICATE----- 
          [...] 
      -----END CERTIFICATE-----
  <!--NeedCopy-->

  oc create -f secured-route-edge.yaml 
  <!--NeedCopy-->

For creating a secured OpenShift route with passthrough termination secured-passthrough-route.yaml, use the following command:

apiVersion: v1 
kind: Route 
metadata: 
  name: secured-passthrough-route 
spec: 
  host: secured-passthrough-route.openshift.citrix-cic.com 
  to: 
    kind: Service 
    name: svc-apache-multi-ssl 
  tls: 
    termination: passthrough
<!--NeedCopy-->

oc create -f secured-passthrough-route.yaml
<!--NeedCopy-->

For creating a secured OpenShift route with re-encryption termination secured-reencrypt-route.yaml, use the following command:

apiVersion: v1 
kind: Route 
metadata: 
  name: secured-reencrypt-route 
spec: 
  host: secured-reencrypt-route.openshift.citrix-cic.com 
  path: "/" 
  to: 
    kind: Service 
    name: svc-apache-multi-ssl 
  tls: 
    termination: reencrypt 
        
    key: |-                       
      -----BEGIN RSA PRIVATE KEY----- 
            [...] 
      -----END RSA PRIVATE KEY----- 
        
    certificate: |-               
      -----BEGIN CERTIFICATE----- 
            [...] 
      -----END CERTIFICATE----- 
            
    destinationCACertificate: |-             
      -----BEGIN CERTIFICATE----- 
            [...] 
      -----END CERTIFICATE----- 
  <!--NeedCopy-->

  oc create -f secured-reencrypt-route.yaml
  <!--NeedCopy-->

Note:

For a secured OpenShift route with passthrough termination, you must include the default certificate.

Access the application using the following command.

curl http://<VIP of NetScaler VPX>/ -H 'Host: < host-name-as-per-the-host-configuration-in-route >' 
<!--NeedCopy-->

The official version of this content is in English. Some of the Cloud Software Group documentation content is machine translated for your convenience only. Cloud Software Group has no control over machine-translated content, which may contain errors, inaccuracies or unsuitable language. No warranty of any kind, either expressed or implied, is made as to the accuracy, reliability, suitability, or correctness of any translations made from the English original into any other language, or that your Cloud Software Group product or service conforms to any machine translated content, and any warranty provided under the applicable end user license agreement or terms of service, or any other agreement with Cloud Software Group, that the product or service conforms with any documentation shall not apply to the extent that such documentation has been machine translated. Cloud Software Group will not be held responsible for any damage or issues that may arise from using machine-translated content.

Was this helpful

NetScaler Secure Deployment Guide

Deploy NetScaler Kubernetes Ingress Controller as an OpenShift router plug-in

February 4, 2026

Contributed by:

February 4, 2026

Contributed by:

Deploy NetScaler Kubernetes Ingress Controller as an OpenShift router plug-in

Supported route types

Deployment options

Alternate backend support

Supported Citrix components on OpenShift

Example

In this article