Kubernetes: Configuring Health Checks in Pods (Examples & Best Practices)

Introduction

Kubernetes, the powerful container orchestration system, provides features to ensure that deployed applications are running as expected. One of the key methods for maintaining reliable services is through the use of health checks. This tutorial will give you an understanding of how health checks can be configured in Kubernetes Pods, which are the basic deployable units in Kubernetes. Along the way, we’ll look at examples and share best practices for creating effective health checks.

Understanding Liveness and Readiness Probes

In Kubernetes, there are two main types of health checks: liveness probes and readiness probes. A liveness probe tells Kubernetes when to restart a container, indicating that the application inside is no longer working correctly. On the other hand, a readiness probe indicates that the container is not ready to handle requests.

Both probes can execute different actions:

• Executing a command inside the container
• Performing a TCP socket check
• Making an HTTP GET request against the container

Configuring a Basic Liveness Command Probe

When you define a Pod, you can specify a liveness probe for each container in the Pod’s spec. A basic liveness command probe executes a command inside a container. If the command returns a zero exit status, the probe is considered successful.

apiVersion: v1
kind: Pod
metadata:
 name: liveness-exec
spec:
 containers:
 - name: liveness
   image: k8s.gcr.io/busybox
   args:
   - /bin/sh
   - -c
   - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
   livenessProbe:
     exec:
       command:
       - cat
       - /tmp/healthy
     initialDelaySeconds: 3
     periodSeconds: 5

This configuration defines a Pod with a single container running the BusyBox image. The command `touch /tmp/healthy` creates a file. The liveness probe checks for the existence of this file every 5 seconds after an initial delay of 3 seconds. If the file is missing, Kubernetes restarts the container.

Advanced Liveness Probe – HTTP GET

An HTTP GET liveness probe is another common way to check the health of a container. The probe sends an HTTP GET request to the container’s IP address on a specified port and path. By default, if the HTTP response code is 200-399, it’s successful.

apiVersion: v1
kind: Pod
metadata:
 name: liveness-http
spec:
 containers:
 - name: liveness
   image: k8s.gcr.io/liveness
   ports:
   - containerPort: 8080
   livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
       httpHeaders:
       - name: Custom-Header
         value: Awesome
     initialDelaySeconds: 3
     periodSeconds: 5

In this example, the liveness probe performs an HTTP GET request to `/healthz` on port 8080 with a custom header. If the system becomes unhealthy, the container is restarted.

Readiness Probes: Ensuring Availability

While liveness probes are crucial for self-healing, readiness probes are essential for managing application load. If a container fails its readiness probe, it gets removed from the list of endpoints that receive traffic, giving it time to recover without affecting the end users.

apiVersion: v1
kind: Pod
metadata:
 name: readiness-exec
spec:
 containers:
 - name: readiness
   image: k8s.gcr.io/readiness
   ports:
   - containerPort: 8080
   readinessProbe:
     exec:
       command:
       - cat
       - /tmp/ready
     initialDelaySeconds: 5
     periodSeconds: 5

In this scenario, the container is considered ready when the file `/tmp/ready` exists. The readiness probe is executed every 5 seconds after a 5 seconds’ initial delay.

Configuring Probes with the kubectl

The `kubectl` command-line tool also provides mechanisms to define liveness and readiness probes. Using `kubectl` can be more convenient for quick changes and testing:

kubectl set probe deployment/myapp --liveness --get-url=http://:8080/healthz
kubectl set probe deployment/myapp --readiness --get-url=http://:8080/ready

These commands set liveness and readiness probes on the `myapp` deployment that perform HTTP GET requests on the specified URLs.

Best Practices

1. Set initialDelaySeconds carefully, especially if your application takes a while to start. 2. Avoid aggressive intervals and thresholds. Frequent probing can impact performance and may lead to unnecessary restarts. 3. Use readiness probes to handle application initialization and temporary unavailability elegantly. 4. Log probe activity and examine it frequently to fine-tune your setup. 5. Monitor and alert on probe failures to detect and respond to issues promptly.

Conclusion

In this tutorial, we’ve covered the basics of Kubernetes health checks, including how to configure and apply liveness and readiness probes within your Pods. Examples ranged from simple exec commands to more advanced HTTP GET probes. Remember the best practices to ensure that your health checks are effective without being too aggressive.