tolerationSeconds and graceful eviction on NoExecute

WHAT THIS TESTS This advanced question distinguishes two timers people routinely conflate: how long a pod may tolerate a NoExecute taint, and how long it gets to shut down once eviction begins.

A GOOD ANSWER COVERS NoExecute evicts pods that do not tolerate the taint immediately. For pods that DO tolerate it, tolerationSeconds controls how long they may keep running after the matching taint is applied. If tolerationSeconds is unset, the pod tolerates the taint forever and is never evicted by it. If set, say 300, the pod is allowed to stay 300 seconds, after which the controller marks it for eviction. At that point terminationGracePeriodSeconds begins: the kubelet sends SIGTERM, waits up to that grace period for the container to exit cleanly, then sends SIGKILL. So the timers are sequential: tolerationSeconds delays the start of eviction, terminationGracePeriodSeconds bounds the shutdown after it starts.

COMMON WRONG ANSWERS Saying both timers run concurrently or are the same thing is the core error. Claiming tolerationSeconds guarantees indefinite protection ignores that omitting it, not setting it large, is what gives infinite tolerance. Forgetting that the node-not-ready and unreachable taints are auto-added with default tolerationSeconds of 300 is also common.

LIKELY FOLLOW-UPS Which taints does Kubernetes add automatically on node failure. How does this interact with PodDisruptionBudgets (it does not; NoExecute eviction is involuntary). What preStop hooks do during the grace window.

ONE CONCRETE EXAMPLE A node goes unreachable; Kubernetes auto-taints it node.kubernetes.io/unreachable:NoExecute. A pod with default tolerationSeconds 300 keeps running five minutes, then eviction starts and its 30-second terminationGracePeriodSeconds governs the SIGTERM-to-SIGKILL shutdown.