Probes in Kubernetes

What are probes?

• To investigate or monitor something and to take necessary actions

What are health probes in Kubernetes?

• Health probes monitor your Kubernetes applications and take necessary actions to recover from failure

• To ensure your application is highly available and self-healing

Type of health probes in Kubernetes

• Readiness ( Ensure application is ready)

• Liveness ( Restart the application if health checks fail)

• Startup ( Probes for legacy applications that need a lot of time to start)

Types of health checks they perform?

• HTTP/TCP/command

Probes can use the following handlers:

• httpGet: Send an HTTP GET request to a container.

• tcpSocket: Attempt a TCP connection on a specified port.

• exec: Run a command inside the container.

✅ Startup Probe

• Used during startup - whether the application inside the container has started correctly.

• Helpful when apps take time to initialize.

• Prevents killing the container during long startup.

• Here’s a Kubernetes Startup Probe example for all three types: HTTP, TCP and Command.

1. HTTP Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-http
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
    startupProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

Notes:

• This checks http://<pod-ip>:80/ every 5s starting after 10s.

• failureThreshold: 30 means it can take up to 30 × 5 = 150 seconds before Kubernetes considers startup failed.

2. TCP Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-tcp
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
    startupProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

Notes:

• Checks TCP connectivity on port 80.

• Useful if you only care about the socket being open, not the HTTP response.

3. Command (Exec) Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-command
spec:
  containers:
  - name: my-container
    image: busybox
    command: ['sh', '-c', 'touch /tmp/healthy && sleep 600']
    startupProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 30

Notes:

• Runs cat /tmp/healthy inside the container.

• If the file exists, probe passes; otherwise, it fails.

---

✅ Liveness Probe

• Checks whether container is healthy and running.

• Checks if the container is still running. If it fails, the container is restarted.

• Here’s a Kubernetes Startup Probe example for all three types: HTTP, TCP and Command.

• 1. HTTP Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-http
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
    startupProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

Notes:

• This checks http://<pod-ip>:80/ every 5s starting after 10s.

• failureThreshold: 30 means it can take up to 30 × 5 = 150 seconds before Kubernetes considers startup failed.

2. TCP Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-tcp
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
    startupProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      failureThreshold: 30

Notes:

• Checks TCP connectivity on port 80.

• Useful if you only care about the socket being open, not the HTTP response.

3. Command (Exec) Startup Probe

apiVersion: v1
kind: Pod
metadata:
  name: startup-command
spec:
  containers:
  - name: my-container
    image: busybox
    command: ['sh', '-c', 'touch /tmp/healthy && sleep 600']
    startupProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 30

Notes:

• Runs cat /tmp/healthy inside the container.

• If the file exists, probe passes; otherwise, it fails.

---

✅ Readiness Probe

• Checks if the container is ready to receive traffic.

• If it fails, the Pod is removed from the Service endpoints.

• Here’s a Kubernetes Readiness Probe example for all three types — HTTP, TCP and Command

1. HTTP Readiness Probe

apiVersion: v1
kind: Pod
metadata:
  name: readiness-http
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3
      successThreshold: 1

What it does: Checks http://<pod-ip>:80/ after 5 seconds. If it fails, the Pod is marked not ready and won’t receive traffic.

2. TCP Readiness Probe

apiVersion: v1
kind: Pod
metadata:
  name: readiness-tcp
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
    readinessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3
      successThreshold: 1

What it does: Checks if TCP connection to port 80 is possible. If not, Pod won’t be considered ready.

3. Command (Exec) Readiness Probe

apiVersion: v1
kind: Pod
metadata:
  name: readiness-command
spec:
  containers:
  - name: my-container
    image: busybox
    command: ['sh', '-c', 'touch /tmp/ready; sleep 30; rm -f /tmp/ready; sleep 600']
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready
      initialDelaySeconds: 5
      periodSeconds: 5
      failureThreshold: 3
      successThreshold: 1

What it does: Runs cat /tmp/ready.

• File exists → Pod is ready

• File removed → Pod becomes not ready (but not restarted)

---