Kubernetes — Liveness Probe and Readiness Probe

Let’s understand what is probe in k8s,First???

Probe: In Kubernetes, a probe is a mechanism for performing health checks on a container within a pod. Probes are essential for ensuring the availability and reliability of applications running in a Kubernetes cluster.

Liveness Probe:

In Kubernetes, a liveness probe is a mechanism used to determine if a container within a pod is still running and responsive. It is a part of the broader concept of container health checks, which are essential for ensuring the reliability and availability of applications in a Kubernetes cluster.

A liveness probe is configured with a set of conditions or actions that are periodically performed on a container. These conditions determine whether the container is considered “alive” or if it should be restarted. If the liveness probe fails, Kubernetes takes action, such as restarting the container, to help maintain the desired state of the application.

In Simple words:

A liveness probe determines,is container still running and responsive??. If the liveness probe fails (i.e., the configured check conditions are not met), Kubernetes considers the container to be unhealthy, and it may take actions such as restarting the container to attempt recovery.

Type of Liveness Probe:

The liveness probe is configured in the pod specification under the spec.containers.livenessProbe ,In Kubernetes, liveness probes can be configured using different types of actions to check the health of a container. The three main types of liveness probe actions are:

1.HTTP GET Probe:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

This type of probe sends an HTTP GET request to a specified path on the container’s IP address and port.

2. TCP Socket Probe:

livenessProbe:
  tcpSocket:
    port: 8080

This type of probe attempts to open a TCP connection to the specified port on the container.

3.Exec Probe:

livenessProbe:
  exec:
    command:
      - cat
      - /tmp/health

This type of probe runs a specified command inside the container. If the command exits with a zero status code, the container is considered healthy; otherwise, it is considered unhealthy.

Here’s a brief explanation of each type:

• HTTP GET Probe is useful for checking the health of web servers or applications that expose an HTTP endpoint for health checks.
• TCP Socket Probe is useful when you want to check if a specific port is open, which is common for services like databases.
• Exec Probe is more flexible, allowing you to run custom commands to check the health of your application. This can be useful for scenarios where a simple HTTP or TCP check might not be sufficient.

Time Related fields:

In Kubernetes, there are several time-related fields that you can use to configure the behavior of liveness probes. These fields determine when the probe should start, how often it should run, and other timing aspects. The primary time-related fields for liveness probes are:

1.initialDelaySeconds:

This field specifies the number of seconds after container has been started liveness probe is initiated for the first time. It provides the container with some time to perform any necessary initialization before health checks begin.Defaults to 0 seconds. Minimum value is 0.

2.periodSeconds:

The field sets the interval between consecutive liveness probe executions. The probe is repeated at regular intervals specified by this field.Default to 10 seconds. The minimum value is 1.

3.timeoutSeconds:

This field specifies the number of seconds after which the liveness probe should time out if it does not receive a response. If the probe takes longer than the timeout, it is considered failed.Defaults to 1 second. Minimum value is 1.

4.successThreshold:

These fields determine the number of consecutive successes required to consider the liveness probe as successful. For example, if successThreshold is set to 3, the liveness probe must succeed three times in a row to be considered successful.Defaults to 1. Must be 1 for liveness . Minimum value is 1.

5.failureThreshold:

This field specifies the number of times a liveness probe must fail in a row before the container is marked as unhealthy, triggering actions like restarting the container.

Below is an example YAML file for a Kubernetes Pod definition that includes a container with a liveness probe, incorporating various time-related fields:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 3
      successThreshold: 1
      failureThreshold: 3

Readiness Probe

In Kubernetes, a readiness probe is a mechanism used to determine whether a container is ready to serve traffic. It is an essential component for ensuring the stability and reliability of applications in a Kubernetes cluster. The primary purpose of a readiness probe is to indicate when a container is prepared to accept incoming network traffic.

A readiness probe differs from a liveness probe in that its purpose is not to check if the container is still running but to assess whether the container is ready to handle requests. When a container is not ready, Kubernetes may temporarily remove it from service, redirecting traffic away from the container until it becomes ready again. This is particularly useful during deployment or scaling scenarios when you want to ensure that a new version of your application is fully initialized before it starts receiving traffic.

A readiness probe can use various types of actions to perform the health check, similar to a liveness probe.

Below is an example YAML file for a Kubernetes Pod definition that includes a container with a readiness probe, incorporating various time-related fields:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myimage
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /readiness
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 15
      timeoutSeconds: 5
      successThreshold: 1
      failureThreshold: 3

That’s all..