Cloud and Container Basics
In a web application on Kubernetes, the check performed by the liveness probe was made to include whether the application can connect to the database it depends on. Which of the following is the most likely problem with this setting?
- AWhen the database stops, the Pods are automatically moved to the node where the database runs, degrading the other applications on that node
- BA brief database outage makes the containers of all Pods restart repeatedly, delaying recovery even after the database comes back
- CWhen the liveness probe fails, the Pod is only removed from the Service's routing targets, so no particular problem arises
Show answer and explanation
Answer: B. A brief database outage makes the containers of all Pods restart repeatedly, delaying recovery even after the database comes back
A liveness probe exists to recover a container that has itself stopped responding (for example, through a deadlock) by restarting it. If it also checks a dependency, then when the database stops, the liveness probes of all Pods fail and the containers keep being restarted, even though restarting does not fix anything. During restarts no requests are handled, and the wait before the next restart may grow as restarts repeat, so recovery is delayed even after the database comes back. A liveness probe should check only whether the process itself can respond, and the state of dependencies should be handled by readiness probes or the application's error handling as needed.
- A. A probe failure never moves a Pod to another node. When a liveness probe fails, the container is restarted.
- B. Correct. A failure of a dependency causes the Pods to be restarted again and again.
- C. Removing a Pod from the routing targets is what a readiness probe does. When a liveness probe fails, the container is restarted.