Kubernetes Probes
On this page
We recommend that you set below probes for your deployment.
StartUp Probe
Note
If the startup probe never succeeds, the container is killed after 300s and subject to the pod's restartPolicy.
Set up startup probe with a failureThreshold * periodSeconds
long enough to cover the worse case startup time
The kubelet uses startup probes to know when a container application has started.
If such a probe is configured, it disables liveness and readiness checks 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.
spec:
template:
spec:
containers:
- name: {{ .Chart.Name }}
startupProbe:
httpGet:
path: /health
port: http
scheme: HTTP
timeoutSeconds: 10 # number of seconds before marking the probe as timing out (failing the health check)
periodSeconds: 10 # how often to check the probe
successThreshold: 1 # minimum number of consecutive successful checks
failureThreshold: 30 # number of retries before marking the probe as failed
In above configuration, the probe checks /health endpoint every 10 seconds until 5 mins (periodSeconds * failureThreshold = 300s)
.
Within that period if the health check endpoint returns success, then it would turn on liveness and readiness probes. Otherwise, it would fail.
Readiness Probe
Note
Kubernetes makes sure the readiness probe passes before allowing a service to send traffic to the pod.
If a readiness probe starts to fail, Kubernetes stops sending traffic to the pod until it passes.
Readiness probes are designed to let Kubernetes know when your app is ready to serve traffic.
spec:
template:
spec:
containers:
- name: {{ .Chart.Name }}
readinessProbe:
httpGet:
path: /health
port: http
scheme: HTTP
timeoutSeconds: 10
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
Liveness Probe
Note
We recommend you use a startupProbe along with a liveness probe.
If your liveness probe fails, it will restart your container.
Incorrect configuration (e.g. App takes more time to startup than the configured delays) will result in a constant restart loop.
spec:
template:
spec:
containers:
- name: {{ .Chart.Name }}
livenessProbe:
httpGet:
path: /health
port: http
scheme: HTTP
timeoutSeconds: 10
periodSeconds: 10
successThreshold: 1
failureThreshold: 3