Have Kubernetes on Your Side, Use Probes!

During your journey through the Kubernetes world, you have certainly come across some unfamiliar field in the manifest of some object. All objects that create Pods are considered basic in the cluster (Pod, Deployment, DaemonSet, StatefulSet, etc). Even so, they all have a huge number of fields for customizing our microservices. Today we will explore the Probes section to provide a brief explanation of their functionalities and share some basic examples to help you use them in your cluster.

All Pods running on the cluster nodes are managed by kubelet. It is the agent responsible for running Probes, which can be of the Liveness, Readiness, and Startup Probe types.

Liveness Probe

The Kubelet uses the Liveness Probe to restart application Pods if they stop returning successful responses to test requests. These can be simple commands, TCP, HTTP, or gRPC requests. This behavior is ideal for restarting the application in case of crashes, bugs, memory leaks, and other issues. 

An example below shows a Pod manifest configured to use the Liveness Probe with HTTP requests. 

apiVersion: v1

kind: Pod

metadata:

  labels:

    test: liveness

  name: liveness-http

spec:

  containers:

  - name: liveness

    image: registry.k8s.io/liveness

    args:

    - /server

    livenessProbe:

      httpGet:

        path: /healthz

        port: 8080

        httpHeaders:

        - name: Custom-Header

          value: Awesome

      initialDelaySeconds: 3

      periodSeconds: 3

The image used (registry.k8s.io/liveness) was purposely created to return an HTTP 200 status code during the first ten seconds of the Pod's life. After that, it returns 500. Upon applying this manifest to the cluster, we notice that the Pod is restarted shortly after that period, which means Kubelet plays its role by restarting the application in an attempt to solve the issue. In a real-world scenario, this failure response could indicate a serious problem in the Pod, making it desirable to provision a new one in its place.

From the cluster events shown above, we can see that the probe fails and receives the HTTP 500 code. Failing three consecutive times, the Kubelet restarts the Pod.

Readiness Probe

You may not always want to bring down the application in these failure scenarios. There is the option of just suspending it so that, for example, it can finish executing a critical routine. In this case, the Kubelet uses the Readiness Probe to stop sending requests to the application Pods if they stop returning successful responses to test requests. The configuration in the manifest is similar to Liveness, with only the initial field changing from livenessProbe to readinessProbe.

We will use the same image from the previous example to evaluate what changes in the Pod status when using readinessProbe:

apiVersion: v1

kind: Pod

metadata:

  labels:

    test: readiness

  name: readiness-http

spec:

  containers:

  - name: readiness

    image: registry.k8s.io/liveness

    args:

    - /server

    readinessProbe:

      httpGet:

        path: /healthz

        port: 8080

        httpHeaders:

        - name: Custom-Header

          value: Awesome

      initialDelaySeconds: 3

      periodSeconds: 3

For this simulation, we notice that, after the Pod starts up, the