Skip to main content
logoTetrate Global Load BalancerVersion: Latest

Testing Global Load Balancer

In this Chapter​

In this chapter, you'll learn how to:

  • Use dig to query the DNS names and interpret the results
  • Provoke a range of failure and recovery scenarios and observe the effects

Step 1: Test Normal Operation​

Test from the R_E_CLIENT resource group. You can expect the following response, which contains the active Edge Gateway IPs in region eastus (recall that in the RG_E_CLIENT resource group, the local.example.com Zone was linked from RG_E_DNS):

dig +noall +answer edge-internal.global.example.com

# edge-internal.global.example.com. 2 IN	CNAME	edge-internal.local.example.com.
# edge-internal.local.example.com. 2 IN	A	20.242.239.35
# edge-internal.local.example.com. 2 IN	A	20.232.235.7

Test from the R_C_CLIENT resource group. You can expect the following response, which contains the active Edge Gateway IPs in region centralus (recall that in the RG_C_CLIENT resource group, the local.example.com Zone was linked from RG_C_DNS):

dig +noall +answer edge-internal.global.example.com

# edge-internal.global.example.com. 2 IN	CNAME	edge-internal.local.example.com.
# edge-internal.local.example.com. 2 IN	A	52.230.239.36
# edge-internal.local.example.com. 2 IN	A	52.230.239.11

Query the Failover Gateway name directly. You can expect to get a list of all healthy gateways (across all regions):

dig +noall +answer global-edge-internal.global.example.com

# global-edge-internal.global.example.com. 2 IN	A	20.242.239.35
# global-edge-internal.global.example.com. 2 IN	A	20.232.235.7
# global-edge-internal.global.example.com. 2 IN A	52.230.239.36
# global-edge-internal.global.example.com. 2 IN A	52.230.239.11

Step 2: Test a Single Gateway Failure​

We scale down one of the Ingress Gateways, for example, in RG_E1:

kubectl config use-context aks-glbdemo01-eastus-0
# Switched to context "aks-glbdemo01-eastus-0".

kubectl scale deployment -n edge edge-gw --replicas 0
# deployment.apps/edge-gw scaled

After several seconds, that IP is removed from the DNS response:

edge-internal.global.example.com. 1 IN	CNAME	edge-internal.local.example.com.
edge-internal.local.example.com. 1 IN	A	20.232.235.7

Step 3: Test a Regional Failure​

We can then provoke a regional failure by scaling does the other Ingress Gateway (in RG_E2):

kubectl config use-context aks-glbdemo01-eastus-1
# Switched to context "aks-glbdemo01-eastus-1".

kubectl scale deployment -n edge edge-gw --replicas 0
# deployment.apps/edge-gw scaled

After several seconds, the alias is switched to the global-edge-internal.global.example.com CNAME, which contains a full list of all remaining working Edge Gateways:

edge-internal.global.example.com. 3 IN	CNAME	global-edge-internal.global.example.com.
global-edge-internal.global.example.com. 3 IN A	52.230.239.36
global-edge-internal.global.example.com. 3 IN A	52.230.239.11

Step 4: Restore Normal Operations​

When the gateways are scaled up (service is restored in the resource groups), the DNS responses are updated accordingly.

Scale the gateways up in each region:

kubectl config use-context aks-glbdemo01-eastus-1
# Switched to context "aks-glbdemo01-eastus-1".

kubectl scale deployment -n edge edge-gw --replicas 1
# deployment.apps/edge-gw scaled