TCP probe configuration in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

TCP Probe Success Check

Given this Kubernetes pod spec snippet with a TCP liveness probe, what will be the status of the pod if the TCP port is open and responding?

Kubernetes

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

A The pod will be marked as healthy and continue running.

B The pod will restart immediately due to probe failure.

C The pod will be marked as unhealthy but not restarted.

D The pod will enter CrashLoopBackOff state.

💡 Hint

Think about what a successful TCP probe means for pod health.

A TCP liveness probe checks if the specified port is open. If it is, Kubernetes considers the pod healthy and does not restart it.

❓ Configuration

intermediate

Correct TCP Probe YAML Syntax

Which of the following YAML snippets correctly configures a TCP readiness probe on port 3306 with an initial delay of 15 seconds?

A

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelaySeconds: 15

B

readinessProbe:
  tcpSocket:
    port: "3306"
  initialDelaySeconds: 15

C

readinessProbe:
  tcpSocket:
    portNumber: 3306
  initialDelaySeconds: 15

D

readinessProbe:
  tcpSocket:
    port: 3306
  initialDelay: 15

💡 Hint

Check the exact field names and data types for TCP probes in Kubernetes.

The correct field for port is 'port' as an integer, and the delay field is 'initialDelaySeconds'. Quoting the port or using wrong field names causes errors.

❓ Troubleshoot

advanced

TCP Probe Fails Despite Open Port

A pod's TCP liveness probe on port 9090 keeps failing, but manual checks confirm the port is open and accepting connections. What is the most likely cause?

A The TCP probe port number is incorrectly specified as a string instead of an integer.

B The pod's container is not listening on 0.0.0.0 but only on localhost.

C The initialDelaySeconds is set too high, causing premature failures.

D The pod's CPU limits are too low, causing probe timeouts.

💡 Hint

Think about network interfaces and how probes connect to pods.

If the container listens only on localhost (127.0.0.1), the probe from Kubernetes cannot reach it via the pod IP, causing failures despite the port being open inside the container.

🔀 Workflow

advanced

Implementing a TCP Readiness Probe

You want to add a TCP readiness probe to a deployment to check port 8081 every 10 seconds with a 5-second initial delay. Which kubectl command applies this configuration correctly from a YAML file named 'probe.yaml'?

A kubectl set probe deployment/myapp --tcp=8081 --readiness --initial-delay=5 --period=10

B kubectl create tcp-probe -f probe.yaml

C kubectl apply -f probe.yaml

D kubectl edit deployment myapp --tcp-readiness-port=8081

💡 Hint

Remember how kubectl applies YAML configurations.

The 'kubectl apply -f' command applies the YAML file changes. Other commands are invalid or do not exist.

✅ Best Practice

expert

Best Practice for TCP Probe Configuration

Which practice is best when configuring TCP probes for a stateful application that takes time to start and open its port?

A Set initialDelaySeconds to 0 and timeoutSeconds to 1 for fast failure detection.

B Use HTTP probes instead of TCP probes for all stateful applications regardless of port availability.

C Disable probes entirely to prevent pod restarts during startup delays.

D Set a high initialDelaySeconds and a reasonable timeoutSeconds to avoid false failures during startup.

💡 Hint

Consider startup time and avoiding unnecessary restarts.

A high initial delay allows the app to start and open ports before probes begin. Reasonable timeout avoids marking the pod unhealthy too soon.