Skip to content
This repository has been archived by the owner on Jul 27, 2022. It is now read-only.

Do not send 503 on shutdown #17

Open
florianmutter opened this issue Jul 1, 2019 · 2 comments
Open

Do not send 503 on shutdown #17

florianmutter opened this issue Jul 1, 2019 · 2 comments

Comments

@florianmutter
Copy link

florianmutter commented Jul 1, 2019

According to https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-liveness-or-readiness-probes it is not necessary to send 503 on shutdown.

Note that if you just want to be able to drain requests when the Pod is deleted, you do not necessarily need a readiness probe; on deletion, the Pod automatically puts itself into an unready state regardless of whether the readiness probe exists. The Pod remains in the unready state while it waits for the Containers in the Pod to stop.

See also https://freecontent.manning.com/handling-client-requests-properly-with-kubernetes/

I think it should be avoided to have more meaning full event logs of the pods. Otherwise each shutdown generates logs of failed readiness requests

@florianmutter
Copy link
Author

I would appreciate a comments on this. Maybe I got something wrong.

@rsp
Copy link

rsp commented Oct 18, 2020

@florianmutter Did you get any feedback on this issue?
It seems to me that it all depends on whether the service can still serve requests during the shutdown. The pod may automatically put itself into an unready state if the pod itself is deleted, but the shutdown can be initiated not only by Kubernetes but from the application itself - like getting a sigterm for some other reason or even a self-initiated or a manual shutdown.

In any case, if it is able to serve the readiness requests but not its core service endpoints for some reason then 503 seems reasonable if the service is indeed unavailable. But I'd like to know how this project maintainers view it. Did you get any reply on that?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants