Deprecating current Kubernetes implementation #135
TwiN
announced in
Announcements
Replies: 3 comments
-
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Considering that nobody has spoken against the idea and a sufficient grace period has been given, the current Kubernetes implementation will be officially removed from v3.0.0. See #166 |
Beta Was this translation helpful? Give feedback.
0 replies
-
v3.0.0 has been released today, and the Kubernetes auto discovery has been removed with it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello 👋
I've been thinking about deprecating the current (alpha) implementation of Kubernetes (see Kubernetes (ALPHA) in the README).
Here are the reasons why:
1. I'm not sure anybody even uses it
As much as I love Kubernetes from the depth of my heart, the dependencies are just such a pain to manage, and if nobody's using it, then I feel it's a pain I can live without.
2. I feel like the current implementation promotes bad practices
When I created Gatus, one of the biggest motivators was that I wanted an application that only notified me when something actually worth checking was happening.
The current Kubernetes implementation promotes having a 1-template-fits-all, which I think goes against that ideology; each service configuration should be tailored to that service, and even though you can do some basic filtering (through
kubernetes.namespaces[].name
andkubernetes.namespaces[].excluded-services
), I personally think it's not specific enough.Mind you, this reason is very opinionated. Really, you can use Gatus for whatever you want -- hell, I use Gatus for load testing, which is definitely not its intended purpose -- but as the maintainer, I have a vision for Gatus, and it strongly includes preventing Gatus from becoming "one of these tools that sends too many alerts and ends up being muted".
3. The current implementation could be externalized
By having another application whose primary task is auto discovery "inject" a configuration (e.g. in a configmap).
4. Readiness and liveness probes aren't supported
This is something that's been on my agenda, in fact, there's even an issue open about it: #5.
All the current implementation does is look for services (k8s) in a list of namespaces, and filter some of them out, then create a service (gatus) template that will fit every services (k8s) in a given namespace (e.g. "find all services in namespace X and evaluate the same endpoint and the same conditions on each of these services")
To clarify, I do plan on adding support for using the readiness & liveness probe statuses as a condition at one point, and may re-use some of the code that would be removed as a result of this deprecation, but I'd rather design it from scratch when I get to that point.
My mind is pretty much made up, but I'm just throwing it out there to see if anybody has something to say on the topic that might further convince me (or convince me otherwise).
Beta Was this translation helpful? Give feedback.
All reactions