Product Documentation
NetScaler ingress controller
View PDF

Unified ingress

July 19, 2024
Contributed by: 
C C

The Unified ingress deployment is used to perform load balancing of North-South traffic. North-South traffic is the traffic that enters or exits Kubernetes cluster, that is, the traffic that flows between the client and the front-end microservices. In this deployment, NetScaler Ingress Controller automates the configuration of NetScaler, which load balances traffic to microservices in the Kubernetes environment. NetScaler Ingress Controller runs as a pod that monitors the Kubernetes API server and configures NetScaler MPX or NetScaler VPX.

Deploy NetScaler Ingress Controller as a standalone pod in the Kubernetes cluster

Use the netscaler-ingress-controller Helm chart to deploy NetScaler Ingress Controller as a pod in your Kubernetes cluster.

The installation involves NetScaler Ingress Controller pod creation, cluster role creation, cluster role bindings, and service account creation.

When you deploy NSIC using the Helm chart, you can use a values.yaml file to specify the values of the configurable parameters instead of providing each parameter as an argument.

Note:

NSIC can also work with RBAC roles.

Prerequisites

  • Determine the NS_IP (NetScaler IP) address using which NetScaler Ingress Controller communicates with NetScaler. The IP address might be any one of the following IP addresses depending on the type of NetScaler deployment:

    • NSIP (for standalone appliances) - The management IP address of a standalone NetScaler appliance. For more information, see IP Addressing in NetScaler.

    • SNIP (for appliances in High Availability mode) - The subnet IP address. For more information, see IP Addressing in NetScaler.

    • CLIP (for appliances in Cluster mode) - The cluster management IP (CLIP) address for a cluster NetScaler deployment. For more information, see IP addressing for a cluster.

  • The user name and password of a system user account of NetScaler MPX or NetScaler VPX used as the Ingress device. NetScaler needs to have a system user account (non-default) with certain privileges so that the NetScaler Ingress Controller can configure NetScaler MPX or NetScaler VPX. For instructions to create the system user account on NetScaler, see Create System User Account for NetScaler Ingress Controller in NetScaler.

    You can directly pass the user name and password or use Kubernetes secrets. If you want to use Kubernetes secrets, create a secret for the user name and password using the following command:

     kubectl create secret  generic nslogin --from-literal=username=<username> --from-literal=password=<password>

  • Version 1.21 and later in the Kubernetes environment.

  • Version 4.8 and later in the OpenShift platform.

  • Ensure that you have installed Helm version 3.x or later. To install Helm, see here.

Create a system user account for NetScaler Ingress Controller in NetScaler

NetScaler Ingress Controller configures NetScaler using a system user account of NetScaler. The system user account should have certain privileges so that NetScaler Ingress Controller has permission to configure the following on NetScaler:

  • Add, delete, or view content switching (CS) virtual server
  • Configure CS policies and actions
  • Configure Load Balancing (LB) virtual server
  • Configure service groups
  • Configure SSL certkeys
  • Configure routes
  • Configure user monitors
  • Add system file (for uploading SSL certkeys from Kubernetes)
  • Configure virtual IP address (VIP)
  • Check the status of the NetScaler appliance

To create the system user account, perform the following:

  1. Log on to NetScaler. Perform the following steps:

    1. Use an SSH client, such as PuTTy, to open an SSH connection to NetScaler.

    2. Log on to NetScaler using the administrator credentials.

  2. Create the system user account using the following command:

    add system user <username> <password>

    For example:

    add system user cic mypassword

  3. Create a policy to provide required permissions to the system user account. Use the following command:

    add cmdpolicy cic-policy ALLOW '^(\?!shell)(\?!sftp)(\?!scp)(\?!batch)(\?!source)(\?!.*superuser)(\?!.*nsroot)(\?!install)(\?!show\s+system\s+(user|cmdPolicy|file))(\?!(set|add|rm|create|export|kill)\s+system)(\?!(unbind|bind)\s+system\s+(user|group))(\?!diff\s+ns\s+config)(\?!(set|unset|add|rm|bind|unbind|switch)\s+ns\s+partition).*|(^install\s*(wi|wf))|(^\S+\s+system\s+file)^(\?!shell)(\?!sftp)(\?!scp)(\?!batch)(\?!source)(\?!.*superuser)(\?!.*nsroot)(\?!install)(\?!show\s+system\s+(user|cmdPolicy|file))(\?!(set|add|rm|create|export|kill)\s+system)(\?!(unbind|bind)\s+system\s+(user|group))(\?!diff\s+ns\s+config)(\?!(set|unset|add|rm|bind|unbind|switch)\s+ns\s+partition).*|(^install\s*(wi|wf))|(^\S+\s+system\s+file)'

    Note:

    The system user account has privileges based on the command policy that you define.

    The command policy mentioned in step 3 is similar to the built-in sysAdmin command policy with additional permission to upload files.

    In the command policy specification provided, special characters which need to be escaped are already omitted to easily copy-paste into the NetScaler command line.

    For configuring the command policy from NetScaler configuration wizard (GUI), use the following command policy specification.

    ^(?!shell)(?!sftp)(?!scp)(?!batch)(?!source)(?!.*superuser)(?!.*nsroot)(?!install)(?!show\s+system\s+(user|cmdPolicy|file))(?!(set|add|rm|create|export|kill)\s+system)(?!(unbind|bind)\s+system\s+(user|group))(?!diff\s+ns\s+config)(?!(set|unset|add|rm|bind|unbind|switch)\s+ns\s+partition).*|(^install\s*(wi|wf))|(^\S+\s+system\s+file)^(?!shell)(?!sftp)(?!scp)(?!batch)(?!source)(?!.*superuser)(?!.*nsroot)(?!install)(?!show\s+system\s+(user|cmdPolicy|file))(?!(set|add|rm|create|export|kill)\s+system)(?!(unbind|bind)\s+system\s+(user|group))(?!diff\s+ns\s+config)(?!(set|unset|add|rm|bind|unbind|switch)\s+ns\s+partition).*|(^install\s*(wi|wf))|(^\S+\s+system\s+file)

  4. Bind the policy to the system user account using the following command:

    bind system user cic cic-policy 0

