Separate readiness and liveness probe

[bouskaJ]

We have a common configuration property for enablement liveness and readiness probes ({{container.probes-enabled}}). But those probes are used for different use-cases.
See probes documentation:

The kubelet uses liveness probes to know when to restart a container.

 For example, liveness probes could catch a deadlock, where an application is running, but unable to make progress. Restarting a container in such a state can help to make the application more available despite bugs.

The kubelet uses readiness probes to know when a container is ready to start accepting traffic.

 A Pod is considered ready when all of its containers are ready. One use of this signal is to control which Pods are used as backends for Services. When a Pod is not ready, it is removed from Service load balancers.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

I can imagine an application that should not be restarted on an unhealthy status (only readiness probe makes sense to configure) and vice versa.

[prapakaransp]

@bouskaJ Agreed. Both are different. It needs to be addressed separately for both liveness and readiness proof.