Kubernetes can restart the container after it senses that the container has crashed. For example, the memory of a Java program leaks and the program cannot work normally, but the JVM process is…

Question

Options

• AMonitoring Probes
• BStart the probe
• CReadiness Probe
• DSurvival Probes

• A
  6% (3)
• B
  13% (6)
• C
  4% (2)
• D
  77% (37)

Explanation

Option D, Survival Probes (known as Liveness Probes in Kubernetes), is correct because they are specifically designed to detect whether a running application is still functioning correctly - not just whether the process exists. In the scenario described, the JVM process is alive but the application has a business-level failure (memory leak), so Kubernetes cannot detect the problem from process state alone; the liveness probe actively queries the application and triggers a restart if it gets no valid response.

Option A, Monitoring Probes, is not a real Kubernetes probe type and is a distractor. Option B, Startup Probe, is used only during initial container startup to give slow-starting applications time to initialize - it does not handle runtime failures after the app has already started. Option C, Readiness Probe, determines whether a container should receive traffic, but a failing readiness probe only removes the pod from the service endpoint rotation; it does not cause Kubernetes to restart the container.

Memory tip: Think of Liveness as asking "Is this container still alive and sane?" - if the answer is no, Kubernetes kills and restarts it. Think of Readiness as asking "Is this container ready for customers?" - if the answer is no, it just stops sending new requests to it.

No community discussion yet for this question.