Probes

Configured startup suppresses liveness and readiness until startup succeeds. It then stops for that container instance and hands off to the separately configured checks.

Startup probes delay other probes until initialization succeeds

A startup probe gives a container a separate initialization contract. While that configured probe has not succeeded, Kubernetes does not execute the container’s liveness or readiness probes. This is stronger and more specific than ignoring some liveness failures during a grace period: those other checks have not begun. Once startup succeeds, ordinary ongoing health and readiness behavior takes over. ...

Readiness failure closes ordinary Service routing eligibility while liveness failure can restart the container inside the same Pod.

Readiness changes routing eligibility; liveness restarts a container

Readiness and liveness answer different operational questions. Readiness asks whether this container should contribute to a Pod that accepts ordinary Service traffic now. Liveness asks whether restarting this container is the configured recovery action. Both can use HTTP, but sharing a protocol does not make their meanings interchangeable. Define the action you want before choosing the condition that triggers it. ...