mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
47 lines
3.7 KiB
Plaintext
47 lines
3.7 KiB
Plaintext
:_mod-docs-content-type: ASSEMBLY
|
|
:context: machine-configs-configure
|
|
[id="machine-config-node-disruption_{context}"]
|
|
= Using node disruption policies to minimize disruption from machine config changes
|
|
include::_attributes/common-attributes.adoc[]
|
|
|
|
toc::[]
|
|
|
|
By default, when you make certain changes to the fields in a `MachineConfig` object, the Machine Config Operator (MCO) drains and reboots the nodes associated with that machine config. However, you can create a _node disruption policy_ that defines a set of changes to some Ignition config objects that would require little or no disruption to your workloads.
|
|
|
|
A node disruption policy allows you to define the configuration changes that cause a disruption to your cluster, and which changes do not. This allows you to reduce node downtime when making small machine configuration changes in your cluster. To configure the policy, you modify the `MachineConfiguration` object, which is in the `openshift-machine-config-operator` namespace. See the example node disruption policies in the `MachineConfiguration` objects that follow.
|
|
|
|
[NOTE]
|
|
====
|
|
There are machine configuration changes that always require a reboot, regardless of any node disruption policies. For more information, see _About the Machine Config Operator_.
|
|
====
|
|
|
|
After you create the node disruption policy, the MCO validates the policy to search for potential issues in the file, such as problems with formatting. The MCO then merges the policy with the cluster defaults and populates the `status.nodeDisruptionPolicyStatus` fields in the machine config with the actions to be performed upon future changes to the machine config. The configurations in your policy always overwrite the cluster defaults.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
The MCO does not validate whether a change can be successfully applied by your node disruption policy. Therefore, you are responsible to ensure the accuracy of your node disruption policies.
|
|
====
|
|
|
|
For example, you can configure a node disruption policy so that sudo configurations do not require a node drain and reboot. Or, you can configure your cluster so that updates to `sshd` are applied with only a reload of that one service.
|
|
|
|
You can control the behavior of the MCO when making the changes to the following Ignition configuration objects:
|
|
|
|
// I used this wording for the objects to match the previous section in the assembly: file:///home/mburke/openshift-docs/_preview/openshift-enterprise/mco-node-disruption-policy/post_installation_configuration/machine-configuration-tasks.html#what-can-you-change-with-machine-configs.
|
|
* *configuration files*: You add to or update the files in the `/var` or `/etc` directory. You can configure a policy for a specific file anywhere in the directory or for a path to a specific directory. For a path, a change or addition to any file in that directory triggers the policy.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If a file is included in more than one policy, only the policy with the best match to that file is applied.
|
|
|
|
For example, if you have a policy for the `/etc/` directory and a policy for the `/etc/pki/` directory, a change to the `/etc/pki/tls/certs/ca-bundle.crt` file would apply the `etc/pki` policy.
|
|
====
|
|
|
|
* *systemd units*: You create and set the status of a systemd service or modify a systemd service.
|
|
* *users and groups*: You change SSH keys in the `passwd` section postinstallation.
|
|
* *ICSP*, *ITMS*, *IDMS* objects: You can remove mirroring rules from an `ImageContentSourcePolicy` (ICSP), `ImageTagMirrorSet` (ITMS), and `ImageDigestMirrorSet` (IDMS) object.
|
|
|
|
include::snippets/machine-config-node-disruption-actions.adoc[]
|
|
|
|
include::modules/machine-config-node-disruption-example.adoc[leveloffset=+1]
|
|
include::modules/machine-config-node-disruption-config.adoc[leveloffset=+1]
|