Kubernetes 1.37 Node Lifecycle Conditions: A Safer Way to Handle Node Maintenance

Kubernetes 1.37 introduces five well-known Node lifecycle conditions that describe what is happening to a Node during draining, maintenance, and graceful shutdown:

DrainInProgress
Drained
MaintenancePlanned
MaintenanceInProgress
GracefulNodeShutdownInProgress

The feature addresses a practical problem in cluster operations. Kubernetes already exposes Node readiness, taints, Pod state, labels, and annotations, but these signals do not clearly tell other components whether a Node is intentionally being drained, maintained, or shut down.

Node lifecycle conditions provide a shared status signal for that information.

What Are Node Lifecycle Conditions?

Kubernetes already uses Node conditions such as Ready, MemoryPressure, DiskPressure, and PIDPressure to describe the state of a Node.

Kubernetes 1.37 adds lifecycle-specific conditions:

Condition	What it means
`DrainInProgress`	The Node is currently being drained according to the administrator's selected criteria
`Drained`	The Node has reached the selected drain criteria
`MaintenancePlanned`	The Node is expected to undergo a change in the future
`MaintenanceInProgress`	The Node is currently undergoing maintenance
`GracefulNodeShutdownInProgress`	A graceful Node shutdown is currently in progress

Each condition uses the standard Kubernetes condition status:

True means the state is currently active.
False means the state is not currently active.
Unknown means the writer cannot determine the current state.

The reason field identifies why the condition has its current status, while message can provide additional information for administrators.

For example:

status:
  conditions:
    - type: MaintenancePlanned
      status: "True"
      reason: MaintenanceWindow
      lastTransitionTime: "2026-12-09T12:00:00Z"
      message: "Hardware maintenance is scheduled for this Node"

The condition reports the state. It does not perform the maintenance operation.

Why Existing Node Signals Are Not Enough

Kubernetes already provides several mechanisms for managing Nodes.

For example, you can prevent normal scheduling with:

kubectl cordon worker-01

You can then drain workloads with:

kubectl drain worker-01 --ignore-daemonsets

Taints and tolerations can also control which workloads are allowed to run on a Node.

These mechanisms remain important. The problem is that they do not provide the same type of lifecycle context.

Suppose an administrator is preparing a Node for a hardware replacement.

A NotReady condition does not tell another component whether the Node has failed or is intentionally being taken out of service.

A taint can change scheduling behavior, but it does not explicitly state that a drain is in progress.

A terminating Pod shows that a workload is leaving the Node, but it does not explain why.

The new lifecycle conditions provide a common place to publish that information.

Understanding the Difference Between Maintenance and Drain

Maintenance and draining are related, but they are not the same operation.

A maintenance task might require all workloads to leave the Node. A different maintenance task might be performed while workloads continue running.

For example, a Kubernetes upgrade that requires the Node to be taken out of service would normally involve draining workloads first.

A kernel live patch may not require a drain.

This distinction is reflected in the separate conditions:

MaintenancePlanned
MaintenanceInProgress
DrainInProgress
Drained

A maintenance system should therefore avoid assuming that every maintenance operation requires a drain.

A Typical Node Maintenance Workflow

A maintenance controller can use the conditions to describe each stage of the process.

A typical workflow could look like this:

Maintenance scheduled
        |
        v
MaintenancePlanned=True
        |
        v
Cordon Node
        |
        v
DrainInProgress=True
        |
        v
Drain workloads
        |
        v
Drained=True
        |
        v
MaintenanceInProgress=True
        |
        v
Perform maintenance
        |
        v
MaintenanceInProgress=False
        |
        v
Uncordon Node

The exact sequence depends on the type of maintenance.

The important point is that lifecycle conditions report what is happening while existing Kubernetes mechanisms continue to perform the actual Node operations.

How to View Node Lifecycle Conditions

You can inspect all conditions for a Node with:

kubectl describe node worker-01

For a more compact view, use JSONPath:

kubectl get node worker-01 \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status}{"\n"}{end}'

A Node could then show output such as:

Ready=True
MemoryPressure=False
DiskPressure=False
PIDPressure=False
NetworkUnavailable=False
MaintenancePlanned=True

This makes the lifecycle state available through the standard Kubernetes API.

Publishing a Maintenance Condition

An administrator or an administrator-authorized controller is responsible for setting and clearing lifecycle conditions.

For example, a maintenance controller could publish:

status:
  conditions:
    - type: MaintenancePlanned
      status: "True"
      reason: ScheduledMaintenance
      message: "Node maintenance is scheduled for the maintenance window"

When the work starts, it can change the status:

status:
  conditions:
    - type: MaintenanceInProgress
      status: "True"
      reason: HardwareMaintenance
      message: "Node is undergoing hardware maintenance"

When maintenance finishes, the writer should set the condition to False or remove it.

