TCP probe configuration in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a TCP liveness probe port.

Kubernetes

livenessProbe:
  tcpSocket:
    port: [1]

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

A80

B8080

C443

D22

Attempts:

3 left

💡 Hint

Common Mistakes

Using a port number that the container does not listen on.

Using a string instead of a number for the port.

The TCP probe port is set to 80, which is a common HTTP port used for checking container health.

2fill in blank

medium

Complete the code to set the initial delay seconds for the TCP readiness probe.

Kubernetes

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: [1]

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

A5

B10

C0

D30

Attempts:

3 left

💡 Hint

Common Mistakes

Setting initialDelaySeconds too low causing false failures.

Using zero which may cause immediate probe failures.

Setting initialDelaySeconds to 10 gives the container time to start before Kubernetes checks readiness.

3fill in blank

hard

Fix the error in the TCP liveness probe configuration by completing the missing field.

Kubernetes

livenessProbe:
  tcpSocket:
    port: [1]
  periodSeconds: 15

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

Areadiness

Bhttp

Ctcp

D8080

Attempts:

3 left

💡 Hint

Common Mistakes

Using protocol names like 'http' or 'tcp' instead of port numbers.

Confusing readiness probe settings with liveness probe.

The port must be a number, such as 8080, not a protocol name or unrelated string.

4fill in blank

hard

Fill both blanks to configure a TCP readiness probe with a timeout and success threshold.

Kubernetes

readinessProbe:
  tcpSocket:
    port: [1]
  timeoutSeconds: [2]

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

A5432

B5

C10

D3306

Attempts:

3 left

💡 Hint

Common Mistakes

Using a port number that does not match the service.

Setting timeoutSeconds too high causing slow failure detection.

The port 3306 is for MySQL TCP readiness probe, and timeoutSeconds 5 means the probe waits 5 seconds before timing out.

5fill in blank

hard

Fill all three blanks to complete a TCP liveness probe with port, failure threshold, and period seconds.

Kubernetes

livenessProbe:
  tcpSocket:
    port: [1]
  failureThreshold: [2]
  periodSeconds: [3]

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

A8080

B3

C10

D15

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong port numbers.

Setting failureThreshold too low causing restarts.

Setting periodSeconds too high delaying failure detection.

Port 8080 is common for web apps, failureThreshold 3 means 3 failed probes before restart, and periodSeconds 10 means probe runs every 10 seconds.

Practice

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

easy

A. To check the container's memory usage

B. To monitor CPU usage of a container

C. To verify the container's file system integrity

D. To check if a container accepts TCP connections on a specified port

Solution

1. Step 1: Understand TCP probe function

   A TCP probe tests if a container is accepting TCP connections on a specific port.

2. Step 2: Compare with other options

   CPU, memory, and file system checks are not done by TCP probes but by other mechanisms.

3. Final Answer:

   To check if a container accepts TCP connections on a specified port -> Option D

4. Quick Check:

   TCP probe = connection check [OK]

Hint: TCP probe checks port connectivity, not resource usage [OK]

Common Mistakes:

• Confusing TCP probe with CPU or memory monitoring
• Thinking TCP probe checks file system health
• Assuming TCP probe checks HTTP endpoints

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

easy

A. livenessProbe:
tcpSocket:
path: "/health"
initialDelaySeconds: 5
periodSeconds: 10

B. livenessProbe:
httpGet:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

C. livenessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

D. livenessProbe:
exec:
command: ["curl", "localhost:8080"]
initialDelaySeconds: 5
periodSeconds: 10

Solution

1. Step 1: Identify TCP probe syntax

   TCP probes use tcpSocket with a port field, no path.

2. Step 2: Check options for correctness

   livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 uses tcpSocket with port 8080 and timing fields correctly. Others use HTTP or exec or invalid fields.

3. Final Answer:

   livenessProbe with tcpSocket and port field -> Option C

4. Quick Check:

   TCP probe syntax = tcpSocket + port [OK]

Hint: TCP probes use tcpSocket with port, no path [OK]

Common Mistakes:

• Using httpGet or exec instead of tcpSocket for TCP probes
• Adding a path field to tcpSocket (invalid)
• Omitting port number in tcpSocket

3. Given this pod spec snippet, what will happen if the container does not accept TCP connections on port 3306?

livenessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 10
  periodSeconds: 5

medium

A. Kubernetes will ignore the failure and keep the container running

B. Kubernetes will restart the container after the probe fails

C. The container will be marked ready immediately

D. The pod will be deleted permanently

Solution

1. Step 1: Understand liveness probe behavior

   Liveness probes check if a container is alive; failure triggers a restart.

2. Step 2: Apply to TCP probe failure

   If TCP connection on port 3306 fails, Kubernetes restarts the container to fix it.

3. Final Answer:

   Kubernetes will restart the container after the probe fails -> Option B

4. Quick Check:

   Liveness probe failure = container restart [OK]

Hint: Liveness probe failure triggers container restart [OK]

Common Mistakes:

• Confusing liveness with readiness probe effects
• Thinking pod is deleted permanently on failure
• Assuming failure is ignored

4. You configured a TCP readiness probe but Kubernetes reports probe failures immediately after pod start. Which is the most likely cause?

medium

A. initialDelaySeconds is missing or too low, so probe runs before container is ready

B. tcpSocket port is set to 0, which is invalid

C. periodSeconds is set too high, causing delayed checks

D. readinessProbe cannot use tcpSocket, only httpGet

Solution

1. Step 1: Analyze probe timing parameters

   Without initialDelaySeconds, probe starts immediately, possibly before container is ready.

2. Step 2: Evaluate other options

   Port 0 is invalid but would cause different errors; periodSeconds affects frequency, not immediate failure; tcpSocket is valid for readiness probes.

3. Final Answer:

   initialDelaySeconds is missing or too low, so probe runs before container is ready -> Option A

4. Quick Check:

   Missing initialDelaySeconds = early probe failure [OK]

Hint: Set initialDelaySeconds to delay probe start [OK]

Common Mistakes:

• Assuming tcpSocket is invalid for readiness probes
• Ignoring initialDelaySeconds importance
• Confusing periodSeconds with initialDelaySeconds

5. You want to configure a TCP readiness probe for a database container on port 5432. The container takes about 20 seconds to start accepting connections. Which configuration is best to avoid false failures?

hard

A. readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 25
periodSeconds: 10
failureThreshold: 3

B. readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 5
periodSeconds: 5
failureThreshold: 1

C. readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 0
periodSeconds: 10
failureThreshold: 5

D. readinessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 10
periodSeconds: 20
failureThreshold: 1

Solution

1. Step 1: Match initialDelaySeconds to container startup time

   Container needs ~20 seconds to accept connections, so initialDelaySeconds should be at least 20 to avoid early failures.

2. Step 2: Use periodSeconds and failureThreshold to allow retries

   Period of 10 seconds and failureThreshold of 3 means Kubernetes retries for up to 30 seconds before marking not ready, avoiding false negatives.

3. Final Answer:

   readinessProbe with initialDelaySeconds 25, periodSeconds 10, failureThreshold 3 -> Option A

4. Quick Check:

   Delay + retries prevent false failures [OK]

Hint: Set initialDelaySeconds > startup time, use retries [OK]

Common Mistakes:

• Setting initialDelaySeconds too low causing false failures
• Using failureThreshold of 1 with short delays
• Ignoring container startup time in probe config