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.
Recommended by LinkedIn
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/v1kind: Deploymentmetadata: name: my-deploymentspec: 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: v1kind: Podmetadata: labels: test: liveness name: liveness-execspec: 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/v1kind: Deploymentmetadata: name: my-deploymentspec: 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
