k8gb is a global server load balancer for Kubernetes. When the same application runs in several clusters, k8gb decides which clusters’ addresses to return when a client resolves the application’s DNS name, based on whether each cluster’s workload is healthy and on a chosen strategy such as failover, round robin, weighted or geography. It addresses the question left open by multi-cluster deployment: how to send users to the right cluster and away from a failed one, without a vendor’s global load balancer and without a central coordinating service. Each cluster runs its own k8gb controller and DNS server, and the controllers learn about each other through DNS. k8gb was created at Absa Group, a South African banking group, was accepted into the CNCF Sandbox on March 30, 2021, and moved to Incubating on July 18, 2026.
CNCF daily · Sprint 3, post 8 of 21 · Coordination & Service Discovery
At a glance
| Category | Orchestration & Management › Coordination & Service Discovery |
| CNCF status | Incubating. Accepted March 30, 2021; incubating July 18, 2026 |
| Written in | Go |
| License | MIT |
| Core resource | Gslb custom resource that references an Ingress or similar object |
| Strategies | Round robin, failover with a primary geo tag, weighted round robin, and GeoIP-based routing |
| DNS components | CoreDNS in each cluster with a Kubernetes custom resource plugin, plus ExternalDNS for delegation records |
| Edge DNS providers | Route 53, Azure DNS, Cloudflare, Infoblox, NS1 and others supported through ExternalDNS |
| Health signal | Readiness of the pods behind the referenced Ingress or service in each cluster |
Architecture
flowchart TB
CLIENT[Client<br/>resolver] ==>|1 query app.gslb.example.com| EDGE[Edge DNS zone<br/>Route 53 or similar]
EDGE ==>|2 NS delegation to cluster DNS| CDNS1[k8gb CoreDNS<br/>cloud cluster]
EDGE ==>|NS delegation| CDNS2[k8gb CoreDNS<br/>edge cluster]
CDNS1 ==>|3 answer with healthy IPs<br/>by strategy| CLIENT
CTL1[k8gb controller<br/>cloud cluster] -.->|reads Gslb and endpoints| CDNS1
CTL2[k8gb controller<br/>edge cluster] -.->|reads Gslb and endpoints| CDNS2
CTL1 -.->|asks peer CoreDNS<br/>for healthy addresses| CDNS2
CTL2 -.->|asks peer CoreDNS| CDNS1
EXD[ExternalDNS] -.->|writes NS records| EDGE
CTL1 -.->|DNSEndpoint for delegation| EXD
CLIENT ==>|4 connect to returned IP| ING[Ingress or gateway<br/>in chosen cluster]
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
class CTL1,CTL2,CDNS1,CDNS2 core
class ING,EDGE data
class CLIENT actor
class EXD ctrl
Key: teal blocks are k8gb components, blue are the edge DNS zone and the application entry, purple is ExternalDNS, grey is the client. Numbers follow a request; thick arrows carry DNS and traffic, dashed arrows carry control information.
| Component | Responsibility |
|---|---|
| Gslb resource | Declares the hostname, the Ingress or service whose health matters, and the load-balancing strategy. |
| k8gb controller | Watches the Gslb and the endpoints behind it, decides which addresses are healthy locally, and compares with peers. |
| CoreDNS with k8s_crd plugin | Answers queries for the GSLB zone using the controller’s decisions, serving the addresses of healthy clusters. |
| ExternalDNS | Creates the delegation (NS and glue) records in the edge DNS zone so queries reach the cluster DNS servers. |
| Peers | Each cluster queries the other clusters’ DNS servers to learn their healthy addresses, so no shared database exists. |
Design principle. Use DNS as the only coordination channel. Because clusters share state by answering each other’s DNS queries, there is no central service to fail, and a regional outage affects only the clusters in that region.
Production reference design
A typical design has two or three clusters, such as a cloud region and an edge site, that all serve the same application.
- Prepare edge DNS. Delegate a zone, such as
gslb.example.com, so that its name servers are the k8gb DNS servers, and give ExternalDNS permission to manage the parent zone records. - Install k8gb in each cluster with values that describe its place in the topology:
helm repo add k8gb https://www.k8gb.io helm upgrade -i k8gb k8gb/k8gb --namespace k8gb --create-namespace -f values.yaml
Each cluster uses its own tag and lists the others ink8gb: dnsZone: "gslb.example.com" edgeDNSZone: "example.com" edgeDNSServers: ["10.0.0.2"] clusterGeoTag: "ap-south-1" extGslbClustersGeoTags: "edge-vizag" reconcileRequeueSeconds: 10extGslbClustersGeoTags. - Declare the global service. A
Gslbthat prefers the cloud cluster and fails over to the edge when it is unhealthy:apiVersion: k8gb.absa.oss/v1beta1 kind: Gslb metadata: { name: shop, namespace: shop } spec: resourceRef: apiVersion: networking.k8s.io/v1 kind: Ingress matchLabels: { app: shop } strategy: type: failover primaryGeoTag: ap-south-1 - Test failover. Scale the application to zero in the primary cluster and watch DNS answers change to the secondary within the record’s time to live.
- Tune time to live and checks. Keep DNS records short-lived and set the reconcile interval to balance responsiveness and load.
Typical uses include active-active and active-passive multi-region services, disaster recovery for public endpoints, and edge-to-cloud failover. The Gslb API has changed across releases, so check the documentation for the version you install.
Operational considerations
- DNS caching sets the failover time. Resolvers may ignore short time-to-live values. Expect failover in tens of seconds to minutes, and plan application retries accordingly.
- Health means readiness. k8gb checks pod readiness behind the referenced Ingress, not user-level health. Make readiness probes meaningful.
- Edge DNS delegation is the fragile point. Test delegation records, glue and ExternalDNS permissions, and monitor the DNS servers’ availability from outside the clusters.
- State is not global. k8gb routes users; it does not replicate data. Databases and sessions need their own multi-cluster design.
- Exposure. The cluster DNS servers are public. Use load balancers with appropriate limits, and enable DNS-level protections against abuse.
Adoption
- Absa Group created k8gb and runs it for its own multi-cluster services.
- The project’s repository maintains an ADOPTERS file and describes production users; consult it for current organisations.
- Reaching Incubating in 2026 reflects a growing adopter and contributor base, but teams should still check references in their provider and region.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Cloud DNS routing (Route 53 health checks, Azure Traffic Manager) | Provider-managed DNS failover | Estates on one provider that accept a managed service |
| Global cloud load balancers | Anycast or provider global load balancing | Latency-sensitive public services on a single cloud |
| Cloudflare or NS1 load balancing | SaaS traffic steering | Teams wanting managed health checks and analytics |
| Karmada (CNCF Graduated) | Multi-cluster workload placement | Deciding where workloads run, paired with GSLB for traffic; see the Karmada brief |
| CoreDNS (CNCF Graduated) | Cluster and zone DNS server | The DNS engine k8gb builds on; see the CoreDNS brief |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| No central control plane or single point of failure | Failover speed is bounded by DNS caching |
| Works across clouds, on-premises and edge | Health signal is pod readiness, not end-to-end checks |
| Kubernetes-native, driven by a simple custom resource | Needs correct DNS delegation and ExternalDNS setup |
| Several strategies, including failover and GeoIP | Operating public DNS servers in each cluster |
| Open source with an MIT licence | Smaller ecosystem than commercial GSLB services |
Recommendation
Adopt for teams that run the same service in several clusters and want vendor-neutral, DNS-based failover. Start with two clusters, a short zone time to live, the failover strategy and a drill that removes the primary, and measure real client failover time before relying on it. Services that need near-instant failover or fine-grained latency routing may need a provider global load balancer in front.
References: CNCF project page · k8gb website · k8gb repository · CNCF Landscape