Exec probe configuration in Kubernetes - Commands & Configuration

Introduction

Sometimes, you want Kubernetes to check if your app inside a container is working well. Exec probes let Kubernetes run a command inside the container to see if it is healthy. If the command fails, Kubernetes knows the app might have a problem and can restart it.

When you want to check if a web server inside a container is running by running a command that tests its status.

When your app does not listen on a network port but can be checked by running a script inside the container.

When you want Kubernetes to restart a container automatically if a specific command inside it fails.

When you want to make sure a database inside a container is ready by running a command that checks its status.

When you want to avoid restarting a container unnecessarily by running a quick command to confirm health.

Config File - pod.yaml

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: exec-probe-pod
spec:
  containers:
  - name: my-app
    image: busybox
    command: ["sh", "-c", "sleep 3600"]
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

This YAML file creates a pod with one container running a simple busybox image that sleeps for an hour.

The livenessProbe uses an exec command to check if the file /tmp/healthy exists inside the container.

If the file is missing, the probe fails and Kubernetes restarts the container.

initialDelaySeconds waits 5 seconds before starting the checks, and periodSeconds runs the check every 5 seconds.

Commands

This command creates the pod with the exec liveness probe configured. Kubernetes will start the container and begin health checks after the initial delay.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/exec-probe-pod created

This command shows the status of the pod to verify it is running and ready after creation.

Terminal

kubectl get pods

Expected Output

NAME             READY   STATUS    RESTARTS   AGE

exec-probe-pod   1/1     Running   0          10s

This command creates the file /tmp/healthy inside the container so the exec probe will succeed and keep the container healthy.

Terminal

kubectl exec exec-probe-pod -- sh -c 'touch /tmp/healthy'

Expected Output

No output (command runs silently)

This command removes the file /tmp/healthy inside the container to simulate a failure. The exec probe will fail and Kubernetes will restart the container.

Terminal

kubectl exec exec-probe-pod -- rm /tmp/healthy

Expected Output

No output (command runs silently)

Check the pod status again to see if Kubernetes restarted the container after the exec probe failed.

Terminal

kubectl get pods

Expected Output

NAME             READY   STATUS    RESTARTS   AGE

exec-probe-pod   1/1     Running   1          1m

Key Concept

If you remember nothing else from this pattern, remember: exec probes run a command inside the container to check health and trigger restarts if the command fails.

Common Mistakes

Not setting initialDelaySeconds causing the probe to run before the app is ready.

The probe may fail immediately and restart the container unnecessarily.

Set initialDelaySeconds to wait enough time for the app to start before probing.

Using a command that always succeeds or never fails.

The probe will never detect real problems, so unhealthy containers won't restart.

Use a command that accurately reflects the app's health status.

Not testing the exec command manually inside the container before adding it to the probe.

If the command is wrong or missing, the probe will always fail.

Run the command inside the container with kubectl exec to verify it works as expected.

Summary

Create a pod YAML with a livenessProbe using exec to run a command inside the container.

Apply the YAML with kubectl apply and check pod status with kubectl get pods.

Use kubectl exec to create or remove files or run commands inside the container to test the probe.

Kubernetes restarts the container automatically if the exec probe command fails.

Practice

1. What is the main purpose of an exec probe in Kubernetes?

easy

A. To schedule pods on specific nodes

B. To expose container ports to the outside world

C. To create persistent storage volumes

D. To run a command inside a container to check if it is healthy

Solution

1. Step 1: Understand exec probe functionality

   An exec probe runs a command inside the container to check its health status.

2. Step 2: Compare with other options

   Options A, B, and D relate to scheduling, networking, and storage, not health checks.

3. Final Answer:

   To run a command inside a container to check if it is healthy -> Option D

4. Quick Check:

   Exec probe = runs command inside container [OK]

Hint: Exec probe runs commands inside container to check health [OK]

Common Mistakes:

• Confusing exec probe with port exposure
• Thinking exec probe schedules pods
• Mixing exec probe with storage management

2. Which of the following is the correct syntax snippet to define an exec liveness probe in a pod spec?

easy

A. livenessProbe:\n exec:\n command: ['cat', '/tmp/healthy']\n initialDelaySeconds: 5\n periodSeconds: 10

B. livenessProbe:\n httpGet:\n path: /healthz\n port: 8080\n initialDelaySeconds: 5

C. livenessProbe:\n exec:\n command: 'cat /tmp/healthy'\n initialDelaySeconds: 5

