Kubernetes 101 : Readiness probes
The readiness probes tell kubernetes whether the pods are ready to accept requests.
Readiness probes allow kubernetes to communicate with the applications running inside the pods and get their "readiness" state.
The kubelet running on each node runs the probes, and changes the status of the pod - Ready, Pending, ... - based on the response of the application.
If the probe fails beyond the failure threshold, the pod is not restarted, and it is removed, so that it wouldn't receive any requests from client applications or from other pods.
Below is an example of a TCP based readiness probe:
Below a short definition of some of the probes parameters:
- initialDelaySeconds : waiting time in seconds after the pods starts before the probe is run.
- periodSeconds : the frequency of the probe - 10 seconds, means every 10 seconds -
- failureThreshold : number of tries before the pod is marked as not ready.
The probe in the above example, has a ten second initial delay before it starts probing the container.
The readiness probe is run at the start of the pod, and also when the pod starts experiencing issues after it is started.
Below are the types of readiness probes:
- An Exec probe : runs a command inside the container's application, and the exit status of the command determines the health of the container.
- An HTTP GET probe : sends an HTTP GET request to the container and the HTTP code of the response will determines the health of the container.
- A TCP Socket probe : opens a TCP connection to a port on the container. If the connection goes through, the container is considered healthy and ready to accept requests.