Budget PreStop work inside the Pod termination grace period

Bottom line: Give hook work and application shutdown one explicit time budget. Review what must happen before the stop signal and what must happen afterward, rather than approving each stage independently against the full grace period.

Source fact: documented behavior

The Container Lifecycle Hooks documentation is the primary reference.

PreStop must complete before the TERM signal is sent, while the Pod grace-period countdown starts before the hook runs. The grace period covers both PreStop execution and normal container stopping; the guide illustrates a combined duration exceeding the budget.

What the source does not establish

This article concerns the documented shared timing budget, not an application-specific safe shutdown guarantee or a sidecar ordering plan. It does not establish how long a real hook or application will take. Define the workload result and safe test conditions before exercising any termination scenario.

Applicability questions

• What work is assigned to the hook rather than application shutdown?
• What total termination budget is configured for the workload?
• Which stage timestamps and application observations can be collected?
• What is the stop condition if the approved exercise threatens unrelated work?

DSE recommendation: review the whole termination sequence

DSE recommends a short timeline with the grace-period start, hook start and finish, stop signal, and application completion. Put the intended work beneath each stage. Have the workload owner identify which work is necessary and which can be moved out of the termination path.

Allocate the proposed budget across the stages before tuning values. Use measured representative behavior when it is available, and label unmeasured allowances as estimates. Do not add two independently accepted stage limits without reconciling their combined duration and the margin needed for the intended workload.

Review the hook implementation for a clear completion condition and a bounded failure path. Keep an indefinitely waiting dependency out of an accepted design unless its consequences have been explicitly resolved. Assess what evidence the application owner needs to confirm its own shutdown work; the hook’s completion marker should not stand in for that application result.

Keep this review distinct from restartable-sidecar order. Use the relevant sidecar runbook when that mechanism is involved, and connect its observations to the timeline without replacing this shared-budget calculation. Preserve the configuration revision and the assumptions that justified each allowance for later changes.

Verification and evidence

Proposed verification, not performed: prepare a harmless disposable workload with observable hook and application milestones. For a proposed 60-second budget, compare a planned 40-second hook plus 10-second application allowance with a planned 55-second hook plus 10-second allowance. These are exercise inputs, not measured performance or customer requirements.

Collect the actual stage timings and termination result under the approved plan. Compare the observations with the documented shared-budget rule and investigate any discrepancy before changing the production allowance. Retain the hook revision, workload configuration, timestamps and application completion evidence. Ask a second operator to distinguish the arithmetic of the planned case from the behavior that was actually observed.

Official references

• Container Lifecycle Hooks — Kubernetes.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.