Posted inDevOps

Multi-Region Kubernetes: A Hands-on Guide to Global Load Balancing with K8gb

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

The Nightmare of Regional Outages

Standard Kubernetes Ingress controllers handle local traffic perfectly. But when an entire cloud region like US-East-1 hits the dirt, your local Ingress becomes a dead end. If your infrastructure spans geographical borders—perhaps US-East and EU-West—you need a way to steer traffic at the DNS level based on real-time cluster health.

For years, Global Server Load Balancing (GSLB) was locked behind expensive hardware like F5 BIG-IP or proprietary cloud services like AWS Route53. These tools often feel like outsiders in a Kubernetes-native workflow. K8gb changes that. It is an open-source operator that transforms your existing CoreDNS into a globally distributed load balancer that lives where your code lives.

Why K8gb Beats Traditional GSLB

Most GSLB solutions require manual API calls or clunky integrations to update DNS records during a disaster. K8gb avoids this by using the Kubernetes Operator pattern. It constantly watches your application’s health across clusters. If a service in London fails, K8gb automatically rewrites DNS responses to point users to New York instead.

Vendor lock-in is a non-issue here. You can run one cluster on GKE, another on-premises, and a third on AWS. K8gb creates a lightweight mesh between them to share health statuses. In my production tests, this setup handled regional latency spikes far better than static DNS weighting, often triggering failovers in under 10 seconds.

Setting Up Your Multi-Region Mesh

You need at least two Kubernetes clusters to see the magic happen. For this guide, we will use cluster-eu and cluster-us. Each cluster must have a public-facing LoadBalancer service or a reachable IP address.

Prerequisites

  • Two active Kubernetes clusters (v1.24+).
  • Helm installed on your local machine.
  • A domain (e.g., example.com) managed via Route53, Cloudflare, or similar providers.

Installing K8gb via Helm

You’ll need to run the installation on both clusters to get them talking. K8gb sits on top of CoreDNS, so we will deploy it using the official Helm chart. Each site needs a unique geo-tag to identify its location.

# Deploying to the EU cluster
helm repo add k8gb https://www.k8gb.io
helm repo update

helm install k8gb k8gb/k8gb \
  --namespace k8gb \
  --create-namespace \
  --set k8gb.clusterGeoTag="eu" \
  --set k8gb.extGslbClustersGeoTags="us" \
  --set k8gb.edgeDNSZone="example.com" \
  --set k8gb.edgeDNSServers="8.8.8.8"

Now, switch your context to the US cluster and run the command again, but swap the tags:

# Deploying to the US cluster
helm install k8gb k8gb/k8gb \
  --namespace k8gb \
  --create-namespace \
  --set k8gb.clusterGeoTag="us" \
  --set k8gb.extGslbClustersGeoTags="eu" \
  --set k8gb.edgeDNSZone="example.com" \
  --set k8gb.edgeDNSServers="8.8.8.8"

K8gb uses ExternalDNS under the hood. It creates NS (Name Server) records in your main DNS provider, effectively delegating a subdomain like gslb.example.com to the K8gb instances running inside your clusters.

Defining Your Traffic Strategy

Forget manual DNS record management. Once the operator is live, you control traffic using a Gslb Custom Resource. You can choose between RoundRobin, Failover, or GeoIP strategies depending on your needs.

The Failover Strategy

Failover is the safest bet for database-heavy apps. You designate a Primary region and only route traffic to the Secondary if the Primary is completely unreachable. This prevents the data consistency headaches caused by cross-region replication lag.

# failover-strategy.yaml
apiVersion: k8gb.absa.oss/v1beta1
kind: Gslb
metadata:
  name: my-app-gslb
  namespace: my-app
spec:
  strategy:
    type: failover
    primaryGeoTag: eu
  ingress:
    rules:
      - host: app.gslb.example.com
        http:
          paths:
          - path: /
            backend:
              serviceName: my-app-service
              servicePort: 80

Apply this to both clusters. K8gb detects the shared host app.gslb.example.com. Since eu is the primary, DNS queries will return the EU LoadBalancer IP as long as those pods are healthy.

The Round Robin Strategy

Stateless microservices thrive on roundRobin. This strategy distributes users across all regions to balance the load. It is a simple way to improve performance for a global user base.

spec:
  strategy:
    type: roundRobin

In this mode, K8gb returns IP addresses from both clusters. The client’s DNS resolver will then cycle through them automatically.

Verification and Production Monitoring

Testing GSLB requires a shift in mindset. You aren’t just checking HTTP status codes; you are watching DNS responses. Use the dig tool to see which cluster is answering your request.

# Query your K8gb DNS instance directly
dig @<K8GB_SERVICE_IP> app.gslb.example.com

Try simulating a disaster. Scale your primary deployment to zero. Within roughly 10 to 30 seconds, K8gb’s health check will flag the EU site as down. Run dig again, and you should see the US cluster’s IP address appear instantly.

Observability is mandatory for production. K8gb exports metrics to Prometheus by default. I recommend building a Grafana dashboard to monitor these three key areas:

  • Regional Health (k8gb_gslb_status): Is the US cluster seeing the EU cluster as “Up”?
  • Resolution Latency: Are your CoreDNS instances responding in under 20ms?
  • Edge Sync Errors: Are you hitting API rate limits on Route53 or Cloudflare?

In my experience, the setup rarely fails at the K8gb level. Most issues stem from “Edge DNS” configuration. If your parent domain’s NS records don’t point correctly to your K8gb LoadBalancer IPs, your traffic steering will fail before it even starts. Treat your global traffic rules as code, and you’ll achieve the resilience that modern distributed systems demand.

Share:
Tags: