Why you probably won’t use K8gb.io

Into the weeds with k8gb and GSLBs

K8gb connects clients to healthy services in a multi-cluster set up

There are 2 reasons to go “global”:

• Better performance by proximity to customers
• Obtaining the highest level of availability and disaster recovery

In this post, I’ll be covering the latter use case and it’s why I put “global” in quotes, since the architecture I’ll be discussing is really multi-zone, and does not necessarily have to be multi-region. The idea here is to run at least 2 Kubernetes clusters, each isolated in their own zone.

You may be wondering why you would want to run 2 zonal Kubernetes clusters, instead of just 1 cluster spread across multiple zones for high availability. Well, you might find out the hard way that if one zone goes down and the load balancer is spread across multiple zones, it can cause network issues on your load balancer for all zones (so provisioning that NLB across multiple zones seems to have of back fired 🙁). Plus, when an outage occurs in one zone, how long does it take you to get all the pods off the nodes in that zone?

In the end, the most reliable architecture is one with multiple Kubernetes clusters isolated to their own zones. But this introduces another question. How do you make sure people who visit your app at “example.com” are routed to a healthy cluster/zone?

This is where Global Server Load Balancers can help. This blog is going to cover the 2 kinds of GSLBs and go into some hands on specifics of K8gb, the first open source DNS based GSLB for Kubernetes (and I’ll also discuss why I don’t use it and why you probably won’t either).

DNS Based GSLB

Let’s keep it simple. A DNS based GSLB is basically just dynamic DNS with health checks. The global service load balancer runs health checks against an endpoint and if it’s healthy, it configures DNS to point to that endpoint. When it becomes unhealthy, it immediately updates the DNS record to point to another healthy endpoint.

In reality, it’s a little more involved than that, but it’s fair enough to view it this way. With a TTL on the DNS record set to the lowest time possible (usually 60 seconds), that means (in theory), potential down time is limited to about a minute.