What is Readiness Probe in Kubernetes-DecodingDevOps

Kubernetes Health Checks

Making sure that container and application are ready to serve requests in kubernetes is as challenging as deploying a deployment. Sometimes Pods are ready but the application is not ready to accept clients requests. And to eliminate that complexity, Kubernetes introduced “healthchecks” to check the healthiness of the application and container.

There are two kinds of healthcheck probes, one is Liveness Probe and other one is Readiness Probe.

Kubernetes Readiness Probe

kubernetes readiness probe check whether an application is ready to to serve requests or not. A healthy Readiness Probe’s response always tells that container and application is ready to serve. Always kubernetes includes those pods into the load balancer who are considered healthy with the help of readiness. Unhealthy pods are being removed from the Load Balancer to serve those requests. To check healthiness for container running a live website, Liveness Probe is being set to get status code greater or equal than 200 and less than 400. If status code in health check is outside from the given constraints, then scheduler automatically consider that pod unhealthy.

Kubernetes Readiness Probe with Example

Let’s understand kubernetes readiness probe with example .

Consider nginx server to serving a website. Let’s create yaml file and deploy it on Kubernetes.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: webserver
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

From the yaml file we can see that, readiness probe is being set to check HTTP health for container. Health Check path is “/” which is considered as root path. We are using http port (80) to host our website. We also define initialDelaySeconds as 5, so once container created kubernetes wait for initial delay of 5 second to hit it’s first health check. Last but not least, periodSeconds are being set to 10 sec, which tells kubernetes to take period of 10 seconds before every next check.

Now to deploy this pods use following command.

kubectl apply -f nginx.yaml

this will create a pod running nginx image on it.

Now to check whether this pod is running or not, hit the following command.

kubectl get pods nginx

The output of the previous command is:

master $ kubectl get pods
NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     Running   0          6s

From the output, You can see that the status of the pod is “Running”. However, in ready state it is showing “0/1” which indicates that container is created but pod is not healthy yet. The moment pod respond with 200 status code, the pods will be considered healthy and ready to serve http requests.

master $ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          26s

Now to testing what happens when we receive status code which is not in range of 200 to 400, hit following command.

kubectl exec -t nginx -- rm /usr/share/nginx/html/index.html

master $ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   0/1     Running   0          6m32s

You will get 404 in the web browser and after few health checks the pod is being considered unhealthy. So this pod is being removed from the LoadBalancer and is no longer able to serve requests until it become healthy again.

Now to make this pod healthy and make it serve requests again, Generate a new .html file and copy it into the pod.

echo "<h1>Status: 200</h1>" >> index.html

kubectl cp index.html nginx:/usr/share/nginx/html/

And now again you can see the pod is in Ready state and able to serve requests.

master $ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          8m

kubernetes Health checks are as important as any other components in production cluster. kubernetes Readiness probe and Liveness probe always make sure that there are always healthy pods running in the cluster and always available to serve requests. So few health checks and your production system stays up and running for your clients to serve.