Deploy NetScaler Ingress Controller as a standalone pod in the Kubernetes cluster

To deploy NetScaler Ingress Controller as a standalone pod:

  1. Add the NetScaler Helm chart repository to your local registry using the following command.

    helm repo add netscaler https://netscaler.github.io/netscaler-helm-charts/   
<!--NeedCopy-->

  2. Install NetScaler CPX with NetScaler Ingress Controller using the following command.

    helm install nsic netscaler/netscaler-ingress-controller --set nsIP=<NSIP>,license.accept=yes,adcCredentialSecret=<Secret-for-NetScaler-credentials>
<!--NeedCopy-->

Note:

You can also use a values.yaml file in the helm install command to specify the values of the configurable parameters instead of providing each parameter as a command-line argument. For example, helm install nsic netscaler/netscaler-ingress-controller -f values.yaml.

For information about the mandatory and optional parameters that you can configure during NSIC installation, see Configuration.

Warning:

Do not create NSIC pod replicas in the Kubernetes cluster. When you create replicas of an NSIC pod by specifying replicatset>1, an unexpected behavior is observed with NSIC/VPX because the same APP_PREFIX is shared among the NSIC PODs and each instance tries to configure the same resources.

Route addition in NetScaler MPX or NetScaler VPX

For seamless functioning of services deployed in the Kubernetes cluster, NetScaler should be able to reach the underlying overlay network over which the pods are running. The feature-node-watch argument of NetScaler Ingress Controller can be used for automatic route configuration on NetScaler towards the pod network. Refer to Static Routing for more information. By default, feature-node-watch is set to false; set to true to enable automatic route configuration.

If your deployment uses a single NetScaler to load balance between multiple k8s clusters, there is a possibility of CNI subnets to overlap, causing the static routing to fail due to route conflicts. In such deployments, Policy Based Routing (PBR) can be used. PBR requires you to provide one or more subnet IP addresses unique for each kubernetes cluster either using an environment variable or ConfigMap, see PBR Support.

Use the following command to provide subnet IP addresses (SNIPs) to configure Policy Based Routes (PBR) on NetScaler.

helm install my-release netscaler/netscaler-ingress-controller --set nsIP=<NSIP>,license.accept=yes,adcCredentialSecret=<Secret-for-NetScaler-credentials>,nsSNIPS='[<NS_SNIP1>\, <NS_SNIP2>\, ...]'
<!--NeedCopy-->

Note:

PBR can also be achieved by deploying NetScaler Node Controller. Netscaler Node Controller, by default, adds static routes while creating the VXLAN tunnel. To use Policy Based Routing (PBR) to avoid static route clash, both NetScaler Node Controller and NetScaler Ingress Controller have to work in conjunction and have to be started with specific arguments. For more information, refer Configure PBR using the NetScaler node controller.

Use the nsncPbr=<True/False> parameter in the helm install command of NSIC to inform NSIC that NetScaler Node Controller is configuring Policy Based Routes (PBR) on NetScaler.

helm install my-release netscaler/netscaler-ingress-controller --set nsIP=<NSIP>,license.accept=yes,adcCredentialSecret=<Secret-for-NetScaler-credentials>,clusterName=<unique-cluster-identifier>,nsncPbr=<True/False>
<!--NeedCopy-->
Unified ingress
July 19, 2024
Contributed by: 
C C
July 19, 2024
Contributed by: 
C C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.