k8gb balances across Kubernetes clusters with DNS and one Gslb resource

One Gslb resource points at an Ingress and names a primary cluster

k8gb is a cloud native Kubernetes Global Balancer, and its central idea is that the whole configuration is one custom resource.

apiVersion: k8gb.io/v1beta1
kind: Gslb
metadata:
  name: test-gslb-failover
  namespace: test-gslb
spec:
  resourceRef:
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    name: test-gslb-failover
  strategy:
    type: failover # Global load balancing strategy
    primaryGeoTag: eu-west-1 # Primary cluster geo tag

The reference model is the part that makes it feel native. The Gslb does not define the application, it points at one through resourceRef, here an Ingress, and the strategy block says how traffic should be distributed, with the type set to failover and the primary cluster identified by a geo tag. The applications and their own Ingress objects stay untouched, and the global layer is a separate concern expressed as its own resource.

The README's framing of the problem is direct. Global load balancing, commonly referred to as GSLB solutions, has typically been the domain of proprietary network software and hardware vendors, installed and managed by siloed network teams. k8gb is positioned as a completely open source, cloud native, global load balancing solution for Kubernetes, and the sentence that follows is the one an operations team cares about: global load balancing for any Kubernetes Service can now be enabled and managed by any operations or development teams in the same Kubernetes native way as any other custom resource.

The motivating case is specific. k8gb was born out of the need for an open source, cloud native GSLB solution at Absa Group in South Africa, as part of a bank's wider container adoption running multiple geographically dispersed Kubernetes clusters, where a global load balancer driven from the health of Kubernetes Services was required and no existing solution was found.

The legacy API is still handled. k8gb.absa.oss/v1beta1 resources are still accepted and automatically migrated to k8gb.io/v1beta1, and legacy objects are labeled k8gb.io/migrated-to-k8gb-io=true and emit a warning event telling users to edit the k8gb.io object going forward.

DNS is the mechanism, and the health signal comes from Kubernetes probes

The four key differentiators listed in the README are the whole architecture.

Load balancing is based on the timeproof DNS protocol, which the README says is perfect for global scope and extremely reliable. There is no dedicated management cluster and no single point of failure. Kubernetes native application health checks utilize the status of liveness and readiness probes for load balancing decisions. And configuration is with a single Kubernetes CRD of Gslb kind.

The health signal is the part that is genuinely different from a network appliance. A traditional GSLB checks whether the backend answers a health check URL. k8gb reads the status of the Kubernetes probes, which means the same liveness and readiness endpoints your workloads already declare decide whether a cluster is in rotation. There is no second definition of health to keep in sync, and a probe that is failing in Kubernetes is failing in the DNS answer too.

The DNS choice has a clear cost, and the README is honest about the reasoning rather than hiding it. DNS is reliable and global, but a resolver cache means that a failover is not instantaneous. The TTL of the record determines how long clients keep using the old answer. That is the right trade for a bank running multi-region Kubernetes with health-driven failover, where a few seconds of stale routing is acceptable and a management cluster being a single point of failure is not. It is the wrong trade for a game server or a trading system, and the README's own framing of the problem as enterprise multi-region infrastructure tells you which side of that line the project targets.

The absence of a dedicated management cluster is worth understanding. Each k8gb instance runs inside the cluster it manages, and the clusters exchange their health information with each other. There is no central brain to lose, and the cost is that the logic is distributed, which is why the DNS provider integration and the strategy rules carry so much of the complexity.

make deploy-full-local-setup spins up two k3d clusters to try it

The quick start is a single make target, which is unusual and pleasant.

make deploy-full-local-setup

It deploys two local k3s clusters via k3d, exposes the associated CoreDNS service for UDP DNS traffic, and installs k8gb with test applications and two sample Gslb resources on top. The setup is adapted for local scenarios and works without external DNS provider dependency, and the local playground documentation covers the details of experimenting with the local setup.

A local setup that needs no external DNS provider is a deliberate piece of engineering, because the production path needs a real delegated zone. The Makefile shows what it involves: CLUSTERS_NUMBER defaults to 2, CLUSTER_NAME defaults to test-gslb, CLUSTER_GEO_TAGS lists eu, us, cz, af, ru, ap, uk and ca, and the clusters share a k3d action bridge network whose gateway address is read out of the Docker network inspect output. So the local environment really is two clusters with a shared network and geo tags, which is the shape of the production topology.

There is a newer demonstration built on the same scaffolding:

make deploy-full-local-setup FULL_LOCAL_SETUP_WITH_AI_DEMO=true
make ai-inference-demo

