About this scenario
billing loads a large cache before it listens on port 8080, which takes about a minute. Its Pods restart again and again and never become Ready.
The liveness probe is right for a running app: if billing hangs, it should be restarted within 30 seconds. It just shouldn't apply while billing is starting.
Objectives
- See what restarts billing
- billing has a startup probe that allows its warm-up
- Both billing Pods are Ready, with no restarts
- Liveness still restarts a hung billing within 30 seconds
What you'll practice
- A liveness probe that fails while the app starts turns a slow start into a crash loop.
- A startup probe covers the start only. Once it passes, the liveness and readiness probes take over with their own short timings.
- Raising the liveness probe's
initialDelaySeconds also stops the restarts, but then a hung app goes unnoticed for as long after every restart. - Size the startup budget,
failureThreshold × periodSeconds, for the slowest start you expect, with some room.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.