Kubernetes probes explained

Probes are a way to check the health of an application deployed in the Kubernetes cluster. As of writing, Kubernetes supports 3 different types of probes.

• Liveness probe
• Readiness probe
• Startup probe

Probe properties

Few important properties you might want to configure in your manifest.

• initialDelaySeconds: Kubelet will wait for this amount of duration before starting the first probe on a container. This could be helpful in scenarios where the application takes longer to start and respond to the health check. However, startup probes are the recommended approach in these scenarios. Default value is 0 seconds.
• periodSeconds: Kubelet will perform liveness probes every periodSeconds duration. Default value is 10s.
• timeoutSeconds: Probe will timeout after this duration. Default value is 1s.
• successThreshold: Number of consecutive successful checks to pass the probe. Default value is 1.
• failureThreshold: Number of consecutive failure checks to fail the probe. Default is value is 3.

Types of Probe health checks

• HTTP health check

livenessProbe:
  httpGet:
    path: /
    port: nginx-port

• TCP health check

livenessProbe:
  tcpSocket:
    port: 8080

• gRPC health check

livenessProbe:
  grpc:
    port: 2379

• Command health check

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

Liveness probe

Kubelet runs this probe to determine if the container needs to be restarted. This is helpful in scenarios when the application container is hung and not responding to requests. This could be due to a deadlock or a race condition in the code. A container failing liveness probe will be restarted by the Kubelet.

Readiness probe

Kubelet runs this probe to determine if the container is ready to start accepting traffic. A container failing readiness probe will be marked as NotReady by the Kubelet. Traffic to that container will be stopped.

Startup probe

Kubelet runs this probe when a container is started. It disables liveness and readiness checks until it succeeds. This kind of probe is helpful if there is an application which takes longer time to start. Use it along failureThreshold * periodSeconds to delay the liveness and readiness probes. Once the period (failureThreshold * periodSeconds) is over, the container is killed and subject to the pod’s restartPolicy.

Sample deployment

Combining all three types of probes I have compiled a nginx deployment manifest.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: probes-deployment
  labels:
    app: probes
spec:
  replicas: 1
  selector:
    matchLabels:
      app: probes
  template:
    metadata:
      labels:
        app: probes
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - name: nginx-port
          containerPort: 80
        resources:
          limits:
            cpu: 20m
            memory: 50Mi
          requests:
            cpu: 10m
            memory: 25Mi
        livenessProbe:
          httpGet:
            path: /
            port: nginx-port
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 1
          successThreshold: 1
          failureThreshold: 3
        startupProbe:
          httpGet:
            path: /
            port: nginx-port
          failureThreshold: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: nginx-port
          initialDelaySeconds: 5
          periodSeconds: 5