That deploys a lightweight Ollama model in both clusters, exposes an OpenAI-compatible endpoint, and shows failover through the same global hostname. The AI inference resilience demo documentation covers local and real-cluster usage. The Makefile constants for it are visible: OLLAMA_IMAGE defaults to alpine/ollama:latest, OLLAMA_BASE_MODEL to qwen2.5:0.5b, and OLLAMA_STORAGE_SIZE to 2Gi, which tells you the demo is deliberately small enough to run on a laptop.

Metrics are optional. You can run make deploy-prometheus and check the metrics on the test clusters at localhost:9090 and localhost:9091. The go.mod confirms the Prometheus client, and there is a grafana/ directory in the repository for the dashboards.

The dependency list shows DNS and external-dns, not a cloud load balancer

The go.mod is the clearest technical description of what k8gb actually is, and it is short and specific.

The DNS side is github.com/miekg/dns at 1.1.73, the Go DNS library, and sigs.k8s.io/external-dns at 0.23.0, which is the project that writes DNS records from Kubernetes resources. That pairing is the architecture: k8gb computes the answer, and external-dns is what actually publishes it to your provider.

The Kubernetes side is controller-runtime at 0.25.2 with k8s.io/api, apimachinery and client-go all at 0.37.1, which is the standard operator stack. The service mesh and gateway pieces are there too: istio.io/client-go at 1.31.1 and sigs.k8s.io/gateway-api at 1.6.3, so the project understands both Ingress and the newer Gateway API.

The DNS provider integrations are the infobloxopen/infoblox-go-client, in both v1 and v2, which is a specific vendor's DNS provider. A dependency on one vendor's client does not mean k8gb only works with Infoblox, since external-dns is the general mechanism, but it does show which provider the maintainers at Absa Group, a bank, had in front of them.

The rest is standard operator machinery. alecthomas/kong for the CLI, go-playground/validator for CRD validation, rs/zerolog for logging, and a full OpenTelemetry stack with the OTLP trace and HTTP exporters plus the SDK, which is what produces the traces the project exports. prometheus/client_golang provides the metrics. go.uber.org/mock and stretchr/testify are the test doubles and assertions.

The module targets Go 1.27.2. The container image is a distroless static nonroot base with a single binary copied in, running as the nonroot user, which is a small and hardened image with no shell in it.

CNCF incubation, a 1.0 release, and a v1 API after the migration

The governance signals are strong for a project at this stage, and they are the reason to keep watching it.

k8gb is a CNCF Incubating Project, with a link to the CNCF landscape entry, a Slack channel on CNCF Slack, a roadmap on GitHub projects, and community meetings. The repository also carries GOVERNANCE.md, a self-assessment.md, an ADOPTERS.md, a CONTRIBUTOR_LADDER.md and a DEPENDENCY.md, which are all CNCF project expectations rather than optional extras.

The badge list in the README is a roll call of the compliance and security tooling a CNCF project is expected to have: CodeQL, the OpenSSF Scorecard, CII Best Practices, CLOMonitor, FOSSA for licence scanning, a Go Report Card, the Terratest workflow, golangci-lint and golic, Helm publish, and a doc.crds.dev badge for the generated custom resource reference. The presence of cosign.pub in the repository root and the note that signed OCI artifacts are published to ghcr.io/k8gb-io means the images are signed, and the container image default in the Helm chart is registry.k8gb.io/k8gb-io/k8gb, with the Docker Hub badge reflecting historical pulls.

The release history is short but the important number is v1.0.0 on 2026-09-02, which comes after the v0.21.0 release candidates in August 2026. The 1.0 release is likely tied to the API group move from k8gb.absa.oss to k8gb.io, since the legacy migration behaviour and the warning events are described in the same section as the v1beta1 example. A 1.0 release with an API group rename is a breaking change for existing users, which is why the automatic migration and the deprecation warning exist.

The repository is not archived and the last push was on 2026-10-15, so the work is current.

Editorial conclusion

Adopt k8gb if you run more than one Kubernetes cluster across geographies and want failover driven by native readiness and liveness probes, configured through a custom resource rather than a network appliance. Do not adopt it if you need layer 4 balancing or sub-second failover, since the README says the load balancing is based on the timeproof DNS protocol, which trades response speed for reliability. Before you install, confirm you have a DNS provider and a zone you can delegate, and read the strategy documentation, because failover, round robin and geoip behave very differently and the choice is baked into the Gslb resource.

Frequently asked questions

Official sources

1. k8gb-io/k8gb on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases