siderolabs/talos  /  overview go 1.24 v1.14 MPL-2.0
An API-managed Kubernetes OS — studied from the source

Talos Linux

A minimal, immutable Linux distribution built for one job: running Kubernetes. No shell, no SSH, no package manager — just a kernel, a single PID 1 called machined, and a graph of controllers reconciling typed resources until the machine matches its configuration. This walkthrough reads the siderolabs/talos source from kernel hand-off up to a running cluster.

1PID 1: machined does everything
~200COSI controllers reconcile the OS
0shells · SSH · login prompts
:50000one mTLS gRPC API, the only door
What Talos is.

Talos Linux is a Linux distribution from Sidero Labs with everything stripped away except what Kubernetes needs. The root filesystem is a read-only squashfs; the machine is described by a single declarative machine config; and the only way to manage a node is a mutually-authenticated gRPC API. Under the hood it is built on COSI — the same resource/controller engine this site's companion COSI walkthrough dissects. If COSI is the engine, Talos is the canonical machine built on it.

#The one-diagram mental model

A Talos node is a stack of layers, and everything above the kernel lives inside one process. machined is PID 1. It runs an imperative sequencer (ordered phases that boot, install, upgrade, reset the machine) and a declarative COSI controller runtime (a reconciliation graph that continuously drives the machine — network, storage, secrets, Kubernetes — toward the config). The only external surface is apid, a single mTLS gRPC port. Kubernetes runs on top, managed by the controllers, not by a human.

apid · the only door mTLS gRPC :50000 · roles in certs talosctl › machined — PID 1 Sequencer imperative · v1alpha1 Initialize → Install → Boot · Upgrade Reset · Reboot ordered phases + tasks COSI controller runtime declarative · v1alpha2 · ~200 controllers network block / volumes secrets k8s / etcd resources ⇄ reconcile, shared state Service manager supervised, in containerd etcd · kubelet apid · trustd udevd · containerd deps + health + restart Linux kernel read-only squashfs root · overlays · KSPP-hardened · measured boot EFI · META · STATE · EPHEMERAL Kubernetes — control plane as static pods, kubelet & etcd as Talos services rendered from machine config · no kubeadm
Hover any block to trace it. machined hosts both the sequencer and the COSI graph; apid is the only way in.

#Four design principles

🔒

Immutable & minimal

The OS ships as a read-only squashfs image — no apt, no shell, no mutable system. Everything that can change lives in a small EPHEMERAL partition. The image is reproducible and tamper-evident; "configuration drift" is structurally impossible.

🛰️

API-managed, not logged-into

There is no SSH and no console login. The single surface is a mutually-authenticated gRPC API on port 50000, with the caller's role carried in their client certificate. Rebooting, reading a file, upgrading — all are typed RPCs.

🔁

Declarative & reconciled

You give Talos a desired state — the machine config — and ~200 COSI controllers continuously reconcile reality toward it. Network, disks, certificates, the Kubernetes control plane: all are the output of controllers, not scripts.

☸️

Kubernetes as a built-in

Talos has no notion of "install Kubernetes." etcd and the kubelet run as supervised services; the control plane runs as kubelet static pods rendered from config. talosctl bootstrap lights the first node and the rest join automatically.

#Why read this

Talos is one of the cleanest large-scale examples of the "desired state in, real-world machine out, kept reconciled" pattern in production. It shows what an operating system looks like when it is built like a Kubernetes operator: a typed resource graph instead of init scripts, a reconcile loop instead of a runbook, an API instead of a shell. Whether you run Talos or just want to steal its ideas for your own control plane, the source is unusually legible — and this deep dive is a map of it.

How to read this — eleven pages, five movements.

Foundations (01–03) are how a Talos machine comes alive: the boot sequencer, the COSI runtime that hosts the controllers, and the machine config they read. Subsystems (04–06) are the controller families doing the real work: storage, networking, and Kubernetes/etcd. Surface & trust (07–08) are how you talk to a node and how it secures itself. Lifecycle (09) is atomic A/B upgrades and the imager. Synthesis (10) ties it together and traces a packet from power-on to a Ready node. Read top-to-bottom, or jump to whatever subsystem you're debugging.

#A 30-second taste

Three commands stand up a single-node Talos cluster. Notice there is nothing to ssh into and nothing to configure by hand — you apply a declarative config, then bootstrap.

stand up a nodebash
# 1. generate machine + client configs for a cluster
talosctl gen config my-cluster https://10.0.0.10:6443

# 2. apply the machine config to a freshly-booted Talos node (maintenance mode)
talosctl apply-config --insecure --nodes 10.0.0.10 --file controlplane.yaml

# 3. bootstrap etcd on the first control-plane node — one time, one node
talosctl bootstrap --nodes 10.0.0.10

# the node now reconciles itself into a working Kubernetes control plane
talosctl --nodes 10.0.0.10 health
talosctl --nodes 10.0.0.10 kubeconfig .

Everything else in this deep dive explains what happens between step 2 and a Ready node. Start at the bottom of the stack — how Talos boots.