A livenessProbe (extracted from an example) below is working well.
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
But, my livenessProbe is not working.(pod is continually restarted). YAML is below
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness-test
name: liveness
spec:
containers:
- name: liveness
args:
- /bin/bash
- -c
- /home/my_home/run_myprogram.sh; sleep 20
image: liveness:v0.6
securityContext:
privileged: true
livenessProbe:
exec:
command:
- /home/my_home/check.sh
initialDelaySeconds: 10
periodSeconds: 5
/home/my_home/check.sh (to restart the pod when the number of running processes is 1 or 0) is below, which is pre-tested.
#!/bin/sh
if [ $(ps -ef | grep -v grep | grep my-program | wc -l) -lt 2 ]; then
exit 1
else
exit 0
fi
If the application starts up in a few seconds or less, then a liveness probe is probably unnecessary. If it takes more than a few seconds, we should put in a liveness probe to ensure that the container initializes without error rather than crashing.
Run the kubectl get events command, and you will see that the liveness probe has failed, and the container has been killed and restarted.
Define a liveness command Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations. In this exercise, you create a Pod that runs a container based on the k8s.gcr.io/busybox image.
The only difference is that you use the readinessProbe field instead of the livenessProbe field. Configuration for HTTP and TCP readiness probes also remains identical to liveness probes. Readiness and liveness probes can be used in parallel for the same container.
If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. Readiness probes are configured similarly to liveness probes. The only difference is that you use the readinessProbe field instead of the livenessProbe field.
The output indicates that no liveness probes have failed yet: At the bottom of the output, there are messages indicating that the liveness probes have failed, and the containers have been killed and recreated. Wait another 30 seconds, and verify that the Container has been restarted: Another kind of liveness probe uses an HTTP GET request.
This problem is related to Golang Command API. I changed the livenessProbe as below
livenessProbe:
exec:
command:
- /bin/sh
- -c
- /home/test/check.sh
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With