Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
openshift-merge-robot Merge pull request #864 from stbenjam/cloud
controller: don't set cloud provider for baremetal
Latest commit 9fc6860 Jun 18, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github update issue template to link to security response May 10, 2019
cmd Import pivot code Jun 17, 2019
docs Docs: Clean up hacking readme and add example podman commands Jun 11, 2019
examples docs&examples: replace machineSelector with nodeSelector Apr 12, 2019
hack hack/cluster-push-prep: Fix anonymous auth May 15, 2019
install Bug 1712507: etcdquorumguard: Respond correctly to TERM when pod shut… May 22, 2019
internal/clients add golangci-lint Jun 13, 2019
lib Add KernelArguments to MachineConfig May 20, 2019
manifests Merge pull request #840 from LorbusChris/shorts Jun 11, 2019
pkg Don't set cloud provider for baremetal Jun 18, 2019
test Merge pull request #797 from runcom/rpm-files Jun 13, 2019
vendor *: bump kube to 1.14.0 Jun 3, 2019
.gitattributes gitattrs: flag updated template testdata as generated files Apr 30, 2019
.gitignore .gitignore: add .vscode folder Apr 13, 2019
.golangci.yml add golangci-lint Jun 13, 2019
Dockerfile.machine-config-controller Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-controller.rhel7 Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-daemon Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-daemon.rhel7 Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-daemon.upstream Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-operator Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-operator.rhel7 Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-server Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.machine-config-server.rhel7 Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.setup-etcd-environment Dockerfile.*: bump to golang-1.12 May 31, 2019
Dockerfile.setup-etcd-environment.rhel7 Dockerfile.*: bump to golang-1.12 May 31, 2019
Gopkg.lock *: bump kube to 1.14.0 Jun 3, 2019
Gopkg.toml *: bump kube to 1.14.0 Jun 3, 2019
LICENSE legal: add apache 2.0 license Jul 25, 2018
Makefile add golangci-lint Jun 13, 2019
OWNERS OWNERS: add Erica Jun 12, 2019 Move to docs/ Mar 19, 2019
machine-config-daemon.spec Add a machine-config-daemon.spec Jun 4, 2019


OpenShift 4 is an operator-focused platform, and the Machine Config operator extends that to the operating system itself, managing updates and configuration changes to essentially everything between the kernel and kubelet.

To repeat for emphasis, this operator manages updates to systemd, cri-o/kubelet, kernel, NetworkManager, etc. It also offers a new MachineConfig CRD that can write configuration files onto the host.

The approach here is a "fusion" of code from the original CoreOS Tectonic as well as some components of Red Hat Enterprise Linux Atomic Host, as well as some fundamentally new design.

The MCO (for short) interacts closely with both the installer as well as Red Hat CoreOS. See also the machine-api-operator which handles provisioning of new machines - once the machine-api-operator provisions a machine (with a "pristine" base Red Hat CoreOS), the MCO will take care of configuring it.

One way to view the MCO is to treat the operating system itself as "just another Kubernetes component" that you can inspect and manage with oc.

The MCO uses CoreOS Ignition as a configuration format. Operating system updates use rpm-ostree, with ostree updates encapsulated inside a container image. More information in

Sub-components and design

This one git repository generates 4 components in a cluster; the machine-config-operator pod manages the remaining 3 sub-components. Here are links to design docs:

Interacting with the MCO

Because the MCO is a cluster-level operator, you can inspect its status just like any other operator that is part of the release image. If it's reporting success, then that means that the operating system is up to date and configured.

oc describe clusteroperator/machine-config

One level down from the operator CRD, the machineconfigpool objects track updates to a group of nodes. You will often want to run a command like this:

oc describe machineconfigpool

Particularly note the Updated and Updating columns.

Applying configuration changes to the cluster

The MCO has "high level" knobs for some components of the cluster state; for example, SSH keys and kubelet configuration. However, there are obviously a quite large number of things one may want to configure on a system. For example, offline environments may want to specify an internal NTP pool. Another example is static network configuration. By providing a MachineConfig object containing Ignition configuration, systemd units can be provided, arbitrary files can be laid down into writable locations (i.e. /etc and /var).

One known ergonomic issue right now for supplying files is that you must encode file contents via data: URIs. This is part of the current Ignition specification.

In the example below, the mode is in octal (notice the leading 0); however, decimal is the canonical representation for mode when inspecting MachineConfigs (in the example, it's 420 below).

This example MachineConfig object replaces /etc/chrony.conf with some custom NTP time servers; see the chrony docs.

# This example MachineConfig replaces /etc/chrony.conf
kind: MachineConfig
  labels: worker
  name: 50-examplecorp-chrony
      version: 2.2.0
      - contents:
          source: data:,
        filesystem: root
        mode: 0644
        path: /etc/chrony.conf
# oc get machineconfigs -o yaml 50-examplecorp-chrony
kind: MachineConfig
  creationTimestamp: 2019-03-25T18:25:39Z
  generation: 1
  labels: worker
  name: 50-examplecorp-chrony
  resourceVersion: "186713"
  selfLink: /apis/
  uid: 6445154f-4f2b-11e9-91e1-021aaf2ce4c0
      version: 2.2.0
      - contents:
          source: data:,
        filesystem: root
        mode: 420
        path: /etc/chrony.conf

The controller will notice the new MachineConfig and generate a new "rendered" version that looks like worker-<hash>. Use oc describe machineconfigpool/worker to monitor the status of the rollout of the new rendered config to each node.

Note this configuration only applies to workers (see the role: worker label); currently if you want to apply to both master and workers, you must create two separate MachineConfig objects.

Practically speaking, one may find it useful to generate your custom MachineConfig objects from a higher level tool. Although in the future ergonomic improvements are planned such as having a single MC apply to multiple labels, inline file encoding, etc.

What to look at after creating a MachineConfig

Once you create a MachineConfig fragment like the above, the controller will generate a new "rendered" version that will be used as a target. For more information, see MachineConfiguration.

In particular, you should look at oc describe machineconfigpool and oc describe clusteroperator/machine-config as noted above.

More information about OS updates

The model implemented by the MCO is that the cluster controls the operating system. OS updates are just another entry in the release image. For more information, see

Developing the MCO


Security Response

If you've found a security issue that you'd like to disclose confidentially please contact Red Hat's Product Security team. Details at

You can’t perform that action at this time.