Skip to main content
logoTetrate Global Load BalancerVersion: Latest

Product Components

Product Architecture​

The role of the Tetrate GSLB solution is to maintain the Global, Regional and Failover Gateway DNS records to ensure that lookups for an API/App/Service 'friendly' name (FQDN) receive the A records for healthy Edge Gateways, preferring Edge Gateways in the same region when available.

Tetrate GSLB Components​

The Tetrate GSLB Controller comprises the following components:

  1. tetrate-gslb-controller: Acts as the central intelligence of the system, determining which DNS Zones to update, when to update them, and what specific DNS records need modification.
  2. external-dns-controllers: Executes updates to DNS records based on directives from the tetrate-gslb-controller. There are two deployments: one for the regional DNS Zone and another for the global DNS Zone.

The Tetrate GSLB controller communicates with the External-DNS controllers using a set of dnsendpoint Custom Resources (CRs) (documented in the Troubleshooting chapter). The Regional and Global External-DNS Controllers are configured with Private DNS Zone Contributor roles to give them write access to the Regional and Global Private DNS Zones respectively:

Tetrate GSLB product architecture

info

The Tetrate GSLB install also includes a busybox container which is used for internal health check tests.

Each Tetrate GSLB Controller's responsibilities include:

  • Maintaining DNS A records: Ensures that the Regional Gateway DNS record continuously reflects the IPs of healthy Edge Gateways within the region, and that the Failover Gateway DNS record accurately reflects IPs of healthy Edge Gateways across all regions.
  • DNS TXT Record Updates: The controller advertises the health statuses of the Edge Gateways in the cluster through DNS TXT records updates and gathers similar data about active Edge Gateways from other clusters. This consolidated information is used to update the DNS A records in both the regional private and global DNS Zones. An expired timestamp in the TXT records serves as an indicator of cluster or regional failures.
  • Handling regional failures: When the controller detects regional outages, it changes the contents of the Global Gateway DNS record to the Failover Gateway CNAME. Conversely, it also detects regional recovery and changes the contents back to the Regional Gateway CNAME.

As we will see when we configure VNet mappings, each Tetrate DNS controller needs to be able to resolve entries in its local Private DNS zone and in the global Private DNS zone. Internal shared state is stored and distributed as TXT records in each of these zones; note that the schema and contents of this internal information may change between releases.