You have a container deployed on Google Kubernetes Engine. The container can sometimes be slow to launch, so you have implemented a liveness probe. You notice that the liveness probe occasionally fails on launch. What should you do?
A.
Add a startup probe.
B.
Increase the initial delay for the liveness probe.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes
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.
"Sometimes, you have to deal with legacy applications that might require an additional startup time on their first initialization. In such cases, it can be tricky to set up liveness probe parameters without compromising the fast response to deadlocks that motivated such a probe. The trick is to set up a startup probe with the same command"
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes
A startup probe is a probe that Kubernetes uses to determine if a container has started successfully. If the startup probe fails, Kubernetes will restart the container.
Readiness probe is the right answer. Likeness probe fails if it tries to probe a container not yet ready to serve the traffic. So we need to add readiness probe. There is no such thing called startup probe in kubernetes.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Caution: Liveness probes do not wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe.
A liveness probe checks if the container is running as expected, and if not, it restarts it. If the container is slow to launch, it may take some time for it to fully start up and be able to respond to the liveness probe. Increasing the initial delay for the liveness probe can help mitigate this issue by giving the container more time to start up before the probe begins checking its status. This can help reduce the likelihood of false-positive failures during launch.
A. Adding a startup probe is useful for determining when a container has started, but it won't help with the problem of the liveness probe occasionally failing on launch.
B. Increasing the initial delay for the liveness probe might help if the container is taking longer than the delay to start, but it's not a guaranteed solution.
C. Increasing the CPU limit for the container may help if the container is running out of resources, but it may not be necessary if the issue is related to the container's initialization process.
D. A readiness probe can help determine when a container is ready to receive traffic, but it won't help with the problem of the liveness probe occasionally failing on launch.
Changing to A:
The problem is that the liveness probes fires too early, so we need a startup probe to determine when liveness (and potential readiness) probe are valid.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Should be A definitely
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes
Sometimes, you have to deal with legacy applications that might require an additional startup time on their first initialization. In such cases, it can be tricky to set up liveness probe parameters without compromising the fast response to deadlocks that motivated such a probe. The trick is to set up a startup probe with the same command, HTTP or TCP check, with a failureThreshold * periodSeconds long enough to cover the worse case startup time
Thanks to the startup probe, the application will have a maximum of 5 minutes (30 * 10 = 300s) to finish its startup. Once the startup probe has succeeded once, the liveness probe takes over to provide a fast response to container deadlocks. If the startup probe never succeeds, the container is killed after 300s and subject to the pod's restartPolicy.
B is the answer.
https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-setting-up-health-checks-with-readiness-and-liveness-probes
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
closer89
Highly Voted 1 year, 6 months agoKadhem
Most Recent 10 months, 1 week ago__rajan__
1 year, 1 month agopurushi
1 year, 2 months agoflesk
1 year agopurushi
1 year, 2 months agoPime13
1 year, 8 months agomrvergara
1 year, 9 months agoomermahgoub
1 year, 9 months agochunker
1 year, 9 months agochunker
1 year, 9 months agoTNT87
1 year, 9 months agoTNT87
1 year, 9 months agocloser89
1 year, 6 months agocloser89
1 year, 6 months agozellck
1 year, 10 months agosharath25
1 year, 10 months agoTNT87
1 year, 11 months ago