Preparing to perform an EUS-to-EUS update

Due to fundamental Kubernetes design, all {product-title} updates between minor versions must be serialized. You must update from {product-title} <4.y> to <4.y+1>, and then to <4.y+2>. You cannot update from {product-title} <4.y> to <4.y+2> directly. However, administrators who want to update between two Extended Update Support (EUS) versions can do so incurring only a single reboot of non-control plane hosts.

Important

EUS-to-EUS updates are only viable between even-numbered minor versions of {product-title}.

There are a number of caveats to consider when attempting an EUS-to-EUS update.

EUS-to-EUS updates are only offered after updates between all versions involved have been made available in stable channels.
If you encounter issues during or after upgrading to the odd-numbered minor version but before upgrading to the next even-numbered version, then remediation of those issues may require that non-control plane hosts complete the update to the odd-numbered version before moving forward.
You can do a partial update by updating the worker or custom pool nodes to accommodate the time it takes for maintenance.
You can complete the update process during multiple maintenance windows by pausing at intermediate steps. However, plan to complete the entire update within 60 days. This is critical to ensure that normal cluster automation processes are completed.
Until the machine config pools are unpaused and the update is complete, some features and bugs fixes in <4.y+1> and <4.y+2> of {product-title} are not available.
All the clusters might update using EUS channels for a conventional update without pools paused, but only clusters with non control-plane MachineConfigPools objects can do EUS-to-EUS update with pools paused.