What is Ignition in OpenShift?

Ignition is the first-boot provisioning engine used by Red Hat Enterprise Linux CoreOS (RHCOS) to configure OpenShift nodes.

Think of Ignition as the tool that builds the operating system configuration before Kubernetes starts.

A simple way to remember it is:

Ignition provisions a new node only once, during its first boot. After that, the Machine Config Operator (MCO) manages ongoing configuration changes.

Where Ignition Fits in OpenShift

                   New Server / VM
                          │
                          ▼
                 Boot RHCOS ISO/PXE
                          │
                          ▼
                 Download Ignition File
                          │
                          ▼
                    Ignition Runs
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
 Configure disks      Configure users   Configure files
 Configure network    Install SSH keys  Configure systemd
                          │
                          ▼
                  Reboot (if needed)
                          │
                          ▼
                kubelet starts
                          │
                          ▼
              Node joins OpenShift
                          │
                          ▼
         Machine Config Operator takes over

Why Ignition Exists

Before Kubernetes can run, the operating system must be prepared.

A new node initially knows nothing about:

• The cluster
• SSH keys
• Storage layout
• Network configuration
• Certificates
• kubelet
• CRI-O configuration

Ignition performs all of this automatically during the first boot.

Without Ignition, every node would require manual configuration before joining the cluster.

What Ignition Configures

During first boot, Ignition can configure:

1. Disk Partitioning

Example:

Disk
 │
 ├── EFI
 ├── Boot
 ├── Root
 └── Data

It can:

• Partition disks
• Create filesystems
• Format volumes
• Mount storage

2. Users

Creates users such as:

core

Configures:

• SSH authorized keys
• User groups
• Password hash (if specified)

Example:

passwd:
  users:
    - name: core
      sshAuthorizedKeys:
        - ssh-rsa AAAA...

3. Files

Ignition can create files like:

/etc/motd
/etc/sysctl.conf
/etc/containers/registries.conf

Example:

storage:
  files:
    - path: /etc/example.conf
      contents:
        source: data:text/plain;base64,...

4. Directories

Example:

/opt/company/
/etc/custom/

5. systemd Services

Ignition can enable:

systemd

Example:

Enable service
↓
Start at boot

6. Certificates

Can install:

• CA certificates
• Internal PKI
• Registry certificates

7. kubelet Bootstrap

Creates the initial kubelet configuration so that it can join the cluster.

Ignition During Installation

A typical OpenShift installation looks like this:

openshift-install
        │
        ▼
Generate Ignition Files
        │
 ┌──────┼──────────┐
 │      │          │
 ▼      ▼          ▼
bootstrap.ign
master.ign
worker.ign

Each node type receives its own Ignition configuration.

Bootstrap Node

The bootstrap node receives:

bootstrap.ign

Its job is to:

• Start temporary control plane
• Bootstrap etcd
• Start Kubernetes
• Create permanent control-plane nodes

After installation:

Bootstrap node
↓
Removed

Master Nodes

Master nodes receive:

master.ign

This configures:

• kubelet
• CRI-O
• certificates
• etcd membership
• control plane services

Worker Nodes

Workers receive:

worker.ign

This prepares:

• kubelet
• CRI-O
• networking
• certificates

Workers then register with the cluster.

Example Boot Process

Imagine a brand-new worker VM.

Step 1

Power on

↓

Boot RHCOS

Step 2

Downloads:

worker.ign

Step 3

Ignition starts

Step 4

Creates:

Users
Files
Directories
Storage
SSH Keys
systemd

Step 5

Starts kubelet

Step 6

kubelet connects:

api-int.cluster.example.com

Step 7

Node joins cluster

Ignition Runs Only Once

One of the most important interview points.

First Boot
↓
Ignition
↓
Never runs again

After first boot:

Machine Config Operator
↓
Machine Config Daemon
↓
Node Updates

Ignition vs Machine Config Operator

Many interviewers ask this.

Think of it like:

Ignition
↓
Build the house
↓
Machine Config Operator
↓
Maintain the house

Ignition File Format

Ignition files are JSON.

Example:

{
  "ignition": {
    "version": "3.4.0"
  }
}

Generated automatically by:

openshift-install create ignition-configs

Normally administrators do not edit these JSON files manually.

Where Ignition Comes From

During installation:

Install Config
↓
openshift-install
↓
Ignition Generator
↓
bootstrap.ign
master.ign
worker.ign

Relationship with RHCOS

New RHCOS Node
↓
Ignition
↓
Configure OS
↓
Start kubelet
↓
Join OpenShift
↓
Machine Config Operator

Relationship with Machine Config

Later in cluster life:

Administrator
↓
MachineConfig
↓
Machine Config Operator
↓
Machine Config Daemon
↓
Node Updated

Ignition is not involved anymore.

Security

Ignition can securely provision:

• SSH keys
• Certificates
• Registry trust
• Users
• Files
• Kernel arguments

Since it runs before Kubernetes starts, it establishes the initial trusted configuration.

Typical Files Created

Examples include:

/etc/hostname
/etc/containers/
systemd units
authorized_keys
CA certificates
kubelet configuration

Common Troubleshooting

Node never joins cluster

Check:

journalctl -b

Look for:

Ignition failed
network unreachable
cannot download ignition
certificate errors

Verify Ignition

During installation:

openshift-install wait-for bootstrap-complete

If bootstrap never completes:

Often:

• bootstrap.ign incorrect
• network issue
• DNS
• load balancer
• certificates

Machine Config changes not applied

Remember:

Ignition
DOES NOT RUN AGAIN

The issue is almost certainly with:

• Machine Config Operator
• Machine Config Daemon
• MachineConfigPool

Ignition vs Cloud-init

A common interview comparison.

Best Practices

• Never manually edit generated .ign files unless you fully understand the implications.
• Use openshift-install to generate them.
• Use Ignition only for initial provisioning.
• Use MachineConfig for day-2 operating-system changes.
• Avoid manual changes to RHCOS that bypass the Machine Config Operator.

Interview Answer (2 Minutes)

Ignition is the first-boot provisioning engine used by RHCOS in OpenShift. During installation, the openshift-install utility generates three Ignition files—bootstrap.ign, master.ign, and worker.ign—which are consumed when each node boots for the first time. Ignition configures the operating system by creating users, installing SSH keys and certificates, partitioning disks, creating files and directories, configuring systemd services, and preparing the kubelet so the node can join the cluster.

A key point is that Ignition runs only once, before Kubernetes starts. After the node joins the cluster, ongoing operating-system configuration is managed by the Machine Config Operator and the Machine Config Daemon through MachineConfig resources. In interviews, I emphasize that Ignition is for day-0 provisioning, while the Machine Config Operator handles day-2 lifecycle management, updates, and configuration changes across the cluster.