Modifying node configurations in OpenShift 4.X
by Juan Antonio Osorio Robles
OpenShift 4.X relies heavily on operators in order to configure… just about everything. This includes the configuration of the hosts that run the OpenShift installation. In order to configure the aforementioned hosts, the installation comes with a running instance of the “machine-config-operator”, which is an operator that applies host configurations and restarts the host whenever it detects configuration changes.
So, to learn how to use this, lets change /etc/chrony.conf and set up some specific servers.
First of all, lets look at the configuration we want to apply to chrony.conf:
This configuration is based on what’s shipped by default in OpenShift, except that we made the deployment get its time from the three specific fedora nodes in ntp.org.
The machine-config-operator gives us a construct named
allows us to apply configuration changes to specific files and to specific
What are these roles?
Well, the machine-config-operator works with so called
which are sets of nodes that have a specific role in your system. Most likely
these nodes will run different services, and serve different purposes.
To view all of the roles in your system, do:
In my basic deployment, I see the following:
The main thing to note here are the names of the roles, which we’ll use in our configuration.
Another thing to note is that currently, the configurations need URL encoding
For this, we can use the following snippet:
This will output the contents of the configuration file (in this case called exmaple-chrony.conf), and read it in a python script which will encode the contents, including newlines.
This will give us the following output:
With this in mind, lets apply the aforementioned configuration!
Apply the configuration
We’ll call this yaml file chrony-enable-worker.yaml.
Note that we specified the role via the
machineconfiguration.openshift.io/role label in the
metadata. We also gave it a name that reflects the application order (50 will
be applied in the middle), the role’s name, and the configuration we’re
Lets see all of the
MachineConfig objects that are currently applied to our
Lets now apply our configuration
Having applied our changes, we’ll see that the new configuration applies fairly in the middle:
Going back to our
MachineConfig declaration, lets also note that the
configuration was applied to the
source key, and had the
in it. This details are important things to remember if you want your
configuration to be applied correctly, as they’re things that the
If we want to apply the configuration to other hosts, we’ll need a
MachineConfig object per-role (This might be fixed in the
Verifying our configuration changes
Lets log into our node to check that the changes were successfully applied (Note that it might take some time for the changes to apply, since they need to be picked up by the operator first).
Lets first choose one node to view.
To check the nodes in your system, do:
Notice that the roles of the host are specified in their own column.
So, given that it’s a worker node, lets choose ip-10-0-138-158.eu-west-1.compute.internal.
To log into the node, we do:
Once in the node, you can do the following command:
This should show that there are 3 sources that chronyd is using, and the IP addresses to all of them.
The ultimate source of truth
Another feature of the machine-config-operator, is that it allows you to query an aggregated structure with all of the configurations that have been rendered into the host.
Remember the output of getting the
MachineConfigPools? Lets get it
You will note two things:
The items under the
MachineConfigobjects that you can query from the system.
The keys under
CONFIGchanged from last time we checked! This was because there is a new rendering, since we applied the new chronyd configuration.
To look at the render, we can do the following:
This will show us a yaml representation of all of the configurations that have been applied to that role.