READ-ONLY ROOTFS

TALOS LINUX · SPEC SHEET

Talos:Immutable, Minimal,
Mighty.

Running Kubernetes on Bare Metal with Talos

AGENDA

What we're covering tonight

01Why the design principles behind Kubernetes matter

02Who’s talking

03What’s wrong with general-purpose Linux

04Eight design criteria for a Kubernetes OS

05Talos components — and how it actually works

06How to start: factory, config, upgrades

07Live demo — bare metal → GitOps

OPENING QUESTION

Have you ever thought about the principles behind Kubernetes design?

What if we used those same principles to design a brand-new OS — one built to run nothing but Kubernetes workloads?

WHO'S TALKING

Reza Chalak

DevOps Engineer @ ProLion

We build cybersecurity products. My job: keep the Kubernetes underneath them boring, reconciled, and hard to break.

Company

ProLion — Cybersecurity Products

Role

DevOps Engineer

Focus Tonight

Bare metal → Talos → GitOps, live on stage

THE QUESTION NOBODY ASKS

What's wrong with general-purpose Linux machines?

The Problem

Package manager→drift, node by node

SSH access→an unaudited surface

A persistent shell→undeclared state

General tooling→CVEs nobody asked for

All We Actually Need

Kernel — nothing riding on top of it by default
A few binaries — exactly what Kubernetes needs to run
An API to talk to — never a shell
Containerd (CRI) — the one runtime, no shim zoo

DESIGN CRITERIA

What criteria matter when you design an OS for Kubernetes?

01

API-Driven

Every interaction goes through an API. Never a shell, never SSH.

02

Single Source Of Truth

One declarative document fully describes the node.

03

Declarative States

Say what the node should be — never the steps to get there.

04

Reconciliation Loop

Validate, then converge continuously toward the desired state.

05

Minimal

Only what Kubernetes needs. Nothing else ships.

06

Maintainable

Fewer moving parts — fewer things that can drift or break.

07

Secure By Default

mTLS, PKI identity, zero default passwords — not bolted on later.

08

Replaceable Node

Don't repair a node. Replace it, like a pod.

TALOS COMPONENTS

Talos components — and how it actually works

The only way onto a Talos node is apid's gRPC API — every daemon reconciles through the same COSI resource model, straight down to the kernel.

HOW TO START

From zero to a running node

01

Talos Factory

Build a custom install image: pick extensions, kernel args, architecture.

02

Deployment Types

Bare metal, VMware, Proxmox, every major cloud — same image model.

03

Extensions

Drop in exactly what the hardware needs. Nothing ships unasked.

04

Kernel Arguments

Declared in the image, never edited on a running box.

05

Machine Config

One YAML fully describes a control plane or worker node.

06

Upgrades

A/B partitions, one API call, roll back just as fast.

LIVE DEMO

Bare metal → GitOps, live on stage

1

Blank Hardware → Talos Boots

Boot the install image, apply a Machine Config: install disk, a VIP on the node's interface.

2

talosctl bootstrap

One command, one production-grade single-node cluster — allowSchedulingOnControlPlanes included.

3

A Local Registry, Close To The Metal

A second disk mounted as a UserVolumeConfig runs zot as a static pod — a pull-through mirror for Docker Hub, GHCR, registry.k8s.io and Quay.

4

FluxCD Bootstraps Itself

An inline-manifest Job installs Flux, which points an OCIRepository straight at that same zot registry — GitOps-driven from first boot.

Thank You.

Reza Chalak — DevOps Engineer, ProLion

Talos Linux · talos.dev

CNCF Vienna Meetup · 03 September 2026

linkedin.com/in/rezachalak

Questions?

Talos:Immutable, Minimal,Mighty.