// Module included in the following assemblies:
//
// * updating/preparing_for_updates/kmm-preflight-validation.adoc

:_mod-docs-content-type: CONCEPT
[id="kmm-day0-day2-lifecycle-management_{context}"]
= Lifecycle management

[role="_abstract"]
KMM lifecycle management on {product-title} lets you upgrade kmods from Day 0 through Day 2 without rebooting nodes when the driver supports it.


[NOTE]
====
This will not work if the upgrade requires a node reboot, for example, when rebuilding `initramfs` files is needed.
====

Use one of the following options for lifecycle management.

[id="kmm-kmod-in-tree-driver_{context}"]
== Treat the kmod as an in-tree driver

Use this method when you want to upgrade the kmods. In this case, treat the kmod as an in-tree driver and create a `Module` in the cluster with the `inTreeRemoval` field to unload the old version of the driver.

Note the following characteristics of treating the kmod as an in-tree driver:

* Downtime might occur as KMM tries to unload and load the kmod on all the selected nodes simultaneously.
* This works if removing the driver makes the node lose connectivity because KMM uses a single pod to unload and load the driver.

[id="kmm-ordered-upgrade_{context}"]
== Use ordered upgrade

You can use ordered upgrade (ordered_upgrade.md) to create a versioned `Module` in the cluster representing the kmods with no effect, because the kmods are already loaded.

Note the following characteristics of using ordered upgrade:

* There is no cluster downtime because you control the pace of the upgrade and how many nodes are upgraded at the same time; therefore, an upgrade with no downtime is possible.
* This method will not work if unloading the driver results in losing connection to the node, because KMM creates two different worker pods for unloading and another for loading. These pods will not be scheduled.
