GSLB Controller for datacenter resiliency across OpenShift clusters

To achieve high availability, proximity-based routing, and scalability for applications running across multiple geographically distributed Kubernetes clusters, traffic must be intelligently distributed between all active instances.

NetScaler simplifies this with its GSLB Controller, which automatically configures NetScaler GSLB appliances deployed in each region. One appliance operates as the primary ADC and others as secondary. The controller pushes configuration to the primary ADC, enabling seamless global load balancing for applications exposed through Ingress or LoadBalancer services. The configuration synchronizes between the primary and secondary appliances through GSLB sync mechanisms.

This multi-site GSLB setup ensures optimal performance, resilient failover, and consistent user experience regardless of where the request originates.

The NetScaler GSLB controller image is the same as that of NetScaler Ingress Controller, can be deployed through NetScaler Operator available on OpenShift platform or by using Helm Charts.

Understanding the Architecture

The architecture (refer Part 1 for architecture) consists of two OpenShift clusters (DC 1 and DC 2), each with:

 

1. OpenShift Container Platform running applications.
2. NetScaler Ingress Controller (NSIC) managing ingress rules.
3. GSLB Controller handling DNS-based traffic distribution.
4. IPAM Controller handling Ingress IP allocation.
5. NetScaler appliances acting as Tier-1 ingress points and synchronizing GSLB configuration.

Flow Explanation

1. GSLB Controller configures GSLB entities in the primary site (DC1)

• The GSLB Controller in DC1 creates:

o GSLB services

o GSLB virtual servers (GSLB vServers)

o Site definitions

• These represent each application’s endpoint across DC1 and DC2.

2. GSLB Config Is Synchronized Between Sites

• The two NetScaler ADC appliances exchange configuration using:

o MEP (Metric Exchange Protocol)

o GSLB Sync

• This ensures both ADCs have the same GSLB configuration and real-time health state of each GSLB service.

3. Client Performs DNS Query for Application FQDN

• A client (user) queries DNS for the app domain (e.g., bk.httpbin.com).

• Request reaches GSLB DNS on one of the ADCs (whichever serves the DNS zone).

4. GSLB Selects the Optimal Site Based on Policy

Based on configured policies such as:

• Proximity (based on client location)

• Load

• Health checks

• Static priority

GSLB returns the best site’s VIP IP address to the client.

Example:

If DC1 is healthier or closer → return DC1 VIP.

If DC1 is down → automatically return DC2 VIP.

5. Client Sends Application Traffic to the Ingress VIP

• Client connects directly to the selected site’s NetScaler Ingress VIP (North–South traffic).

• The ADC forwards traffic into the Kubernetes cluster via kube-proxy to the relevant pods.

• Application is served from the site chosen by GSLB.

Deployments Prerequisites:

1.        Install NetScaler GSLB Controller from OpenShift Operator Hub in the project/namespace created. It is OpenShift native way to deploy and manage NetScaler’s inside OpenShift environment.

2.        The required GSLB ports bidirectional communication must be open between both sites.

3.        While deploying GSLB controller from NetScaler Operator or Helm charts, consider updating the deployment parameters value in YAML –

				
					In DC1
acceptLicense: 'Yes'
  affinity: {}
  gslbController:
    disableAPIServerCertVerify: false
    entityPrefix: 'gslbred'
    image: 'quay.io/netscaler/netscaler-k8s-ingress-controller@sha256:41e21b8df2ecb0bfc22dfdf2324340d969308f69adf0adc9d3a61219eec7bdb3'
    kubernetesURL: ''
    localCluster: redstorm
    localRegion: 'singapore'
    logLevel: Debug
    openshift: true
    pullPolicy: IfNotPresent
    resources:
      limits: {}
      requests:
        cpu: 32m
        memory: 128Mi
    siteData:
      - secretName: 'nslogin'
        siteIp: '10.100.X.X'
        siteMask: '255.255.255.0'
        siteName: 'gslb_site_dc1'
        sitePublicIp: ''
        siteRegion: 'singapore'
      - secretName: 'nslogin'
        siteIp: '10.200.X.X'
        siteMask: '255.255.255.0'
        siteName: 'gslb_site_dc2'
        sitePublicIp: ''
        siteRegion: 'malaysia'
  imagePullSecrets: []
  netscaler:
    adcCredentialSecret: 'nslogin'
    nitroReadTimeout: 20
    nsIP: '10.100.X.X'
    nsPort: 443
    nsProtocol: HTTPS
  nodeSelector: {}
  podAnnotations: {}
  tokenExpirationSeconds: 31536000
  tolerations: []
  upgradeImageAlways: false

In DC2 – change the values highlighted in RED as per the cluster and site configuration details.
acceptLicense: 'Yes'
  affinity: {}
  gslbController:
    disableAPIServerCertVerify: false
    entityPrefix: 'gslbblue'
    image: 'quay.io/netscaler/netscaler-k8s-ingress-controller@sha256:41e21b8df2ecb0bfc22dfdf2324340d969308f69adf0adc9d3a61219eec7bdb3'
    kubernetesURL: ''
    localCluster: bluestorm
    localRegion: 'malaysia'
    logLevel: Debug
    openshift: true
    pullPolicy: IfNotPresent
    resources:
      limits: {}
      requests:
        cpu: 32m
        memory: 128Mi
    siteData:
      - secretName: 'nslogin'
        siteIp: '10.100.X.X'
        siteMask: '255.255.255.0'
        siteName: 'gslb_site_dc1'
        sitePublicIp: ''
        siteRegion: 'singapore'
      - secretName: 'nslogin'
        siteIp: '10.200.X.X'
        siteMask: '255.255.255.0'
        siteName: 'gslb_site_dc2'
        sitePublicIp: ''
        siteRegion: 'malaysia'
  imagePullSecrets: []
  netscaler:
    adcCredentialSecret: 'nslogin'
    nitroReadTimeout: 20
    nsIP: '10.200.X,X'
    nsPort: 443
    nsProtocol: HTTPS
  nodeSelector: {}
  podAnnotations: {}
  tokenExpirationSeconds: 31536000
  tolerations: []
  upgradeImageAlways: false