Node Shutdowns [page]deterministic

In a Kubernetes cluster, a [node](#gloss:node) can be shut down in a planned graceful way or unexpectedly because of reasons such as a power outage or something else external. A node shutdown could lead to workload failure if the node is not drained before the shutdown. A node shutdown can be either graceful or non-graceful.

> Caution: The `unattended-upgrades` package from Debian conflicts with node graceful shutdown in its normal configuration. If you use the default configuration of `unattended-upgrades`, which customizes the server shutdown grace period, then the kubelet fails to obtain the necessary lock to handle shutdown events properly.

This happens if the `shutdownGracePeriod` value is greater than 30 seconds. To avoid this, you can suppress part of the `unattended-upgrades` configuration, by making `/etc/systemd/logind.conf.d/unattended-upgrades-logind-maxdelay.conf` be a symbolic link to `/dev/null`.

For more details, refer to the [`logind.conf` documentation](https://www.freedesktop.org/software/systemd/man/latest/logind.conf.html).

## Graceful node shutdown {#graceful-node-shutdown}

The kubelet attempts to detect node system shutdown and terminates pods running on the node.

Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown. During node shutdown, the kubelet does not accept new Pods (even if those Pods are already bound to the node).

### Enabling graceful node shutdown

On Linux, the graceful node shutdown feature is controlled with the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) which is enabled by default in 1.21.

The graceful node shutdown feature depends on systemd since it takes advantage of [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration.

On Windows, the graceful node shutdown feature is controlled with the `WindowsGracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) which is introduced in 1.32 as an alpha feature. In Kubernetes 1.34 the feature is Beta and is enabled by default.

The Windows graceful node shutdown feature depends on kubelet running as a Windows service, it will then have a registered [service control handler](https://learn.microsoft.com/en-us/windows/win32/services/service-control-handler-function) to delay the preshutdown event with a given duration.

Windows graceful node shutdown can not be cancelled.

If kubelet is not running as a Windows service, it will not be able to set and monitor the [Preshutdown](https://learn.microsoft.com/en-us/windows/win32/api/winsvc/ns-winsvc-service_preshutdown_info) event, the node will have to go through the [Non-Graceful Node Shutdown](#non-graceful-node-shutdown) procedure mentioned above.

In the case where the Windows graceful node shutdown feature is enabled, but the kubelet is not running as a Windows service, the kubelet will continue running instead of failing. However, it will log an error indicating that it needs to be run as a Windows service.

### Configuring graceful node shutdown

Note that by default, both configuration options described below, `shutdownGracePeriod` and `shutdownGracePeriodCriticalPods`, are set to zero, thus not activating the graceful node shutdown functionality. To activate the feature, both options should be configured appropriately and set to non-zero values.

Once the kubelet is notified of a node shutdown, it sets a `NotReady` condition on the Node, with the `reason` set to `"node is shutting down"`. The kube-scheduler honors this condition and does not schedule any Pods onto the affected node; other third-party schedulers are expected to follow the same logic. This means that new Pods won't be scheduled onto that node and therefore none will start.

The kubelet also rejects Pods dur …(trimmed)