CODEWITHSUNDEEP
kuberneteshealth-monitoringkubernetes-health-checkhealth-check
Axedyson
Axedyson

Reputation: 279

Should I implement a dedicated api endpoint for Kubernetes health checks?

I have deployed a next.js frontend server and an express.js backend server on a Kubernetes cluster, which issues automated health checks, currently on the root path ("/") on the two servers.

My question is, should I implement my own health check routes like "/health" and just return a 200 HTTP response code on that route or should I just let it be as it is right now?

I'm afraid that I will implement a lot of functionality on the root path ("/") endpoint on both servers, which would put a bit more pressure on my two servers, as the cluster continues to issue requests to those endpoints.

Upvotes: 1

Views: 1947

Answers (1)

Rico
Rico

Reputation: 61689

Actually, if you are concerned about affecting the performance of your application, from the compute/memory resources perspective it depends on what material you are serving under /.

If you are serving a big blob of HTML it will actually affect your performance and I'd recommend implementing a different endpoint /health for healthcheck to be used with Kubernetes Readiness Probes for example.

If the content of / is very light, it's unlikely that it will make a difference. In terms of improving the 'stress' you are putting on the resources when running a healthcheck using Liveness/Readiness probes in K8s, you could alleviate that by increasing the periodSeconds in them, but keep in mind that if you have multiple pods behind a Kubernetes service and one of the pods has some issue with the healthcheck it would take longer for that pod to be removed from the service causing a longer potential 'downtime'.

Upvotes: 3

Related Questions