Liveness probe kubernetes are mechanism for exposing whether the applications inside your containers are healthy. Read more about the Liveness probe article by our Server management support services.

Liveness probe kubernetes

Liveness probes are a mechanism provided by Kubernetes. Determines if applications running within containers are operational. Also, help to improve the resilience and availability of Kubernetes pods.

Kubernetes controllers by default check if a pod is running. And if find it’s not running, then restart it according to the pod’s restart policy. However, might be a chance of the pod running, even though when the app running within has malfunctioned.

Liveness checks provide granular information to the kubelet. This helps to understand whether applications are functional or not.

When to use a Liveness Probe?

A liveness probe is not necessary if the application running on a container is configured to auto crash container during a problem or when an error occurs. In such cases, the kubelet will take the appropriate action. It will further restart the container based on it’s pod’s restart policy.

If you use a liveness probe, then set the restartPolicy to Always or OnFailure.

Liveness Probe Best Practices

The below practices help you to make effective use of liveness probes. These practices apply to Kubernetes clusters running for 1.16v and after.

• To use probes on apps that have unpredictable or fluctuating startup times.

• If you use a liveness probe on the same endpoint as a startup probe, then set the failureThreshold of the startup probe higher, to support long startup times.

• Use readiness and liveness probes on the same endpoint. But, in this case, use the readiness probe to check startup behavior and the liveness probe to verify the container health.

• Defining probes improves pod resilience and availability. Before defining a probe, need to observe the system behavior and average startup times of the pod and its containers.

• Be sure to update probe options as an application evolves, or if you make infrastructure changes, such as giving the pod more or fewer system resources.

Creating Liveness Probes

Liveness probes are been defined by the pod’s spec.containers.livenessProbe field. Here’s an example of an exec (command) type liveness probe:

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-demo
spec:
  containers:
  - name: liveness-probe-demo
    image: busybox:latest
    args:
    - /bin/sh
    - -c
    - touch /healthcheck; sleep 30; rm -rf /healthcheck; sleep 300
    livenessProbe:
    exec:
        command:
        - cat
        - /healthcheck
    initialDelaySeconds: 5
    periodSeconds: 15
    failureThreshold: 1

This pod’s containers have a liveness probe that will have an initial delay of five seconds. Later reads the content of the /healthcheck file every fifteen seconds after. The container is configured to create the new /healthcheck file when it starts up.

Later removes the file after thirty seconds have elapsed. At this point the liveness probe’s cat command will begin to issue non-zero status codes. This cause a subsequent probe to be marked as failed.

Apply the YAML manifest to your cluster:

$ kubectl apply -f liveness-pod-demo.yml

Next, inspect the events of the pod you’ve created:

$ kubectl describe pod liveness-probe-demo

Further, wait for 30 seconds before retrieving the events again:

$ kubectl describe pod liveness-probe-demo

The event log will now show the liveness probe that began to fail after the container deleted its /healthcheck file. The event discloses the output from the liveness probe’s command. If you used a different probe type, such as HTTP or TCP, you would see relevant information such as the HTTP status code instead.

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, from this article, you have learned why and when to use liveness probes. The types of probes that are available. Even how you can start attaching them to your pods.