LEARN. PRACTICE. GROW.Concept and mechanism
Probes answer different questions. Startup covers initialization; until it succeeds, it delays liveness and readiness. Liveness identifies conditions where restarting may help, such as a stuck process. Readiness indicates traffic-serving capability and can remove a Pod from service endpoints without requesting restart for that reason. A shared database outage does not imply that every process needs restarting. If liveness depends on that database, failure can cause startup loops and increase load precisely when the dependency is degraded. Choose observable, lightweight criteria with tolerance appropriate to measured behavior. An active Pod does not by itself demonstrate functional readiness.
Guided application
In a fictional batch, the application takes 90 seconds to initialize and needs fast detection after startup. A startup probe can provide measured headroom without making liveness slow throughout the lifecycle. For HPA, distinguish absolute values, utilization percentages, and external metrics. A CPU percentage target uses requests as its denominator; confirm each container’s effective configuration and metric availability. Calculated scale needs capacity in dependencies. Thirty Pods with pools of fifteen can request 450 connections, above 300 available. Coordinate pools, admission, backpressure, and limits while preserving headroom for other consumers. More replicas fix neither a connection leak nor a database lacking capacity.
A missing denominator is not zero utilization; it is insufficient information for that calculation.
Common pitfalls
Readiness as a liveness pause; external failure as deadlock; HPA as automatic database scaling.
Related topics: State, caching, and asynchronous flows · Credentials, secrets, and access · Build, artifacts, and provenance
Measure the right condition and protect the complete path when scaling.
Reference: Kubernetes probes · Current linked guide; edition date unconfirmed (2026-09-30 inspection)