Kubernetes does not define exclusive ownership, locking, or handoff between different writers. This means teams building maintenance controllers need to decide which component owns each condition and prevent competing controllers from continuously overwriting each other's status.

What Kubernetes 1.37 Does Not Do Automatically

This is an important limitation of the feature.

Setting:

MaintenanceInProgress=True

does not automatically:

Cordon the Node
Drain Pods
Evict workloads
Prevent scheduling
Stop the Node
Change scheduler behavior

Similarly, setting:

Drained=True

does not replace kubectl drain.

Core workload controllers do not currently change their behavior just because one of these lifecycle conditions is present.

Continue using the existing mechanisms for Node management:

kubectl cordon worker-01

kubectl drain worker-01 --ignore-daemonsets

Use taints and tolerations when you need more specific scheduling or eviction rules.

The lifecycle conditions provide the context around those operations.

Example: Coordinating a Maintenance Controller

Consider a controller responsible for planned hardware maintenance.

It could first publish:

MaintenancePlanned=True

The controller can then cordon the Node:

kubectl cordon worker-01

When draining begins, it can publish:

DrainInProgress=True

The actual drain still uses the normal Kubernetes mechanism:

kubectl drain worker-01 --ignore-daemonsets

After the controller's selected drain criteria are satisfied:

Drained=True

The maintenance operation can then start:

MaintenanceInProgress=True

Once the maintenance is complete and the Node has been verified, the controller can clear the maintenance condition and return the Node to service:

kubectl uncordon worker-01

This separation makes the system easier to reason about. One part performs the operation, while the lifecycle condition tells other components what is happening.

Graceful Node Shutdown

The fifth condition, GracefulNodeShutdownInProgress, covers another important lifecycle event.

Kubernetes already supports graceful Node shutdown. During a graceful shutdown, the kubelet attempts to terminate Pods through the normal Pod termination process and does not accept new Pods while the shutdown is in progress.

The new condition provides an explicit lifecycle signal that graceful shutdown is taking place.

This is useful for systems that need to distinguish a planned shutdown from an unexpected Node failure.

For example, monitoring or cluster-management automation can treat:

GracefulNodeShutdownInProgress=True

differently from an unhealthy Node that has unexpectedly become unavailable.

Common Mistakes

Treating a Condition as an Action

A lifecycle condition is an observation.

Setting:

MaintenanceInProgress=True

does not start maintenance.

The controller or administrator still needs to perform the required operations.

Using `Ready=False` for Planned Maintenance

Ready=False tells you that the Node is not healthy or available to accept Pods. It does not explain whether that state is caused by an unexpected failure or planned maintenance.

Lifecycle conditions provide that additional context.

Assuming Maintenance Always Requires a Drain

Not every maintenance operation needs workloads to leave the Node.

Decide whether a drain is necessary based on the actual maintenance operation.

Allowing Multiple Writers

If several controllers update the same lifecycle condition, one controller can overwrite another controller's state.

Define ownership before deploying lifecycle automation.

Advantages and Limitations

Area	Advantage	Limitation
Operations	Provides a standard way to describe Node lifecycle state	Does not perform the operation
Automation	Controllers can consume a common signal	Controllers must be designed to use it
Monitoring	Maintenance can be distinguished from failures	Monitoring systems need to consume the new conditions
Maintenance	Planned and active maintenance become visible through the Node API	Ownership must be coordinated between writers
Scheduling	Provides context for future lifecycle-aware behavior	Core scheduling behavior does not automatically change

Best Practices

If you plan to use Node lifecycle conditions in a production cluster, keep these practices in mind:

Use conditions to report state, not perform actions. Continue using cordon, drain, taints, and other established mechanisms for Node management.
Use stable reason values. A consistent reason makes the condition easier for automation to process.
Write useful messages. The message should help an administrator understand what is happening without inspecting another system.
Define condition ownership. Decide which controller or operational process can update each lifecycle condition.
Clear stale conditions. Set a condition to False or remove it when the lifecycle state is no longer active.
Do not infer maintenance from readiness alone. A failed Node and a Node undergoing planned maintenance are different operational situations.
Test automation against real lifecycle transitions. Make sure dashboards, alerts, and controllers behave correctly when a Node moves from planned maintenance to active maintenance and back to normal operation.

Conclusion

Kubernetes 1.37 Node lifecycle conditions provide a standard way to describe what is happening to a Node during maintenance, draining, and graceful shutdown.

The five conditions are:

DrainInProgress
Drained
MaintenancePlanned
MaintenanceInProgress
GracefulNodeShutdownInProgress

They do not replace existing Node management commands or automatically change workload behavior. Their immediate value is the shared context they add to the Node API.

For administrators and platform teams, that means maintenance state no longer has to be reconstructed from a mixture of readiness, taints, Pod state, labels, and external systems. A controller can publish the lifecycle state directly on the Node, while existing Kubernetes mechanisms continue to control scheduling, draining, and workload eviction.