What is the Readiness Probe?The Readiness probe signals readiness to process requests.In detail, this means that:
- While it responds successfully, it says the container is “ready” to receive requests.
- If all containers in a Pod are “Ready”, the Pod is added to the list of possible Endpoints for a Service.
- Network requests to a Service will go to the Endpoints (Pods that are “Ready”).
- The container gets marked as not ready.
- Because at least one container is not ready, the Pod as a whole is not ready.
- The Pod is removed from the list of eligible Endpoints for any Service it belongs to, and thus, stops getting new requests.
Correct Usage of the Readiness ProbeSay, a backend component depends on a database. If the database connection goes down (for whatever reason), the backend component cannot process requests, right now.It would be poor for application stability if the component would get requests it cannot process. It is much better to not get them in the first place, than to get them, and not be able to process them.If the backend component now responds with failure to its Readiness probe, it will not have to get new requests until the database connection is restored.By just not getting new requests, it can still have a warm cache, and JIT compiled interpreted languages such as Python or NodeJS will still be running efficiently. So performance is preserved, and the component will be ready to handle requests again, as soon as it is able to.
Download the open source Kubernetes distribution.
All security features pre-configured from day one with Elastisys Compliant Kubernetes. Including RBAC, monitoring, logging, intrusion detection and more.
What is the Liveness Probe?The Liveness probe signals that the component has “liveness”. That does not mean that it is “alive”. This unfortunate name is the number one reason it is misunderstood.“Liveness” is a term in distributed systems. It means that the component will, eventually, be able to produce a result. Or, as the Wikipedia article on liveness says, “something good will eventually occur”.When would that ever not be the case?
Deadlock vs. LivenessIn most systems, the practical opposite of liveness is if the component is in a deadlock state. This is a state where the application is caught in such a horrendous state that it cannot continue processing (some or all requests), because one part of it is waiting for another, which is waiting for the first (or a longer chain of waiting-for relationships).So because of deadlock, the component is unable to process (at least some) requests. In this case, it does not have “liveness”.The only remedy to a component without “liveness” is to terminate the application, and hope that it won’t wind up in that state again.…and that’s exactly what the kubelet in Kubernetes will wind up doing for you. It will restart that container.
Liveness Probe in DetailIn detail, when a Liveness probe fails (as many times as the failure threshold is set to), the following happens:
- the kubelet restarts that container (if the restart policy of the Pod permits),
- which marks the Pod as being “not ready”,
- which means that it it will not be an eligible Endpoint to any Service,
- which means that it stops getting requests.
- all containers (including the one that was restarted) are marked as ready,
- at which point the Pod itself is ready, and
- can be listed as an eligible Endpoint for any Service it belongs to.