What Happens After A Node Restart [page]deterministic
System components on a node sometimes restart, either because of an upgrade, a crash, or an explicit operator action. This page describes what happens to Pods and to the node when the [kubelet](#gloss:kubelet), the [container runtime](#gloss:container-runtime), or the node as a whole restarts.
In a healthy cluster these restarts are usually safe and do not break running workloads. The sections below describe the effects to be aware of, which become more pronounced on large or heavily loaded nodes. The most disruptive case is a [node reboot](#impact-of-a-node-reboot), which encompasses both a container runtime restart and a kubelet restart, but with more consequences because every container on the node stops first.
## Impact of a kubelet restart
If only the kubelet restarts, the containers that are already running **continue to run**. The kubelet re-establishes its view of the Node, and reconciles the running containers against the desired state. During this period of time, the following happens:
* The kubelet re-initializes and re-synchronizes its caches, which produces a burst of requests to the [API server](#gloss:kube-apiserver). On large nodes with many Pods this burst can be significant.
* The node is temporarily reported as `NotReady` until the kubelet finishes initializing. While the node is `NotReady`, the [scheduler](#gloss:kube-scheduler) does not place new Pods on it.
* [Node heartbeats](/docs/concepts/architecture/nodes/#node-heartbeats) pause while the kubelet is down and resume once it has restarted and finished initializing, when the kubelet renews its `Lease` object and posts node status again.
* The kubelet preserves the readiness of running containers across a restart. Each Pod's readiness drives [EndpointSlices](#gloss:endpoint-slice), Endpoints, and downstream configuration (such as Gateways or Ingresses); this means that resetting container readiness on every restart would place a large load on the API server and on components that watch endpoint state, and could briefly remove healthy Pods from Service load balancing. This behavior is described in [KEP-4781: Fix inconsistent container ready state after kubelet restart](https://www.kubernetes.dev/resources/keps/4781/). Resetting container readiness to `false` on every restart was the default behavior for a long time. The `ChangeContainerStatusOnKubeletRestart` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) lets you revert to that behavior, but it is a deprecated legacy escape hatch that is slated for removal, so you should not rely on it. For more detail, see [Pod behavior during kubelet restarts](/docs/concepts/workloads/pods/pod-lifecycle/#kubelet-restarts).
* During the initial kubelet startup, [garbage collection](#gloss:garbage-collection) of unused images and containers, and Pod [evictions](/docs/concepts/scheduling-eviction/node-pressure-eviction/) driven by node-pressure, are paused. This pause continues for a short grace period after the kubelet has completed its main startup routines. This delay can slow the node's reaction to memory or disk pressure.
* Ongoing image pulls are cancelled. Depending on the container runtime, a cancelled pull may have to start over from the beginning when it is retried.
* Pod admission runs again for the Pods on the node as the kubelet replays them through its admission checks. If the node's [labels](#gloss:label) or [taints](#gloss:taint) have changed while the kubelet was down, a Pod can fail admission and be rejected even though it was already running. This is an existing behavior, and whether it should be considered a bug is still debated; see [kubernetes/kubernetes#123859](https://github.com/kubernetes/kubernetes/issues/123859) for the discussion and details.
Overall, in a healthy cluster a kubelet restart does not break running workloads. On large clusters with overcommitted nodes, however, the r …(trimmed)