TCP probe configuration in Kubernetes - Commands & Configuration

Introduction

Sometimes, you want to check if your app inside a container is ready or alive by testing if it can accept network connections. TCP probes help Kubernetes do this by trying to open a simple network connection to your app's port.

When you want Kubernetes to restart a container if it stops accepting network connections.

When you want to delay sending traffic to a container until it is ready to accept connections.

When your app does not have an HTTP endpoint but listens on a TCP port.

When you want a simple check to see if your app's port is open and responsive.

When you want to improve app reliability by automatically detecting and fixing network failures.

Config File - tcp-probe-pod.yaml

tcp-probe-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: tcp-probe-pod
spec:
  containers:
  - name: tcp-probe-container
    image: nginx:1.23
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 20

This file creates a pod running an nginx container.

The readinessProbe uses a TCP socket check on port 80 to see if the container is ready to accept traffic. It waits 5 seconds before starting checks and repeats every 10 seconds.

The livenessProbe also uses a TCP socket check on port 80 to see if the container is alive. It waits 15 seconds before starting and repeats every 20 seconds.

Commands

This command creates the pod with the TCP readiness and liveness probes configured. Kubernetes will start the pod and begin checking the TCP port.

Terminal

kubectl apply -f tcp-probe-pod.yaml

Expected Output

pod/tcp-probe-pod created

This command checks the status of the pod to see if it is running and ready based on the TCP probe results.

Terminal

kubectl get pods tcp-probe-pod

Expected Output

NAME             READY   STATUS    RESTARTS   AGE

tcp-probe-pod    1/1     Running   0          20s

This command shows detailed information about the pod, including the results of the TCP probes and any events related to container health.

Terminal

kubectl describe pod tcp-probe-pod

Expected Output

Name:         tcp-probe-pod

Namespace:    default

Priority:     0

Node:         minikube/192.168.49.2

Start Time:   Thu, 01 Jun 2023 12:00:00 +0000

Labels:       <none>

Annotations:  <none>

Status:       Running

IP:           172.17.0.5

Containers:

  tcp-probe-container:

    Container ID:   docker://abcdef123456

    Image:          nginx:1.23

    Image ID:       docker-pullable://nginx@sha256:...

    Port:           80/TCP

    State:          Running

      Started:      Thu, 01 Jun 2023 12:00:10 +0000

    Ready:          True

    Restart Count:  0

    Readiness:      tcpSocket on port 80 delay=5s timeout=1s period=10s

    Liveness:       tcpSocket on port 80 delay=15s timeout=1s period=20s

Events:

  Type    Reason     Age   From               Message

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

  Normal  Scheduled  30s   default-scheduler  Successfully assigned default/tcp-probe-pod to minikube

  Normal  Pulled     25s   kubelet            Container image "nginx:1.23" already present on machine

  Normal  Created    25s   kubelet            Created container tcp-probe-container

  Normal  Started    25s   kubelet            Started container tcp-probe-container

Key Concept

If you remember nothing else from this pattern, remember: TCP probes check if your app's network port is open and accepting connections to decide if it is ready or alive.

Common Mistakes

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

The probe will always fail because it cannot connect, causing Kubernetes to think the container is unhealthy.

Make sure the TCP probe port matches the container's actual listening port.

Setting initialDelaySeconds too low before the app is ready to accept connections.

Kubernetes may mark the container as unhealthy and restart it before it has a chance to start properly.

Set initialDelaySeconds to a value that gives your app enough time to start.

Not defining both readinessProbe and livenessProbe when needed.

Without readinessProbe, Kubernetes may send traffic to a container that is not ready. Without livenessProbe, Kubernetes won't restart a crashed container.

Define readinessProbe to control traffic flow and livenessProbe to detect and fix crashes.

Summary

Create a pod YAML file with tcpSocket probes under readinessProbe and livenessProbe sections.

Apply the pod configuration using kubectl apply -f to start the pod with TCP health checks.

Use kubectl get pods and kubectl describe pod to verify the pod status and probe results.

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