Exec probe configuration in Kubernetes - Deep Dive

Overview - Exec probe configuration

What is it?

Exec probe configuration in Kubernetes is a way to check the health of a container by running a command inside it. Kubernetes runs this command periodically to see if the container is working properly. If the command succeeds, the container is considered healthy; if it fails, Kubernetes can restart or stop the container. This helps keep applications running smoothly without manual checks.

Why it matters

Without exec probes, Kubernetes would not know if a container is stuck or broken inside. This could lead to bad user experiences or downtime because unhealthy containers keep running. Exec probes automate health checks, so Kubernetes can fix problems quickly by restarting containers. This makes applications more reliable and reduces manual work for operators.

Where it fits

Before learning exec probes, you should understand basic Kubernetes concepts like pods and containers. After this, you can learn about other probe types like HTTP and TCP probes, and then explore advanced health check strategies and custom readiness checks.

Mental Model

Core Idea

An exec probe runs a command inside a container to check if it is healthy and responsive.

Think of it like...

It's like a doctor checking your heartbeat by listening inside your chest; if the heartbeat is normal, you are healthy, otherwise you need attention.

┌─────────────────────────────┐
│ Kubernetes Node             │
│ ┌─────────────────────────┐ │
│ │ Pod                     │ │
│ │ ┌─────────────────────┐ │ │
│ │ │ Container           │ │ │
│ │ │ ┌───────────────┐  │ │ │
│ │ │ │ Exec Probe    │──┼─┼─┤ Runs command inside container
│ │ │ └───────────────┘  │ │ │
│ │ └─────────────────────┘ │ │
│ └─────────────────────────┘ │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is an Exec Probe

Concept: Exec probe is a Kubernetes feature that runs a command inside a container to check its health.

In Kubernetes, an exec probe runs a specified command inside a container. If the command exits with status 0, the container is healthy. If it exits with any other status, the container is unhealthy. This check happens regularly based on configured intervals.

Result

Kubernetes knows if the container is healthy or not by the command's exit status.

Understanding that Kubernetes can run commands inside containers to check health is key to grasping how exec probes work.

2

Foundation

Basic Exec Probe Configuration Syntax

Concept: How to write the exec probe section in a pod's YAML manifest.

An exec probe is defined under the 'livenessProbe' or 'readinessProbe' field in the container spec. It uses the 'exec' key with a 'command' array. Example: livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 10

Result

Kubernetes will run 'cat /tmp/healthy' inside the container every 10 seconds after an initial delay of 5 seconds.

Knowing the YAML structure lets you configure exec probes correctly to monitor container health.

3

Intermediate

Difference Between Liveness and Readiness Probes

🤔Before reading on: do you think liveness and readiness probes do the same thing? Commit to your answer.

Concept: Liveness probes check if a container should be restarted; readiness probes check if a container is ready to serve traffic.

Liveness probes detect if a container is stuck or dead. If it fails, Kubernetes restarts the container. Readiness probes check if the container is ready to accept requests. If it fails, Kubernetes stops sending traffic to it but does not restart it.

Result

You can control container lifecycle and traffic flow separately using exec probes.

Understanding the different roles of liveness and readiness probes helps you design better health checks.

4

Intermediate

Configuring Timing Parameters for Exec Probes

🤔Before reading on: do you think setting very short probe intervals is always better? Commit to your answer.

Concept: Exec probes have timing settings like initial delay, timeout, period, and failure threshold to control how often and when they run.

Key timing parameters: - initialDelaySeconds: wait before first probe - periodSeconds: how often to run - timeoutSeconds: max time to wait for command - failureThreshold: how many failures before action Example: livenessProbe: exec: command: ["/bin/check.sh"] initialDelaySeconds: 10 periodSeconds: 5 timeoutSeconds: 2 failureThreshold: 3

Result

Kubernetes runs the probe every 5 seconds after waiting 10 seconds initially, and restarts container after 3 failures.

Knowing how to tune timing prevents false positives and ensures timely detection of issues.

5

Intermediate

Common Commands Used in Exec Probes

Concept: Typical commands used in exec probes check for files, processes, or custom scripts inside containers.

Examples: - cat /tmp/healthy (checks if file exists) - pgrep myprocess (checks if process runs) - /bin/check.sh (custom script returning 0 or 1) Commands must be quick and reliable to avoid probe timeouts.

Result

Exec probes can be customized to check any condition inside the container.

Choosing the right command is critical for accurate health detection without slowing down the container.

6

Advanced

Handling Exec Probe Failures Gracefully

🤔Before reading on: do you think Kubernetes immediately kills a container on first exec probe failure? Commit to your answer.

Concept: Kubernetes uses failureThreshold and grace periods to avoid restarting containers on transient failures.

If an exec probe fails, Kubernetes waits until failureThreshold is reached before restarting. This avoids restarts from temporary glitches. You can also combine exec probes with readiness probes to control traffic flow during recovery.

Result

Containers are not restarted unnecessarily, improving stability.

Understanding failure thresholds helps prevent flapping and improves application uptime.

7

Expert

Exec Probe Limitations and Security Considerations

🤔Before reading on: do you think exec probes can run any command without restrictions? Commit to your answer.

