1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/kmm-day0-day2-lifecycle-management.adoc
2024-05-16 12:57:14 +00:00

37 lines
1.8 KiB
Plaintext

// 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
You can leverage KMM to manage the Day 0 through Day 2 lifecycle of kmods without a reboot when the driver allows 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.