mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
55 lines
3.5 KiB
Plaintext
55 lines
3.5 KiB
Plaintext
// Module included in the following assemblies:
|
||
//
|
||
// * machine_configuration/machine-config-index.adoc
|
||
:_mod-docs-content-type: CONCEPT
|
||
[id="about-machine-config-operator_{context}"]
|
||
= About the Machine Config Operator
|
||
|
||
{product-title} {product-version} integrates both
|
||
operating system and cluster management. Because the cluster manages its own
|
||
updates, including updates to {op-system-first} on cluster nodes,
|
||
{product-title} provides an opinionated lifecycle management
|
||
experience that simplifies the orchestration of node upgrades.
|
||
|
||
{product-title} employs three daemon sets and controllers to
|
||
simplify node management. These daemon sets orchestrate operating system updates
|
||
and configuration changes to the hosts by using standard Kubernetes-style
|
||
constructs. They include:
|
||
|
||
* The `machine-config-controller`, which coordinates machine upgrades from the control
|
||
plane. It monitors all of the cluster nodes and orchestrates their configuration
|
||
updates.
|
||
* The `machine-config-daemon` daemon set, which runs on
|
||
each node in the cluster and updates a machine to configuration as defined by
|
||
machine config and as instructed by the MachineConfigController. When the node detects
|
||
a change, it drains off its pods, applies the update, and reboots. These changes
|
||
come in the form of Ignition configuration files that apply the specified
|
||
machine configuration and control kubelet configuration. The update itself is
|
||
delivered in a container. This process is key to the success of managing
|
||
{product-title} and {op-system} updates together.
|
||
* The `machine-config-server` daemon set, which provides the Ignition config files
|
||
to control plane nodes as they join the cluster.
|
||
|
||
The machine configuration is a subset of the Ignition configuration. The
|
||
`machine-config-daemon` reads the machine configuration to see if it needs to do
|
||
an OSTree update or if it must apply a series of systemd kubelet file changes,
|
||
configuration changes, or other changes to the operating system or {product-title}
|
||
configuration.
|
||
|
||
When you perform node management operations, you create or modify a
|
||
`KubeletConfig` custom resource (CR).
|
||
//See https://github.com/openshift/machine-config-operator/blob/master/docs/KubeletConfigDesign.md[KubeletConfigDesign] for details.
|
||
|
||
[IMPORTANT]
|
||
====
|
||
When changes are made to a machine configuration, the Machine Config Operator (MCO) automatically reboots all corresponding nodes in order for the changes to take effect.
|
||
|
||
You can mitigate the disruption caused by some machine config changes by using a node disruption policy. See _Understanding node restart behaviors after machine config changes_.
|
||
|
||
Alternatively, you can prevent the nodes from automatically rebooting after machine configuration changes before making the changes. Pause the autoreboot process by setting the `spec.paused` field to `true` in the corresponding machine config pool. When paused, machine configuration changes are not applied until you set the `spec.paused` field to `false` and the nodes have rebooted into the new configuration.
|
||
|
||
include::snippets/node-icsp-no-drain.adoc[]
|
||
====
|
||
|
||
There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated.
|