Understanding Kubernetes Startup Probes: Examples and Use Cases

Kubernetes, a powerful container orchestration tool, offers several features to ensure that your applications are running as expected. One such feature is the use of probes. Probes are diagnostic tools used by Kubernetes to monitor the health of Pods. Among these, Startup Probes play a crucial role in maintaining the health of your applications.

What are Startup Probes?

Startup probes are used by Kubernetes to know when a container application has started. If such a probe is configured, liveness and readiness probes do not start until it succeeds, making sure those probes don’t interfere with the application startup. This can be used to adopt liveness checks on slow starting containers, avoiding them getting killed by the kubelet before they are up and running.

Configuring Startup Probes

Startup probes can be configured in the yaml configuration file under spec.containers.startupprobe. To perform a probe, the kubelet sends an HTTP GET request to the server that is running in the container and listening on port 8080. If the handler for the server’s /healthz path returns a success code, the kubelet considers the container to be alive and healthy.

Here is an example of a Startup Probe configuration:

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10        

In this example, the startup probe is defined with an HTTP GET request to the /healthz endpoint on the liveness-port. If the endpoint returns a success code, the container is considered alive. The failureThreshold is set to 30 and periodSeconds is set to 10, giving the application 30 x 10 = 300 seconds to startup before it fails.

Use Cases for Startup Probes

Startup probes are most useful when an application is temporarily malfunctioning and unable to serve traffic. If the application is running but not fully available, Kubernetes may not be able to scale it up and new deployments could fail. A startup probe allows Kubernetes to wait until the service is active before sending it traffic.

Here are some specific scenarios where startup probes can be beneficial:

1.??? Slow Starting Containers: Startup probes should be used when the application in your container could take a significant amount of time to reach its normal operating state. Applications that would crash or throw an error if they handled a liveness or readiness probe during startup need to be protected by a startup probe. This ensures the container doesn’t enter a restart loop due to failing healthiness checks before it’s finished launching.

2.??? Handling Temporary Glitches: If your application loses connection to another service (e.g., database), a startup probe can help manage traffic during these periods.

Remember, when you use a startup probe, Kubernetes will only send traffic to the pod if the probe succeeds. There is no need to use a startup probe on deletion of a pod. When a pod is deleted, it automatically puts itself into an unready state, regardless of whether readiness probes are used. It remains in this status until all containers in the pod have stopped.

Best Practices for Startup Probes

While startup probes are a powerful tool, they must be used carefully to avoid unintended consequences. Here are some best practices for using startup probes:

1.??? Specify a Startup Probe: If the pod takes a long time to start, specify a Startup Probe. The Startup and Liveness Probe can use the same endpoint, but the Startup Probe will have a less strict failure threshold which prevents a failure on start-up.

2.??? Avoid External Dependencies: Do not depend on external dependencies (like data stores) for your startup checks as this might lead to cascading failures.

3.??? Use Different Specifications for Startup and Liveness Probes: If you use a startup probe, don’t set the same specification for startup and liveness probe.

Conclusion

Startup probes are a powerful tool for maintaining the health of your Kubernetes applications. However, they must be used carefully to avoid unintended consequences. By understanding and correctly implementing these probes, you can ensure that your applications are robust and reliable.

Here are some examles

1. HTTP Get Startup Probe

Consider this example where the startup probe is defined in a Deployment. The probe uses an HTTP GET request to the /healthz endpoint on the liveness-port. If the endpoint returns a success code, the container is considered alive.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  template:
    metadata:
      labels:
        app: my-test-app
    spec:
      containers:
      - name: my-test-app
        image: nginx:1.14.2
        startupProbe:
          httpGet:
            path: /healthz
            port: liveness-port
          failureThreshold: 30
          periodSeconds: 10
        

2. Exec Startup Probe

In this example, the startup probe is a shell script that uses the cat command to read the /tmp/healthy file. If the cat command returns a zero exit status, the container is considered alive.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 25; rm -rf /tmp/healthy; sleep 500
    startupProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 6
        

3. TCP Socket Startup Probe

In this example, the startup probe checks if the TCP port 3000 is open. If the port is open, the container is considered alive.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  template:
    metadata:
      labels:
        app: my-test-app
    spec:
      containers:
      - name: my-test-app
        image: nginx:1.14.2
        startupProbe:
          tcpSocket:
            port: 3000
          failureThreshold: 30
          periodSeconds: 10
        

Understanding and correctly implementing these probes can ensure that your applications are robust and reliable. Stay tuned for more insights on Kubernetes!

#Kubernetes #DevOps #CloudComputing