By default, for Google Cloud Platform (GCP) and Amazon Web Services (AWS) clusters, the Machine Config Operator (MCO) updates the boot image in the machine sets in your cluster whenever you update your cluster.
For GCP and AWS, you can disable the boot image management feature, if needed. When the feature is disabled, the boot image no longer updates with the cluster. For example, with the feature disabled, if your cluster was originally created with OKD 4.16, the boot image that the MCO would use to create nodes is the same 4.16 version, even if your cluster is at a later version.
However, using an older boot image could cause the following issues:
For information on how to disable this feature, see "Disabling boot image management". If you disable this feature, you can re-enable the feature at any time. For information, see "Enabling boot image management".
|
The ability to configure boot image management is available for only GCP and AWS clusters. It is not supported for clusters managed by the Cluster CAPI Operator.
|
How the cluster behaves after disabling or re-enabling the feature, depends upon when you made the change, including the following scenarios:
-
If you disable the feature before updating to a new OKD version:
-
The boot image version used by the machine sets remains the same OKD version as when the feature was disabled.
-
When you scale up nodes, the new nodes use that same OKD version.
-
If you disable the feature after updating to a new OKD version:
-
The boot image version used by the machine sets is updated to match the updated OKD version.
-
When you scale up nodes, the new nodes use the updated OKD version.
-
If you update to a later OKD version, the boot image version in the machine sets remains at the current version and is not updated with the cluster.
-
If you enable the feature after disabling:
-
The boot image version used by the machine sets is updated to the current OKD version, if different.
-
When you scale up nodes, the new nodes use the current OKD version in the cluster.
|
Because a boot image is used only when a node is scaled up, this feature has no effect on existing nodes.
|
To view the current boot image used in your cluster, examine a machine set:
Example machine set with the boot image reference
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
name: ci-ln-hmy310k-72292-5f87z-worker-a
namespace: openshift-machine-api
spec:
# ...
template:
# ...
spec:
# ...
providerSpec:
# ...
value:
disks:
- autoDelete: true
boot: true
image: projects/rhcos-cloud/global/images/rhcos-412-85-202203181601-0-gcp-x86-64 (1)
# ...
1 |
This boot image is the same as the originally-installed OKD version, in this example OKD 4.12, regardless of the current version of the cluster. The way that the boot image is represented in the machine set depends on the platform, as the structure of the providerSpec field differs from platform to platform. |
|
If any of the machine sets for which you want to enable boot image management use a *-user-data secret that is based on Ignition version 2.2.0, the Machine Config Operator converts the Ignition version to 3.4.0 when you enable the feature. OKD versions 4.5 and lower use Ignition version 2.2.0. If this conversion fails, the MCO or your cluster could degrade. An error message that includes err: converting ignition stub failed: failed to parse Ignition config is added to the output of the oc get ClusterOperator machine-config command. You can use the following general steps to correct the problem:
-
Disable the boot image management feature. For information, see "Disabling boot image management".
-
Manually update the *-user-data secret to use Ignition version to 3.2.0.
-
Enable the boot image management feature. For information, see "Enabling boot image management".
|