Concept: Exec probes run commands inside containers but have limitations and security risks if misused.

Exec probes require the container to have the command available and permissions to run it. Running complex or slow commands can cause probe failures. Also, exec probes expose an attack surface if commands are not secure. Best practice is to keep commands simple and safe. Some environments restrict exec probes for security reasons.

Result

Exec probes must be designed carefully to avoid security and reliability issues.

Knowing exec probe limits and risks helps design secure and robust health checks.

Under the Hood

Kubernetes kubelet runs the exec probe command inside the container's namespace using container runtime APIs. It waits for the command to finish and checks the exit code. Exit code 0 means success; any other code means failure. The kubelet uses this result to update the container's health status and trigger restarts or traffic routing changes.

Why designed this way?

Exec probes were designed to allow flexible, custom health checks inside containers without requiring network access. Running commands inside the container gives direct insight into its state. Alternatives like HTTP probes require the container to expose endpoints, which is not always possible or desired.

┌───────────────┐
│ Kubernetes    │
│ kubelet       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Container     │
│ Runtime API   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Exec Probe    │
│ Command Runs  │
│ Inside Container│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Exit Code     │
│ 0 = Healthy  │
│ !=0 = Failure│
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: does a failing exec probe always mean the container is broken? Commit yes or no.

Common Belief: If an exec probe fails, the container is definitely broken and must be restarted immediately.

Reality: Exec probe failures can be temporary or caused by slow commands; Kubernetes waits for multiple failures before restarting.

Why it matters: Restarting containers on transient failures causes unnecessary downtime and instability.

Quick: can exec probes check external services? Commit yes or no.

Common Belief: Exec probes can check if external services are reachable by running network commands inside the container.

Reality: Exec probes only check inside the container; they cannot directly verify external dependencies' health.

Why it matters: Relying on exec probes for external checks can give false health signals and hide real issues.

Quick: do exec probes run commands as root by default? Commit yes or no.

Common Belief: Exec probes always run commands with root privileges inside the container.

Reality: Exec probes run commands with the container's user permissions, which may be non-root.

Why it matters: Assuming root privileges can cause probe failures if commands require higher permissions.

Quick: does exec probe output affect container logs? Commit yes or no.

Common Belief: The output of exec probe commands is logged and visible in container logs.

Reality: Exec probe command output is discarded by default and does not appear in container logs.

Why it matters: Debugging probe failures requires separate logging or command design since output is not captured.

Expert Zone

1

Exec probes can cause performance overhead if commands are slow or resource-intensive, impacting container responsiveness.

2

Combining exec probes with readiness probes allows graceful traffic shifting during container startup or recovery phases.

3

Some container runtimes or security policies restrict exec probe commands, requiring fallback to HTTP or TCP probes.

When NOT to use

Avoid exec probes when containers do not have the required commands or when security policies forbid exec commands. Use HTTP or TCP probes instead for network-accessible services.

Production Patterns

In production, exec probes often run lightweight scripts checking file existence or process status. They are combined with readiness probes to manage traffic and liveness probes to trigger restarts. Timing parameters are tuned to balance sensitivity and stability.

Connections

HTTP health probes

Alternative probe type with network checks instead of command execution

Understanding exec probes clarifies why HTTP probes are preferred for web services but exec probes are needed for non-networked health checks.

Container security policies

Exec probes run commands inside containers, which can be restricted by security settings

Knowing exec probe internals helps understand how security policies impact container health monitoring.

Medical diagnostics

Both exec probes and medical tests run internal checks to assess health status

Seeing exec probes as diagnostic tests helps appreciate the importance of timing, accuracy, and false positives in health monitoring.

Common Pitfalls

#1 Using a slow or blocking command in exec probe causing probe timeouts.

Wrong approach:

livenessProbe:
exec:
command: ["sleep", "10"]
timeoutSeconds: 1
periodSeconds: 5

Correct approach:

livenessProbe:
exec:
command: ["/bin/check_quick.sh"]
timeoutSeconds: 1
periodSeconds: 5

Root cause:

Misunderstanding that exec probe commands must complete quickly within timeout to avoid false failures.

#2 Configuring exec probe without initialDelaySeconds causing immediate failures on container start.

Wrong approach:

livenessProbe:
exec:
command: ["cat", "/tmp/healthy"]
periodSeconds: 10

Correct approach:

livenessProbe:
exec:
command: ["cat", "/tmp/healthy"]
initialDelaySeconds: 10
periodSeconds: 10

Root cause:

Not allowing container startup time before health checks leads to premature failure detection.

#3 Assuming exec probe output is logged and using it for debugging probe failures.

Wrong approach:

Relying on container logs to see exec probe command output for troubleshooting.

Correct approach:

Add logging inside the exec command script or use sidecar containers for detailed health check logs.

Root cause:

Not knowing exec probe output is discarded by default, making debugging harder.

Key Takeaways

Exec probes run commands inside containers to check their health by exit status.

They help Kubernetes decide when to restart containers or stop sending traffic.

Proper timing and command choice prevent false failures and improve stability.

Exec probes have security and performance limits that must be considered.

Combining exec probes with other probe types creates robust health monitoring.

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