Kubernetes v1.37: Introducing Node Lifecycle Conditions

[kasenur]

Kubernetes v1.37: Introducing Node Lifecycle ConditionsBy Ryan Hallisey (NVIDIA) |
Wednesday, September 09, 2026Kubernetes has many ways to describe what is happening on a Node. Readiness,
taints, Pod state, labels, annotations, and provider-specific APIs each expose
part of the picture. What has been missing is a shared, Kubernetes-owned way to
say that a Node is draining,
undergoing maintenance, or undergoing Graceful Node Shutdown.Kubernetes v1.37 introduces five well-known Node conditions
that provide that description😀rainInProgressDrainedMaintenancePlannedMaintenanceInProgressGracefulNodeShutdownInProgressThe new Node lifecycle conditionsConditionWhat it reportsDrainInProgressThe Node is actively being drained according to the administrator's chosen drain criteria.DrainedThe Node has reached the drain criteria selected by the administrator.MaintenancePlannedThe Node is expected to undergo a change in the future.MaintenanceInProgressThe Node is actively undergoing maintenance.GracefulNodeShutdownInProgressGraceful Node Shutdown is determined to be in progress on the Node.Maintenance can include hardware or software rollout, remediation,
decommissioning, or debugging. Whether maintenance requires a drain depends on
its impact. A Kubernetes upgrade usually should follow a drain, while a kernel
live patch might not need one.Like other Node conditions, each lifecycle condition uses status to report
whether the observation is active:True: the lifecycle state is currently observed.False: the lifecycle state is not currently observed.Unknown: Kubernetes cannot determine whether the lifecycle state is active.The reason provides a stable, machine-readable cause for the current status,
and message can provide additional human-readable detail.For example, an authorized maintenance controller could publish:# Node .status excerpt
status:

lastTransitionTime: "2026-12-09T12:00:00Z"

message: "Hardware maintenance is scheduled for this Node"
What changes in Kubernetes v1.37The v1.37 release reserves these names as well-known NodeConditionType
constants and introduces the Alpha NodeLifecycleConditions feature gate,
which is disabled by default. In v1.37 the gate is effectively a no-op: it does
not restrict who can set these conditions, and no core component reads them. It
exists so that the built-in behavior planned for future releases — controllers
that consume these conditions — can be opted into when it arrives. You do not
need to enable it to start publishing the conditions today.For this release, an administrator or an administrator-authorized
controller is responsible for setting and clearing the lifecycle conditions.In this first release, no core workload controller changes its behavior based
on these conditions, but an administrator can publish them to communicate
maintenance and drains to cluster users.How to use lifecycle conditions todayThe immediate value is operational clarity. Administrators and
lifecycle automation can use these conditions as a common status channel for
Node lifecycle work that already happens today.For example, maintenance automation can set MaintenancePlanned when a future
maintenance window is scheduled, then set MaintenanceInProgress when work
starts. Drain automation can set DrainInProgress when it begins evicting Pods
and Drained when the administrator's selected drain criteria have been met.
The GracefulNodeShutdownInProgress condition can report that Graceful Node
Shutdown is in progress on the Node.The recommended pattern is to use lifecycle conditions to report status, while
lifecycle operations are managed through other mechanisms. Continue to use
existing Kubernetes mechanisms such as kubectl cordon,
kubectl drain,
taints, and
workload-specific controls to change scheduling or eviction behavior. Use
lifecycle conditions to make the state of that work visible to people,
dashboards, alerts, and automation that choose to consume the signal.When setting a condition, use True while the lifecycle state is active. Set the
condition to False, or remove it, when the state is no longer active. Use a
stable reason value and a clear message so that both people and automation
can understand why the condition changed. Cluster administrators should also
decide which component owns each lifecycle condition to avoid conflicting writes.Why a shared signal mattersNode lifecycle affects components across the cluster. The kubelet, node
lifecycle controller, workload controllers, scheduler, autoscalers, storage
operators, and external maintenance systems all need some understanding of what
is happening to a Node.Today, each component has to reconstruct that understanding from indirect
signals. One controller might look at Node readiness, another at taints, and
another at Pods that are terminating or missing. Infrastructure providers and
operators often add their own labels or annotations.Those signals remain useful for their intended purposes, but they do not answer
the same question. A taint can influence scheduling or eviction, for example,
but it does not attest that a drain is in progress or that an administrator's
drain criteria have been met. A NotReady Node does not explain whether the
cause is an unexpected failure, a graceful shutdown, or planned maintenance.Without shared lifecycle context, independently correct components can make
conflicting decisions. A DaemonSet controller can replace a Pod that the
kubelet intentionally terminated during graceful shutdown. A Job controller can
wait indefinitely for a terminal Pod phase on a Node that an administrator is
removing. A storage operator might learn about maintenance only after drain has
already started.The new conditions provide a stable place on the Node for that missing context,
as part of the
larger effort to enhance Node Lifecycle management.The foundation for lifecycle-aware KubernetesThe value of a shared signal comes from what