D. livenessProbe:\n exec:\n command: cat /tmp/healthy\n initialDelaySeconds: 5

Solution

1. Step 1: Check exec command format

   The command must be an array of strings, e.g., ['cat', '/tmp/healthy'].

2. Step 2: Validate YAML structure

   livenessProbe:\n exec:\n command: ['cat', '/tmp/healthy']\n initialDelaySeconds: 5\n periodSeconds: 10 correctly uses the array syntax and includes initialDelaySeconds and periodSeconds.

3. Final Answer:

   Correct exec probe with command array and delays -> Option A

4. Quick Check:

   Exec command = array of strings [OK]

Hint: Exec command must be a list of strings in YAML [OK]

Common Mistakes:

• Using a single string instead of array for command
• Confusing exec probe with httpGet probe
• Omitting required indentation or keys

3. Given this exec probe configuration in a pod spec:

livenessProbe:
  exec:
    command: ['test', '-f', '/tmp/healthy']
  initialDelaySeconds: 3
  periodSeconds: 5

What happens if the file /tmp/healthy does not exist inside the container?

medium

A. The probe ignores the missing file and logs a warning

B. The probe passes and container continues running

C. The probe fails and Kubernetes restarts the container after retries

D. The container is immediately deleted without restart

Solution

1. Step 1: Understand exec probe command

   The command 'test -f /tmp/healthy' returns success if the file exists, failure if not.

2. Step 2: Effect of probe failure

   If the probe fails repeatedly, Kubernetes restarts the container to recover.

3. Final Answer:

   The probe fails and Kubernetes restarts the container after retries -> Option C

4. Quick Check:

   Missing file = probe fails = restart [OK]

Hint: Missing file causes exec probe failure and container restart [OK]

Common Mistakes:

• Assuming probe passes if file missing
• Thinking container deletes without restart
• Believing probe ignores errors silently

4. You configured an exec readiness probe but your pod never becomes ready. Which of these is the most likely cause?

medium

A. The exec command is missing the command array syntax and uses a single string

B. The initialDelaySeconds is set too high

C. The container image is missing

D. The pod has no resource limits defined

Solution

1. Step 1: Check exec command syntax

   Exec probe commands must be an array of strings; a single string causes probe failure.

2. Step 2: Understand probe failure effect

   If the probe fails, the pod is not marked ready, so it never becomes ready.

3. Final Answer:

   Exec command missing array syntax causes probe failure -> Option A

4. Quick Check:

   Exec command array syntax missing = probe fails [OK]

Hint: Exec command must be array; single string causes failure [OK]

Common Mistakes:

• Ignoring command array syntax errors
• Blaming initialDelaySeconds without checking command
• Confusing readiness with resource limits

5. You want to configure an exec liveness probe that waits 10 seconds before starting, runs the command ['/bin/check.sh'], retries every 5 seconds, and fails after 3 unsuccessful attempts. Which is the correct YAML snippet?

hard

A. livenessProbe:\n exec:\n command: '/bin/check.sh'\n initialDelaySeconds: 10\n periodSeconds: 5\n failureThreshold: 3

B. livenessProbe:\n exec:\n command: ['/bin/check.sh']\n initialDelaySeconds: 10\n periodSeconds: 5\n failureThreshold: 3

C. livenessProbe:\n exec:\n command: ['/bin/check.sh']\n initialDelaySeconds: 5\n periodSeconds: 10\n failureThreshold: 3

D. livenessProbe:\n exec:\n command: ['/bin/check.sh']\n initialDelaySeconds: 10\n periodSeconds: 5\n failureThreshold: 1

Solution

1. Step 1: Verify command syntax and initial delay

   Command must be an array; initialDelaySeconds must be 10 as required.

2. Step 2: Check periodSeconds and failureThreshold

   PeriodSeconds should be 5 for retry every 5 seconds; failureThreshold 3 means fail after 3 tries.

3. Final Answer:

   Correct YAML with command array, initialDelaySeconds 10, periodSeconds 5, failureThreshold 3 -> Option B

4. Quick Check:

   Command array + delays + failureThreshold correct = livenessProbe:\n exec:\n command: ['/bin/check.sh']\n initialDelaySeconds: 10\n periodSeconds: 5\n failureThreshold: 3 [OK]

Hint: Use array for command and set delays and failureThreshold as numbers [OK]

Common Mistakes:

• Using string instead of array for command
• Swapping periodSeconds and initialDelaySeconds values
• Setting failureThreshold too low or missing