Startup, Liveness and Readiness Probes in Kubernetes: A Practical Guide

What is Kubernetes?

Kubernetes is an open source container orchestration engine for automating deployment, scaling, and management of containerized applications. It’s supported by all hyperscaller cloud providers and widely used by different companies. Amazon, Google, IBM, Microsoft, Oracle, Red Hat, SUSE, Platform9, IONOS and VMware offer Kubernetes-based platforms or infrastructure as a service (IaaS) that deploy Kubernetes.

What is a prope in Kubernetes?

A Prope is a health check that is triggered by the kublet to automatically determine if a pod can accept traffic or not. There are four options

• httpGet: HTTP check based on the response status code. Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure.
• exec: Check the command’s exit status. If it's zero (0), it indicates success otherwise it's considered failure.
• tcpSocket: The kubelet will attempt to open a TCP socket connection to your container on the specified port. If it connects successfully, the container is considered healthy, otherwise it's a failure.
• grpc: The kubelet will use gRPC health checking protocol to check if your container is able to handle RPC calls or not.

Prope common fields

• initialDelaySeconds: Number of seconds after the container has started before the probes are initiated. Defaults to zero (0) seconds.
• periodSeconds: How often (in seconds) to perform the probe. Default to 10 seconds.
• timeoutSeconds: Number of seconds after which the probe times out. Defaults to 1 second.
• successThreshold: Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup Probes.
• failureThreshold: When a probe fails, Kubernetes will try failureThreshold times before giving up. Defaults to 3.

Startup Prope

A startup probe verifies whether the application within a container is started. It runs before any other probe, and, unless it finishes successfully, disables other probes. If a container fails its startup probe, then the container is killed and follows the pod’s restartPolicy.

This type of probe is only executed at startup, unlike readiness probes, which are run periodically.

The startup probe is configured in the spec.containers.startupprobe attribute of the pod configuration.

Readiness Prope

A readiness prope verifies whether the application within a container is ready to accept traffic. If it fails for failureThreshold times, the pod will be restarted. It is configured in the spec.containers.readinessprobe attribute of the pod configuration.

Liveness Prope

A liveness prope verifies whether the application within a container is healthy. If it fails for failureThreshold times, the pod will be killed and restarted. It is configured in the spec.containers.livenessprobe attribute of the pod configuration.

Examples

Here is a deployment that uses startup, readiness and liveness http propes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-example-deployment
spec:
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      — name: example-app
        image: nginx
        startupProbe:
          httpGet:
            path: /start
            port: named-port
          failureThreshold: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          successThreshold: 3
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
            httpHeaders:
              - name: example
                value: header
          initialDelaySeconds: 3
          periodSeconds: 3

In this example, We use different endpoint for readiness and liveness propes. This is the best practice because in the readiness prope, we might need to check all dependencies are up which might take some time and resources but in the liveness prope, since it's called periodically, we want to get a response as quickly as possible to respond to deadlock fast.

Here is a deployment that uses readiness exec prope and liveness tcpSocket prope:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-example-deployment
spec:
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      — name: example-app
        image: nginx
        readinessProbe:
          exec:
            command:
              - cat
              - /tmp/healthy
          initialDelaySeconds: 5
          periodSeconds: 5
        livenessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Here is an example pod that uses grpc liveness prope:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: grpc-prope
    image: nginx
    ports:
    - containerPort: 2379
    livenessProbe:
      grpc:
        port: 2379
        service: my-service
      initialDelaySeconds: 10

Conclusion

Using readiness and liveness propes is recommended to enable kubernetes to start sending traffic to your container only when it's ready to handle them. It also helps your application to recover automatically when a deadlock occurs but you need to configure your readiness or liveness prope correctly because it might cause your application to never start if the  failureThreshold is too low for example. it also might cause your application to take long time when restarting if the initialDelaySeconds or periodSeconds are too high.