Exercise 3: A Too-Aggressive Liveness Probe Making Things Worse — Possible Solution
====================================================================

What's actually misconfigured:

The application is described as "occasionally slow to respond... but
not actually broken or deadlocked" -- this is a TEMPORARY PERFORMANCE
issue under real load, not a genuine application failure. Per this
chapter's own distinction, this is fundamentally a READINESS-shaped
problem ("temporarily not ready to serve traffic," matching the
chapter's own database-slowness-style example), NOT a liveness-shaped
problem ("genuinely broken, should be restarted").

The chapter's own warn-box describes exactly this scenario: "a
liveness probe that's too aggressive/sensitive (too short a timeout,
too low a failure threshold) can cause unnecessary restarts of a
genuinely healthy application under temporary load." The liveness
probe's SHORT TIMEOUT is treating ordinary, temporary slowness as if
it were a sign of a genuinely dead application, when it's actually
just a busy one -- and the chapter's own point that "more health
checking isn't automatically better if it's poorly tuned" applies
directly here.

Why it's making the problem WORSE, not just failing to help:

Restarting the container doesn't actually solve slow database query
performance under heavy load -- if anything, it makes things worse,
because every restart briefly removes that pod's capacity entirely
(it has to reboot and reinitialize) right at the moment the
application is already under heavy load and could use MORE capacity,
not less. This is a self-inflicted availability problem layered on top
of a pre-existing performance problem.

How it should be fixed:

1. INCREASE THE LIVENESS PROBE'S TIMEOUT/THRESHOLD so that ordinary,
   temporary slowness under load doesn't get misclassified as a
   genuine failure -- giving the application enough tolerance to be
   briefly slow without being killed for it.

2. ADD OR ADJUST A SEPARATE READINESS PROBE specifically to handle the
   "temporarily overloaded, not currently ready for MORE traffic"
   signal -- per the chapter, this removes the pod from the Service's
   Endpoints (Chapter 6) temporarily, giving it a chance to catch up
   WITHOUT killing and restarting it, which is exactly the
   non-destructive response this situation actually calls for.

The core fix is recognizing that "occasionally slow under load" is a
READINESS signal, not a LIVENESS signal, and configuring the two
probes accordingly rather than relying on an overly strict liveness
probe to handle a problem it was never the right tool for.

WHY THIS WORKS AS AN ANSWER
------------------------------
This diagnoses the scenario using the chapter's own liveness-vs-
readiness distinction (this is a readiness-shaped problem being
handled by an overly aggressive liveness probe) and applies the
chapter's own explicit warn-box scenario directly, then proposes the
two-part fix (loosen liveness, add/tune readiness) the chapter's own
material supports rather than a generic "just tune the timeout" answer
that misses the deeper readiness-vs-liveness mismatch.