What is a MachineConfig and MachineConfigPool in OpenShift, and why not just SSH into nodes?
Quick Answer
MachineConfig defines node-level OS configuration (kernel params, systemd units, files) managed declaratively. MachineConfigPools group nodes and control which MachineConfigs apply to which nodes. We use them instead of SSH because OpenShift follows immutable infrastructure — manual changes get overwritten on next reboot.
Detailed Answer
Think of MachineConfig like a building blueprint that specifies how every apartment on a floor should be configured — what appliances are installed, what the thermostat settings are, what fixtures are in the bathroom. Instead of a maintenance worker going door-to-door making changes (SSH into each node), you update the blueprint and the building management system (MCO) automatically applies changes to every apartment matching that floor plan. If you manually changed a thermostat, the system would revert it on the next maintenance cycle.
A MachineConfig is a Kubernetes custom resource that describes node-level configuration: kernel parameters (sysctl settings), systemd unit files, files to write to the node filesystem (like chrony.conf for NTP), container runtime settings, and OS-level packages. When you create or modify a MachineConfig, the Machine Config Operator (MCO) renders it into a final configuration, combines it with other MachineConfigs, and produces a 'rendered' config that represents the complete desired state of a node.
A MachineConfigPool (MCP) groups nodes and determines which MachineConfigs apply to them. OpenShift has three default MCPs: 'master' (control plane nodes), 'worker' (compute nodes), and optionally 'infra' (infrastructure nodes running routers, monitoring). Each MCP has a node selector that matches nodes by labels. When a MachineConfig changes, the MCO identifies which MCP is affected, then rolls out the update to nodes in that pool — cordoning, draining, applying the config, rebooting, and uncordoning each node.
The MCP controls the rollout strategy via maxUnavailable. For masters, this is always 1 (etcd quorum). For workers, you can increase it to update multiple nodes in parallel — balancing speed against risk. If you set maxUnavailable=3 on a 10-node worker pool, three nodes update simultaneously, reducing upgrade time but accepting that 30% of capacity is temporarily offline.
Why not just SSH in and make changes? Because OpenShift uses immutable infrastructure. The MCO continuously reconciles actual node state against the rendered MachineConfig. If you SSH in and change a sysctl value, it works temporarily — but on the next node reboot or MCO reconciliation, your change gets overwritten. Manual changes are also not auditable, not version-controlled, and not consistently applied across nodes. MachineConfig gives you GitOps-compatible, declarative, auditable node management.
A common pitfall: creating a MachineConfig with a syntax error in a systemd unit or an invalid kernel parameter can render nodes unbootable. The MCO will keep trying to apply it, and nodes may get stuck in a reboot loop. Always test MachineConfig changes on a non-production cluster or a dedicated MCP with one test node first.