Separate Kubernetes pressure alerts from eviction timing

Bottom line: Write down which timer is being investigated before changing an eviction setting. Preserve the pressure observation, threshold persistence and actual termination as distinct events so an alert does not become an assumed application shutdown or recovery result.

Source fact: documented behavior

The Node-pressure Eviction documentation is the primary reference.

A soft eviction threshold must remain satisfied for its configured grace period before eviction, and omitting that required period causes a kubelet startup error. A hard threshold has no grace period and permits immediate termination, while soft eviction has a separate maximum Pod-termination grace setting. The kubelet reports pressure node conditions when a hard or soft threshold is met, independently of configured grace periods.

What the source does not establish

Keep this timing review separate from API-initiated disruption, victim ranking and application recovery design. The article does not prescribe resource-exhaustion tests, a universally safe threshold or a guaranteed shutdown interval. It excludes the separate hugepage-adjustment and split-filesystem branches. An alert or successful replacement Pod alone should not close the original pressure incident.

Applicability questions

• Which exact resource signal crossed which threshold?
• Was the threshold configured as soft or hard?
• Which persistence and termination settings are effective?
• What timestamps establish eviction and application recovery separately?

DSE recommendation: review a timeline with separate checkpoints

DSE recommends writing a threshold-to-termination timeline before changing a node-pressure response.

Start with the actual incident record or an approved hypothetical case. Name the node, resource signal, threshold type and effective settings. Put the first observed pressure condition on its own row. Mark unavailable timestamps as unknown instead of deriving them from the time an operator first saw an alert.

Review the soft-threshold persistence interval separately from the maximum grace available when terminating a selected Pod. Have the application owner identify its required shutdown behavior and any recovery dependency. Preserve a conflict between that requirement and the node’s configured response as a design issue rather than increasing a timer without assessing the remaining resource margin.

For a hard-threshold case, have the recovery owner review the consequence of immediate termination. Obtain a supported procedure for protecting application state and restoring service. Keep the proposed application acceptance separate from an infrastructure observation that resource availability improved.

Before changing settings, compare the managed configuration across eligible nodes and agree the observation and reversal plan. Investigate repeated pressure transitions with the actual signal history; do not label each transition a completed eviction or assume that a quieter alert stream means the workload is healthy.

Verification and evidence

Proposed verification, not performed: begin with desk timelines containing a short soft-threshold excursion, a sustained soft condition and a hard-threshold crossing. Label all times as fixtures. Ask a reviewer to identify which interval each setting governs and which events still require observation.

If a live exercise is necessary, use an isolated test node, an approved bounded workload and explicit stop conditions. Do not create uncontrolled memory or disk exhaustion in production. Record actual signal observations, node conditions, Pod termination and application recovery separately. Retain the settings and workload identity with every result, including a missing or unexpected observation that prevents acceptance.

Official references

• Node-pressure Eviction — Kubernetes.

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