Skip to main content
logoTetrate Global Load BalancerVersion: Latest

Install Tetrate Gateways

Step 1: Deploy Edge Gateways and the TSB Configuration​

We will:

  • Create a namespace edge on each Edge Gateway cluster, and install a TSB Gateway into that namespace
  • Configure the TSB resources needed (Tenant, Workspace, Gateway Group)

All Gateways should be deployed in the Gateway Set edge-internal. We therefore annotate the Gateway with the name edge-internal. This will cause the Tetrate GSLB solution to provision DNS resources for the gateways in this set, using this name.

Install the Edge Gateway​

On each cluster, perform the following steps:

kubectl config use-context aks-glbdemo01-eastus-0

kubectl create namespace edge
kubectl label namespace edge istio-injection=enabled

kubectl apply -n edge -f - <<EOF
apiVersion: install.tetrate.io/v1alpha1
kind: Gateway
metadata:
  name: edge-gw
  namespace: edge
spec:
  kubeSpec:
    service:
      type: LoadBalancer
      annotations:
        gslb.tetrate.io/name: edge-internal
EOF

The Gateway is exposed through an external IP address. This IP address will feature in the later Tetrate-GSLB-generated DNS records:

kubectl get svc -n edge edge-gw

Note the annotation gslb.tetrate.io/name. The value of this annotation defines the set of highly-available Edge Gateways, and the DNS names used to publish the Gateways.

Apply the TSB configuration​

We'll create the following TSB resources:

  • A Tenant glbdemo01
  • A Workspace edge-ws that spans all Edge Gateway clusters on the edge namespaces
  • Two Gateway Groups, edge-gw-eastus and edge-gw-centralus

Edit the following configuration to use appropriate cluster names, and use either the tctl method or apply configuration via kubectl:

Create TSB Configuration (Tenant, Edge Workspace, Edge Gateway Groups) using tctl​

cat <<EOF > tsb-edge-configuration.yaml
apiVersion: api.tsb.tetrate.io/v2
kind: Tenant
metadata:
  organization: tetrate
  name: glbdemo01
spec:
  displayName: glbdemo01
---
apiversion: api.tsb.tetrate.io/v2
kind: Workspace
metadata:
  organization: tetrate
  tenant: glbdemo01
  name: edge-ws
spec:
  namespaceSelector:
    names:
      - "aks-glbdemo01-eastus-0/edge"
      - "aks-glbdemo01-eastus-1/edge"
      - "aks-glbdemo01-centralus-2/edge"
      - "aks-glbdemo01-centralus-3/edge"
---
apiVersion: gateway.tsb.tetrate.io/v2
kind: Group
metadata:
  organization: tetrate
  tenant: glbdemo01
  workspace: edge-ws
  name: edge-gw-eastus
spec:
  namespaceSelector:
    names:
      - "aks-glbdemo01-eastus-0/edge"
      - "aks-glbdemo01-eastus-1/edge"
  configMode: BRIDGED
---
apiVersion: gateway.tsb.tetrate.io/v2
kind: Group
metadata:
  organization: tetrate
  tenant: glbdemo01
  workspace: edge-ws
  name: edge-gw-centralus
spec:
  namespaceSelector:
    names:
      - "aks-glbdemo01-centralus-2/edge"
      - "aks-glbdemo01-centralus-3/edge"
  configMode: BRIDGED
EOF

tctl apply -f tsb-edge-configuration.yaml

Step 2: Check the DNS Records​

Within a few seconds of deploying the Edge Gateways, the Tetrate GSLB solution will start to deploy the corresponding DNS records:

  • In the Global Private DNS zone:

    • edge-internal.global.example.com should be an alias for the Regional Gateway name edge-internal.local.example.com
    • global-edge-internal.global.example.com should contain A records for each healthy Edge Gateway in all regions

  • In the Local Private DNS zone, in each region:

    • edge-internal.local.example.com should resolve to the A records of the healthy Edge Gateways in that region

If the DNS records are not created within a few minutes, refer to the Troubleshooting section in this document.

Configuring the DNS TTL​

The TTL for the DNS records for each gateway can be configured using the annotation gslb.tetrate.io/ttl: "10". Note that the TTL value (in seconds) must be quoted.

The TTL value is one factor in how quickly the system can converge when availability changes. Intermediate DNS caches can store values, resulting in inconsistent or inaccurate results during the TTL period after a change.

The default TTL value of "10" (seconds) provides a balance between overloading clients and DNS servers, while minimizing the risks of inconsistencies or stale results. Values much greater than 10 seconds will likely cause noticeable instabilities.

kubectl apply -n edge -f - <<EOF
apiVersion: install.tetrate.io/v1alpha1
kind: Gateway
metadata:
  name: edge-gw
  namespace: edge
spec:
  kubeSpec:
    service:
      type: LoadBalancer
      annotations:
        gslb.tetrate.io/name: edge-internal
        gslb.tetrate.io/ttl: "10"
EOF

For consistency, all gateways should use the same TTL value.

Using AWS Load Balancer Controller​

On AWS, use the AWS Load Balancer Controller to create an internal NLB:

apiVersion: v1
kind: Service
metadata:
  name: edge-gw
  namespace: edge
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-scheme: internal
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip

    # The Gateway Set this gateway belongs to.
    gslb.tetrate.io/name: edge-internal
spec:
  type: LoadBalancer
  selector:
    app: edge-gw
  ports:
  - name: http
    port: 80
    targetPort: 8080

Confirm each cluster's gateway has a load balancer:

kubectl -n edge get service edge-gw -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
# k8s-edge-edgegw-abc123.elb.us-east-1.amazonaws.com

A hostname here is expected — Tetrate GSLB resolves it and publishes the addresses for you.

Optional: to choose the gateway's addresses yourself rather than letting AWS assign them, add aws-load-balancer-subnets and aws-load-balancer-private-ipv4-addresses (one address per subnet, each within that subnet's range). Useful if you want the addresses in your DNS to be ones you've reserved.

Step 3: Verify​

Within a minute the records should appear:

aws route53 list-resource-record-sets --hosted-zone-id "${GLOBAL_ZONE_ID}" \
  --query 'ResourceRecordSets[?Type!=`NS` && Type!=`SOA`].[Name,Type]' --output text

# edge-internal.global.example.com.          CNAME
# global-edge-internal.global.example.com.   A
# health-001-us-east-1.global.example.com.   TXT

Then check resolution from inside a cluster, which is what your clients actually see:

kubectl -n edge exec deploy/dnsutils -- dig edge-internal.global.example.com +noall +answer
# edge-internal.global.example.com. CNAME edge-internal.local.example.com.
# edge-internal.local.example.com.  A     10.10.200.10
# edge-internal.local.example.com.  A     10.10.200.26

Run the same query from a cluster in the other region and you should get that region's addresses.