Readiness probe concept in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a readiness probe that checks HTTP path '/ready'.

Kubernetes

readinessProbe:
  httpGet:
    path: [1]
    port: 8080

Drag options to blanks, or click blank then click option'

A/status

B/health

C/ready

D/check

Attempts:

3 left

💡 Hint

Common Mistakes

Using a liveness probe path instead of readiness probe path.

Using a path that does not exist in the container.

The readiness probe uses the HTTP path '/ready' to check if the container is ready to receive traffic.

2fill in blank

medium

Complete the code to set the readiness probe initial delay to 5 seconds.

Kubernetes

readinessProbe:
  initialDelaySeconds: [1]

Drag options to blanks, or click blank then click option'

A5

B0

C10

D15

Attempts:

3 left

💡 Hint

Common Mistakes

Setting initialDelaySeconds to 0 which may cause premature checks.

Using a very high delay causing slow readiness detection.

The initialDelaySeconds field sets how long Kubernetes waits before starting readiness checks. Here it is set to 5 seconds.

3fill in blank

hard

Fix the error in the readiness probe port number (should be 8080).

Kubernetes

readinessProbe:
  httpGet:
    path: /ready
    port: [1]

Drag options to blanks, or click blank then click option'

A80

B8080

C443

D3000

Attempts:

3 left

💡 Hint

Common Mistakes

Using default HTTP port 80 when the app listens on 8080.

Using HTTPS port 443 incorrectly.

The readiness probe must use the correct port 8080 where the container serves readiness requests.

4fill in blank

hard

Fill both blanks to set readiness probe timeout to 3 seconds and period to 10 seconds.

Kubernetes

readinessProbe:
  timeoutSeconds: [1]
  periodSeconds: [2]

Drag options to blanks, or click blank then click option'

A3

B5

C10

D15

Attempts:

3 left

💡 Hint

Common Mistakes

Setting timeoutSeconds longer than periodSeconds.

Using very high values causing slow detection.

timeoutSeconds is set to 3 to limit probe wait time, and periodSeconds is set to 10 to check every 10 seconds.

5fill in blank

hard

Fill all three blanks to define a readiness probe with exec command 'cat /tmp/ready', initial delay 5, and failure threshold 3.

Kubernetes

readinessProbe:
  exec:
    command: [[1]]
  initialDelaySeconds: [2]
  failureThreshold: [3]

Drag options to blanks, or click blank then click option'

Acat /tmp/ready

B5

C3

Dls /tmp

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong exec command that does not check readiness.

Setting failureThreshold too low causing false failures.

The exec command checks the file '/tmp/ready' to confirm readiness. Initial delay is 5 seconds, and failure threshold is 3 retries.

Practice

1. What is the main purpose of a readiness probe in Kubernetes?

easy

A. To tell Kubernetes when a container is ready to receive traffic

B. To restart a container if it crashes

C. To monitor the CPU usage of a container

D. To update the container image automatically

Solution

1. Step 1: Understand readiness probe role

   A readiness probe checks if a container is ready to accept requests, preventing traffic to unready containers.

2. Step 2: Compare with other options

   Other options describe different Kubernetes features: restarts (liveness probe), monitoring (metrics), and updates (deployments).

3. Final Answer:

   To tell Kubernetes when a container is ready to receive traffic -> Option A

4. Quick Check:

   Readiness probe = container readiness [OK]

Hint: Readiness probe controls traffic flow to containers [OK]

Common Mistakes:

• Confusing readiness probe with liveness probe
• Thinking readiness probe restarts containers
• Assuming readiness probe monitors resource usage

2. Which of the following is a valid way to define a readiness probe in a Kubernetes pod spec?

easy

A. readinessProbe:
httpGet:
path: /health
port: 8080

B. readinessProbe:
restartPolicy: Always

C. readinessProbe:
exec:
command: ["curl", "-f", "http://localhost:8080"]

D. readinessProbe:
tcpSocket:
port: 8080

Solution

1. Step 1: Review readiness probe types

   Valid readiness probes include httpGet, tcpSocket, and exec commands.

2. Step 2: Check syntax correctness

   readinessProbe: httpGet: path: /health port: 8080 is now correctly indented. readinessProbe: exec: command: ["curl", "-f", "http://localhost:8080"] uses exec with correct command syntax as a list of strings. readinessProbe: tcpSocket: port: 8080 correctly defines tcpSocket with port. readinessProbe: restartPolicy: Always is invalid because restartPolicy is not part of readiness probe.

3. Final Answer:

   readinessProbe with tcpSocket and port -> Option D

4. Quick Check:

   Valid readiness probe syntax = tcpSocket [OK]

Hint: Check indentation and valid probe keys for readiness probe [OK]

Common Mistakes:

• Misplacing restartPolicy inside readinessProbe
• Incorrect command format in exec probe
• Wrong indentation causing YAML errors

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

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

What happens if the HTTP GET request to /ready returns status 503?

medium

A. Kubernetes ignores the failure and continues sending traffic

B. Kubernetes restarts the container immediately

C. Kubernetes marks the container as not ready and stops sending traffic

D. Kubernetes deletes the pod

Solution

1. Step 1: Understand readiness probe failure effect

   If the readiness probe fails (like HTTP 503), Kubernetes marks the container as not ready and stops routing traffic to it.

2. Step 2: Differentiate from liveness probe

   Liveness probe failure causes restarts, but readiness probe failure only affects traffic routing, not container lifecycle.

3. Final Answer:

   Kubernetes marks the container as not ready and stops sending traffic -> Option C

4. Quick Check:

   Readiness failure = no traffic [OK]

Hint: Readiness failure stops traffic, does not restart container [OK]

Common Mistakes:

• Confusing readiness probe failure with liveness probe failure
• Assuming container restarts on readiness failure
• Thinking pod gets deleted on readiness failure

4. You defined this readiness probe in your pod YAML:

readinessProbe:
  exec:
    command: ["cat", "/tmp/ready"]
  initialDelaySeconds: 5
  periodSeconds: 10

But Kubernetes always marks the pod as not ready. What is the most likely cause?

medium

A. The exec command syntax is invalid

B. The file /tmp/ready does not exist or is empty

C. initialDelaySeconds is too short

D. periodSeconds is too long

Solution

1. Step 1: Understand exec readiness probe behavior

   The exec probe runs the command; it expects a zero exit code for success. If the file /tmp/ready does not exist, cat returns non-zero, causing failure.

2. Step 2: Check other options

   Command syntax is valid. Timing values affect delay but not constant failure. So the missing or unreadable file is the cause.

3. Final Answer:

   The file /tmp/ready does not exist or is empty -> Option B

4. Quick Check:

   Exec probe success = command exit code 0 [OK]

Hint: Exec probe needs command to succeed (exit code 0) [OK]

Common Mistakes:

• Assuming timing values cause readiness failure
• Misunderstanding exec command success criteria
• Ignoring file existence for exec probes

5. You want to ensure your web server container only receives traffic after it finishes loading configuration and opens port 8080. Which readiness probe setup best achieves this?

hard

A. Use an exec readiness probe that runs a script checking config file and port status

B. Use an HTTP GET readiness probe on path /health with periodSeconds set to 1

C. Use a TCP socket readiness probe on port 8080 with initialDelaySeconds set to 10

D. Use a liveness probe instead of readiness probe to check port 8080

Solution

1. Step 1: Analyze readiness probe requirements

   The container must be ready only after config is loaded and port is open. TCP socket or HTTP GET alone cannot check config loading.

2. Step 2: Evaluate probe options

   Use a TCP socket readiness probe on port 8080 with initialDelaySeconds set to 10 checks only port open after delay, Use an HTTP GET readiness probe on path /health with periodSeconds set to 1 checks HTTP path frequently but not config. Use an exec readiness probe that runs a script checking config file and port status runs a script that can verify both config and port, making it the best choice. Use a liveness probe instead of readiness probe to check port 8080 is wrong because liveness probes do not control traffic routing.

3. Final Answer:

   Use an exec readiness probe that runs a script checking config file and port status -> Option A

4. Quick Check:

   Complex readiness checks need exec probe [OK]

Hint: Use exec probe for multi-condition readiness checks [OK]

Common Mistakes:

• Using liveness probe instead of readiness probe
• Relying only on TCP or HTTP probes for config readiness
• Ignoring initialDelaySeconds impact on readiness