Probe timing parameters (initialDelay, period, timeout) in Kubernetes - Commands & Configuration

Introduction

Kubernetes uses probes to check if your app is healthy and ready. Probe timing parameters control when and how often these checks happen, helping avoid false alarms and ensuring smooth app operation.

When your app needs some time to start before Kubernetes checks if it's ready

When you want Kubernetes to check your app's health regularly to restart it if it fails

When your app sometimes takes longer to respond and you want to avoid marking it unhealthy too soon

When you want to control how long Kubernetes waits for a probe response before considering it failed

Config File - pod.yaml

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx:1.23
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 2
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 3
      timeoutSeconds: 1

This pod configuration defines two probes: livenessProbe and readinessProbe.

• initialDelaySeconds sets how many seconds Kubernetes waits before starting the first probe after the container starts.
• periodSeconds sets how often Kubernetes runs the probe.
• timeoutSeconds sets how long Kubernetes waits for the probe to respond before marking it failed.

These settings help Kubernetes know when your app is ready and healthy.

Commands

This command creates the pod with the defined probes and their timing parameters.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/example-pod created

This command checks the status of the pod to see if it is running and ready.

Terminal

kubectl get pods example-pod

Expected Output

NAME          READY   STATUS    RESTARTS   AGE

example-pod   1/1     Running   0          10s

This command shows detailed information about the pod, including probe events and timing details.

Terminal

kubectl describe pod example-pod

Expected Output

Name:         example-pod

Namespace:    default

Containers:

  example-container:

    Container ID:   docker://abcdef123456

    Image:          nginx:1.23

    State:          Running

    Ready:          True

    Restart Count:  0

    Liveness:       http-get http://:80/healthz delay=10s timeout=2s period=5s

    Readiness:      http-get http://:80/ready delay=5s timeout=1s period=3s

Events:

  Type    Reason     Age   From               Message

  ----    ------     ----  ----               -------

  Normal  Scheduled  1m    default-scheduler  Successfully assigned default/example-pod to node-1

  Normal  Pulled     1m    kubelet            Container image "nginx:1.23" already present on machine

  Normal  Created    1m    kubelet            Created container example-container

  Normal  Started    1m    kubelet            Started container example-container

Key Concept

If you remember nothing else from this pattern, remember: initialDelaySeconds waits before first check, periodSeconds sets check frequency, and timeoutSeconds sets how long to wait for a response.

Common Mistakes

Setting initialDelaySeconds too low so probes start before the app is ready

Kubernetes may mark the app as unhealthy and restart it unnecessarily.

Set initialDelaySeconds to a value that matches your app's startup time.

Setting timeoutSeconds too low causing probes to fail if the app responds slowly

Probes fail even if the app is healthy but slow, causing restarts.

Set timeoutSeconds to a reasonable value that allows your app to respond.

Setting periodSeconds too high, so failures are detected too late

Kubernetes takes longer to detect and fix unhealthy apps.

Set periodSeconds to a balanced value for timely health checks without overload.

Summary

Define probe timing parameters in pod.yaml to control health and readiness checks.

Use kubectl apply to create the pod and kubectl get/describe to verify probe behavior.

Adjust initialDelaySeconds, periodSeconds, and timeoutSeconds to match your app's needs.

Practice

1. What does the initialDelaySeconds parameter control in a Kubernetes probe?

easy

A. The time to wait before the first probe check starts

B. The maximum time to wait for a probe response

C. The frequency of probe checks after the first one

D. The number of retries before marking the pod as failed

Solution

1. Step 1: Understand the role of initialDelaySeconds

   This parameter sets how long Kubernetes waits before performing the first probe check on a container.

2. Step 2: Differentiate from other timing parameters

   timeoutSeconds limits wait time per check, and periodSeconds sets how often checks repeat after the first.

3. Final Answer:

   The time to wait before the first probe check starts -> Option A

4. Quick Check:

   initialDelaySeconds = wait before first check [OK]

Hint: initialDelaySeconds delays first check only [OK]

Common Mistakes:

• Confusing initialDelaySeconds with timeoutSeconds
• Thinking it controls check frequency
• Assuming it sets retry count

2. Which of the following is the correct syntax to set a liveness probe with initialDelaySeconds of 10, periodSeconds of 5, and timeoutSeconds of 2 in a pod spec?

easy

A. livenessProbe:
initialDelaySeconds: '10'
periodSeconds: '5'
timeoutSeconds: '2'

