Currently both liveness and readiness probes in the chart are set to check the same endpoint, which is /.
This might not work as expected in case, for example, if we need to gracefully shutdown the service.
For the time range the pod is being gracefully shut down (e.g. it has already received SIGTERM, but terminationGracePeriodSeconds has not expired yet and the service itself is still running/cleaning up) I would expect the readiness probe to return an error, so no traffic is forwarded to the given pod, while the liveness probe must still return 200, thus preventing the pod from being killed and restarted.
Currently both liveness and readiness probes in the chart are set to check the same endpoint, which is
/.This might not work as expected in case, for example, if we need to gracefully shutdown the service.
For the time range the pod is being gracefully shut down (e.g. it has already received SIGTERM, but
terminationGracePeriodSecondshas not expired yet and the service itself is still running/cleaning up) I would expect the readiness probe to return an error, so no traffic is forwarded to the given pod, while the liveness probe must still return 200, thus preventing the pod from being killed and restarted.