The Ignition Trilogy — Control Plane
In a Kubernetes world, Control plane nodes are responsible for hosting all the different controllers that are required to run and manage a cluster. In an OpenShift world, these controllers always run in a set of three, each on a separate host to run in a highly available mode.
In my previous post, The Ignition Trilogy — Bootstrap, we have explored the contents of the “bootstrap.ign” file used for provisioning bootstrap node.
In this post, let’s explore the contents of “master.ign” file used for provisioning control plane nodes.
OpenShift installation process is dependent on bootstrap node to host the initial configuration data required for control plane nodes to initialise and form a cluster. Once the bootstrap process is completed, it can be reached via the cluster external (api) and internal (api-int) URLs.
Control plane ignition file contains only two things:
- Internal API URL hosted by the bootstrap machine to fetch the configuration data
- Root CA of the internal API URL
Using the internal API URL control plane nodes fetches the required configuration from bootstrap node. This URL is in the format of —
https://api-int.<cluster-name>.<base-domain>:22623/config/master
Now that we know what’s inside the control plane ignition file,
Let’s take control 🏗️
Let’s explore the configuration data used by the control plane nodes.
Users: As discussed in my previous post, there is a single user “Core” in every OpenShift node. This user is present in the configuration data along with the SSH keys used in the initial “install-config.yaml” file.
Configuration files: There is a lot of configuration data exposed by the “/config/master” endpoint exposed by the API INT URL.
But in this post, we will focus on the important ones only.
- /usr/local/bin/configure-ovs.sh — This file configures OVN networking on the node. Starting with OCP 4.12, OVNK is the default network plugin. This script is used to configure the inital node networking
- /etc/containers/storage.conf — This file has the storage configuration information like temp storage for containers
- /etc/mco/proxy.env — If you use proxy in your install-config.yaml this file is populated with those environment variables
- /etc/kubernetes/kubelet.conf — Kubelet configuration file
- /etc/mcs-machine-config-content.json — Machine configuration file that is deployed using the machine config server
Machine configuration file is a cluster object that is used to manipulate files on cluster nodes. You can apply multiple machine config objects which is rendered into a single file and applied to the nodes.
Systemd Units: Similar to bootstrap, most of the script (.sh) files are triggered via systemd units. Apart from the scripts there are a few unit files for specific clients like:
- kubelet.service — This is used to manage the Kubelet service running on the nodes
- crio.service — This is used to manage the crio service running on the nodes
- node-valid-hostname.service — This is used to make sure that the node has a non local hostname
- ovs-configuration.service — This is used to trigger the configure-ovs.sh script that configures the networking on the node
Run the below command to list the contents of the control plane ignition.
cat $HOME/testconfig/master.ign | jqIn this post, I have provided insights into the contents of the control plane ignition file. In the future posts, I will cover about the data plane ignition files generated during install process.
If you would like to know more about this topic, feel free to DM or comment on the post.
References:
Disclaimer:
The views expressed and content shared are solely of the author and doesn’t associate with author’s employer in any way. All the content shared is based on personal experience. This doesn’t guarantee the correctness of the information provided and it is readers responsibility to verify and use the content. All trademarks are property of their respective owners.
