NetScaler ingress controller

Deployment topologies

NetScalers can be combined in powerful and flexible topologies that complement organizational boundaries. Dual-tier deployments employ high-capacity hardware or virtualized NetScalers (NetScaler MPX and VPX) in the first tier to offload security functions and implement relatively static organizational policies while segmenting control between network operators and Kubernetes operators.

In Dual-tier deployments, the second tier is within the Kubernetes Cluster (using the NetScaler CPX) and is under control of the service owners. This setup provides stability for network operators, while allowing Kubernetes users to implement high-velocity changes. Single-tier topologies are suited to organizations that need to handle high rates of change.

Single-Tier topology

In a Single-Tier topology, NetScaler MPX or VPX devices proxy the (North-South) traffic from the clients to microservices inside the cluster. The NetScaler Ingress Controller is deployed as a standalone pod in the Kubernetes cluster. The controller automates the configuration of NetScalers (MPX or VPX) based on the changes to the microservices or the Ingress resources.


Dual-Tier topology

In Dual-Tier topology, NetScaler MPX or VPX devices in Tier-1 proxy the traffic (North-South) from the client to NetScaler CPXs in Tier-2. The Tier-2 NetScaler CPX then routes the traffic to the microservices in the Kubernetes cluster. The NetScaler Ingress Controller deployed as a standalone pod configures the Tier-1 devices. And, the sidecar controller in one or more NetScaler CPX pods configures the associated NetScaler CPX in the same pod.


Cloud topology

Kubernetes clusters in public clouds such as Amazon Web Services (AWS), Google Cloud, and Microsoft Azure can use their native load balancing services such as, AWS Elastic Load Balancing, Google Cloud Load Balancing, and Microsoft Azure NLB as the first (relatively static) tier of load balancing to a second tier of NetScaler CPX. NetScaler CPX operates inside the Kubernetes cluster with the sidecar Ingress controller. The Kubernetes clusters can be self-hosted or managed by the cloud provider (for example, AWS EKS, Google GKE and Azure AKS) while using the NetScaler CPX as the Ingress. If the cloud-based Kubernetes cluster is self-hosted or self-managed, the NetScaler VPX can be used as the first tier in a Dual-tier topology.

Cloud deployment with NetScaler (VPX) in tier-1: Cloud deployment with VPX in tier-1

Cloud deployment with Cloud LB in tier-1: Cloud deployment with CLB in tier-1

Service mesh lite

An Ingress solution (either hardware or virtualized or containerized) typically performs L7 proxy functions for north-south (N-S) traffic. The Service Mesh lite architecture uses the same Ingress solution to manage east-west traffic as well.

In a standard Kubernetes deployment, east-west (E-W) traffic traverses the built-in KubeProxy deployed in each node. Kube-proxy being a L4 proxy can only do TCP/UDP based load balancing without the benefits of L7 proxy.

NetScaler (MPX, VPX, or CPX) can provide such benefits for E-W traffic such as:

  • Mutual TLS or SSL offload
  • Content based routing, allow or block traffic based on HTTP or HTTPS header parameters
  • Advanced load balancing algorithms (for example, least connections, least response time and so on.)
  • Observability of east-west traffic through measuring golden signals (errors, latencies, saturation, or traffic volume). NetScaler ADM Service Graph is an observability solution to monitor and debug microservices.

For more information, see Service mesh lite.


Services of type LoadBalancer

Services of type LoadBalancer in Kubernetes enables you to directly expose services to the outside world without using an ingress resource. It is made available only by cloud providers, who spin up their own native cloud load balancers and assign an external IP address through which the service is accessed. This helps you to deploy microservices easily and expose them outside the Kubernetes cluster.

By default, in a bare metal Kubernetes cluster, service of type LoadBalancer simply exposes NodePorts for the service. And, it does not configure external load balancers.

The NetScaler Ingress Controller supports the services of type LoadBalancer. You can create a service of type LoadBalancer and expose it using the ingress NetScaler in Tier-1. The ingress NetScaler provisions a load balancer for the service and an external IP address is assigned to the service. The NetScaler Ingress Controller allocates the IP address using the .

For more information, see Expose services of type LoadBalancer.

Service of type LoadBalancer

Services of type NodePort

By default, Kubernetes services are accessible using the cluster IP address. The cluster IP address is an internal IP address that can be accessed within the Kubernetes cluster. To make the service accessible from the outside of the Kubernetes cluster, you can create a service of the type NodePort.

The NetScaler Ingress Controller supports services of type NodePort. Using the Ingress NetScaler and NetScaler Ingress Controller, you can expose the service of type NodePort to the outside world.

For more information, see Expose services of type NodePort.

Services of type NodePort

Deployment using Helm charts and the NetScaler deployment builder

For deploying NetScaler cloud native topologies, there are various options available using YAML and Helm charts. Helm charts are one of the easiest ways for deployment in a Kubernetes environment. When you deploy using the Helm charts, you can use a values.yaml file to specify the values of the configurable parameters instead of providing each parameter as an argument.

You can generate the values.yaml file for NetScaler cloud native deployments using the NetScaler deployment builder, which is a GUI.

The following topologies are supported by the NetScaler deployment builder:

  • Single-Tier

    • Ingress

    • Service type LoadBalancer

  • Dual-Tier

    • NetScaler CPX as NodePort

    • NetScaler CPX as service of type LoadBalancer

  • Multi-cluster Ingress

  • Service mesh

For detailed information on how to use the NetScaler deployment builder, see the NetScaler deployment builder blog.

Deployment topologies