B. livenessProbe:
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 2

C. livenessProbe:
initialDelay: 10
period: 5
timeout: 2

D. livenessProbe:
delayInitialSeconds: 10
periodSeconds: 5
timeoutSeconds: 2

Solution

1. Step 1: Check correct parameter names

   The correct keys are initialDelaySeconds, periodSeconds, and timeoutSeconds exactly as spelled.

2. Step 2: Validate value types and syntax

   Values should be integers without quotes. livenessProbe: initialDelaySeconds: 10 periodSeconds: 5 timeoutSeconds: 2 uses correct keys and integer values.

3. Final Answer:

   Correct YAML with proper keys and integer values -> Option B

4. Quick Check:

   Use exact keys and integer values [OK]

Hint: Use exact parameter names with integer values [OK]

Common Mistakes:

• Misspelling parameter names
• Using quotes around numbers
• Using incorrect keys like 'delayInitialSeconds'

3. Given this liveness probe configuration:

livenessProbe:
  initialDelaySeconds: 5
  periodSeconds: 10
  timeoutSeconds: 3

If the container starts at time 0, when will the first probe timeout occur if the probe command does not respond?

medium

A. At 15 seconds

B. At 5 seconds

C. At 10 seconds

D. At 8 seconds

Solution

1. Step 1: Calculate when first probe starts

   The first probe starts after initialDelaySeconds, so at 5 seconds.

2. Step 2: Add timeoutSeconds to find timeout moment

   The probe waits up to timeoutSeconds (3 seconds) for a response, so timeout occurs at 5 + 3 = 8 seconds.

3. Final Answer:

   At 8 seconds -> Option D

4. Quick Check:

   initialDelay + timeout = 8 seconds [OK]

Hint: Add initialDelaySeconds and timeoutSeconds for first timeout [OK]

Common Mistakes:

• Using periodSeconds instead of timeoutSeconds for timeout
• Forgetting to add initialDelaySeconds
• Assuming timeout happens at periodSeconds

4. You configured a readiness probe with initialDelaySeconds: 0, periodSeconds: 2, and timeoutSeconds: 5. The probe command hangs and never returns. What is the likely problem?

medium

A. initialDelaySeconds cannot be zero

B. periodSeconds must be greater than timeoutSeconds

C. timeoutSeconds is longer than periodSeconds, causing overlapping probes

D. timeoutSeconds must be less than 1 second

Solution

1. Step 1: Analyze timing relationship

   The probe runs every 2 seconds (periodSeconds) but waits up to 5 seconds (timeoutSeconds) for a response.

2. Step 2: Identify overlapping probes issue

   Since timeout is longer than period, new probes start before previous finish, causing overlap and possible resource issues.

3. Final Answer:

   timeoutSeconds is longer than periodSeconds, causing overlapping probes -> Option C

4. Quick Check:

   timeoutSeconds > periodSeconds causes overlap [OK]

Hint: timeoutSeconds should be less than or equal to periodSeconds [OK]

Common Mistakes:

• Thinking initialDelaySeconds cannot be zero
• Assuming timeoutSeconds must be less than 1
• Ignoring probe overlap effects

5. You want a startup probe to check a container's readiness only after 30 seconds, then check every 10 seconds, with each check timing out after 4 seconds. Which configuration correctly sets these parameters?

hard

A. startupProbe:
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 4

B. startupProbe:
initialDelaySeconds: 10
periodSeconds: 30
timeoutSeconds: 4

C. startupProbe:
initialDelaySeconds: 30
periodSeconds: 4
timeoutSeconds: 10

D. startupProbe:
initialDelaySeconds: 4
periodSeconds: 10
timeoutSeconds: 30

Solution

1. Step 1: Match each parameter to requirement

   initialDelaySeconds should be 30 to delay first check, periodSeconds 10 for check frequency, and timeoutSeconds 4 for max wait per check.

2. Step 2: Verify option correctness

   startupProbe: initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 4 matches all requirements exactly; others mix values incorrectly.

3. Final Answer:

   startupProbe with initialDelaySeconds 30, periodSeconds 10, timeoutSeconds 4 -> Option A

4. Quick Check:

   Match timing values to parameters exactly [OK]

Hint: Match each timing value to correct parameter name [OK]

Common Mistakes:

• Swapping periodSeconds and timeoutSeconds values
• Setting initialDelaySeconds too low
• Confusing startupProbe with livenessProbe