Tetrate GSLB, Tetrate Gateway, and Application Configuration

Gateway Configuration and Application Deployment

In order for the solution to work as intended, it must be configured as follows:

• Regional and Global Private DNS zones are created and linked as explained above, and in the detailed example below
• The Tetrate GSLB components are deployed in each Edge Gateway cluster, and are configured with the desired globalDNSzone and localDNSzone values. This document uses global.example.com and local.example.com, but you can use whatever is appropriate for your deployment.
• The Tetrate GSLB components are given Private DNS Contributor roles

Gateways

The user must create the following configuration:

• The set of Edge Gateways that should be monitored and exposed must be annotated with the same gslb.tetrate.io/name name. In these examples, we use the value edge-internal. This provokes the Tetrate solution to create the necessary DNS entries:
  • name.globalDNSzone in the Global Private DNS Zone
  • global-name.globalDNSzone in the Global Private DNS Zone
  • name.localDNSzone in each Regional Private DNS Zone

Applications

• For each service that is delivered through the solution, the user must:
  • Expose that service through all of the Edge Gateways in the set that have been tagged with the same gslb.tetrate.io/name name
  • For the service, configure a 'friendly' DNS name (e.g. the "API Name") that is an alias to the corresponding name.globalDNSzone DNS record managed by the Tetrate solution.

Correct Operation

Then, when a client resolves the 'friendly' DNS name, they will receive the A records of the Edge Gateways in the corresponding set; either the addresses of the gateways in the local region, or the addresses of all remaining functioning gateways.

It is possible to configure this solution on a per-VNET basis instead of a per-Region basis. This may be necessary if there are multiple VNETS within a region, and we want to protect against possible split-brain failures within a region.