Is a Readiness Gate Controller a Necessary Addition to Kubernetes?

0
10
Asked By TechExplorer93 On

I've been diving deep into Kubernetes controllers and I wanted to share an idea I'm experimenting with called a Readiness Gate Controller. Traditionally, Kubernetes readiness probes simply check if an app can accept traffic by pinging localhost, which is fine for data loading and background processes. However, many applications rely on external services like databases and APIs. The common view is that checking these in readiness probes can lead to scalability issues since you wouldn't want many replicas hitting a database just to confirm it's up.

So, I created a Readiness Gate Controller that checks the database centrally, rather than having every pod do it. This way, if there are any issues with the dependency, the controller can toggle a readinessGate on the deployment, and stop traffic accordingly. This separates "App Health" from "Dependency Health."

I've tried to simplify the use of gates by letting users define their checks in a Helm values file without needing to mess with the Kubernetes API directly. I'm open-sourcing this today and would love to hear your thoughts: Is this extra layer of control something you find useful, or do you think the standard approach of letting the app fail until the database recovers is sufficient?

3 Answers

Answered By SystemArchitect21 On

While I understand the intent behind your design, it feels overly complicated. If 50 pods are querying the database, it’s not terribly costly in terms of resources. I’d rather have the workloads report their own readiness, ensuring they're truly prepared to handle traffic.

Answered By DevDude39 On

I see what you're trying to do, but there are alternatives. Like init containers that wait for resources to be ready before starting the main container. It might seem like extra work, but it helps avoid the issues you're concerned about without needing a central controller.

Answered By CodeMonkey77 On

I get your approach, but isn’t it the app’s job to signal its own readiness? If your app isn’t ready to take traffic, the readiness endpoint shouldn’t respond with a 200 status. Kubernetes shouldn’t have to check if your app is correctly reporting itself as ready.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.