Lifecycle controls decide when a process starts receiving traffic, when Kubernetes restarts it, and how it stops. Combining every dependency into one “health” endpoint makes those decisions interfere with each other.
Quick answer
A startup probe protects slow initialization before liveness and readiness begin. Liveness asks whether restarting this container can repair a stuck local process. Readiness asks whether this endpoint should receive regular Service traffic. Pod termination removes the endpoint from normal traffic and sends the process a termination signal; application shutdown must stop admission, drain bounded work, and exit within the grace period. Readiness does not prove end-to-end business correctness.
Learning objectives
- Assign startup, restart, traffic eligibility, and termination responsibilities to separate Kubernetes and Spring lifecycle controls.
- Choose probe dependencies and time budgets that avoid restart storms and preserve ambiguous durable outcomes.
Prerequisites
Review Liveness, Readiness, and Startup Health Checks and Kubernetes workload boundaries. Use the course and topic cluster.
Lifecycle sequence
Spring Boot Actuator can expose application liveness and readiness groups. Keep probe paths reachable on the intended port and test their behavior with the actual security configuration. A remote database outage usually should remove a Pod from readiness only if the Pod cannot serve its declared contract; failing liveness for every shared dependency outage can restart all replicas and add load.
On deletion, traffic removal and process termination are coordinated but not instantaneous across every proxy and client. The application must reject new work at the appropriate boundary, honor SIGTERM, allow bounded requests to finish, stop consumers deliberately, and preserve durable reconciliation for work that outlives the caller. preStop consumes the same termination grace budget and should not be used as an unexplained sleep.
Production failure scenario
Every Pod checks the shared database in liveness. A database incident makes all liveness probes fail, so nodes restart otherwise responsive applications. Startup warms pools, generating more database connections, while remaining capacity collapses. Readiness and user errors oscillate.
Remove the remote dependency from the restart decision, bound readiness according to the offered contract, and mitigate database pressure. Verify business recovery after connection and queue behavior normalize. Green probes alone cannot close the incident.
Common misconceptions
- Liveness is not a complete dependency health check.
- Readiness does not prove business transactions, asynchronous effects, or customer success.
- A startup probe does not make initialization faster.
preStopruns within, not before, the termination grace period.- Caller disconnect or Pod termination does not automatically reverse committed effects.
Decision checklist
- Define what restart can actually repair before adding a liveness dependency.
- Use startup probes for bounded slow initialization.
- Tie readiness to the traffic contract and avoid unbounded checks.
- Coordinate endpoint removal, admission stop, SIGTERM, consumer shutdown, and grace period.
- Test rolling termination with keep-alive requests and real Spring security routing.
- Verify durable outcomes for work interrupted near commit boundaries.
Continue with Kubernetes Resource Requests, Limits, and JVM Containers.
Related reading
- Spring Boot Actuator, Health, and Metrics owns the application lifecycle groups exposed to Kubernetes.
- Timeouts, Deadlines, and Cancellation Propagation explains why termination does not reverse durable effects.
- Graceful Degradation and Fallback Design keeps readiness decisions aligned with the service contract.
Official sources
- Kubernetes liveness, readiness, and startup probes, accessed August 18, 2026.
- Kubernetes Pod lifecycle and termination, accessed August 18, 2026.
- Spring Boot Kubernetes probes, accessed August 18, 2026.
- Spring Boot graceful shutdown, accessed August 18, 2026.