OpenFest 2026

From Zero to Immutable Kubernetes: From First Node to Fleet
Език: Български

Configuration management traditionally converges a running machine toward a desired state. Immutable infrastructure moves that convergence earlier: build the desired state into an image, then replace or roll back that image instead of modifying the running system.

In this hands-on workshop, you’ll follow that model from a single Kubernetes node to operating a fleet.

You’ll build your own immutable OS image, boot it, form a Kubernetes cluster, perform an atomic upgrade, and deliberately roll it back. Then you’ll move beyond the individual cluster. You’ll run your own fleet server, PXE-boot new machines, have them register themselves on first boot, and operate their lifecycle centrally without manually installing or configuring each machine.

Along the way, we’ll look at an important distinction: uniform operations don’t require identical machines. Hardware and workload requirements can live in different system images while provisioning, upgrades, rollback, and recovery follow the same lifecycle.

You’ll learn how to:

Understand what changes operationally when the OS becomes an image rather than something modified in place
Build a tailored immutable OS image using Ubuntu, Fedora, Debian, openSUSE, Alpine, Rocky, or Kairos’s minimal Hadron base
Deploy Kubernetes on top of it and grow from one node to a multi-node cluster
Perform atomic A/B upgrades and rollback
Provision new machines over PXE and have them register automatically for management
Operate node lifecycles centrally while using build-time policy to constrain which remote operations a node will accept
Roll out OS upgrades through Kubernetes-native declarative plans
Integrate image creation and fleet operations into CI/CD
All exercises use Kairos and AuroraBoot, its bootstrap and fleet-management tooling. Both are open source. The workshop focuses on image-based desired state, separation of persistent data from the system, replacement and rollback, automated provisioning, and managing different system images through a common lifecycle.


The workshop is self-paced and hands-on. Attendees follow a core path while the instructors circulate and help with exercises. Faster attendees can continue into CI/CD and advanced exercises.

Part 1: Build

Immutable operations
We’ll start with the operational model: what an immutable OS is, what belongs in the system image, what remains persistent, and how day-two operations change when modifying the running OS is no longer the normal management mechanism.

Kairos concepts
We’ll look at A/B system partitions, persistent data separation, recovery mode, cloud-config-driven provisioning, and how these pieces support replacement and rollback instead of in-place mutation.

Build your system
Start AuroraBoot’s web mode and use its guided image builder to create the system image you’ll use for the rest of the workshop.

Instead of starting from a prebuilt distribution-specific ISO, you’ll choose a supported base and build the immutable artifact yourself. The image, rather than the running machine, becomes the starting point for configuration.

Part 2: Cluster

Deploy your first Kubernetes node
Boot the image in a VM with K3s configured through cloud-config. On first boot, the node registers with the fleet server and becomes available for lifecycle management.

Upgrade and roll back
Perform an A/B system upgrade manually, then roll it back. Trigger the same lifecycle operation through the fleet server and compare the two approaches.

Grow the cluster
PXE-boot worker nodes from the fleet server and join them to the cluster through cloud-config rather than configuring them interactively.

At this point you’ll have gone from an image you built yourself to an operational multi-node Kubernetes cluster.

Part 3: Fleet

Provision with PXE
Use the fleet server’s netboot service to PXE-boot additional machines. Instead of installing each machine manually, they boot the appropriate artifact, provision themselves, and register for management.

Operate the fleet
Perform lifecycle operations such as upgrade, reboot, reset, and applying cloud configuration from the fleet server.

We’ll also examine the boundary between server and node. The operations a server can request are constrained by an allowlist built into the image. Central management therefore does not automatically give the server unrestricted control over every managed machine.

Different machines can require different artifacts without requiring a different operational model for every machine class.

Kubernetes-native lifecycle management
Use the Kairos Operator to express OS upgrades as declarative in-cluster plans and compare this with operating nodes directly through the fleet server.

Automate it
Move image creation into GitHub Actions using the same image-building path exercised earlier, then interact with the fleet server programmatically through its REST API and Go client.

By the end of the core path, you’ll have worked through the complete lifecycle:

build → provision → boot → register → cluster → upgrade → rollback → automate

Optional Advanced Exercises

For attendees who complete the core path early, additional exercises will cover:

Air-gapped image building and provisioning
Trusted Boot with TPM/UEFI and managed SecureBoot keys
Provisioning physical servers through Redfish BMCs
Target Audience and Prerequisites

This workshop is intended for platform engineers, SREs, infrastructure engineers, and solution architects who operate Kubernetes outside fully managed environments or want to understand image-based infrastructure management.

You should be comfortable with Linux and familiar with basic Kubernetes concepts. You’ll need a laptop capable of running containers and a small number of virtual machines, or equivalent compute in a cloud environment.

No operating-system building or Kairos experience is required.

Attendees will leave having built an immutable system themselves and followed it through its operational lifecycle, from image to Kubernetes node, cluster, and centrally managed fleet.