Talos 1.13 Adds VRF Routing and Live CPU Hot-Add for Kubernetes

Talos Linux treats the Kubernetes node as an appliance rather than a general-purpose server. It does not include an SSH daemon, shell access for routine tasks, or a package manager. Instead, operators manage the host using declarative configuration and APIs, rather than logging in to edit files. This approach keeps node state predictable, but it also means Talos itself must fully support host-level networking and hardware features.

Talos 1.13 introduced two features to address this need. The release added Virtual Routing and Forwarding, along with a new VRFConfig machine configuration document, and included udev rules for CPU hot-add in virtual machines. Both features are still available in later versions, including Talos 1.14, but they first appeared in 1.13.

These changes address two different needs for Kubernetes teams. VRF support allows a machine to have multiple routing domains, which is useful when a node connects to separate management, storage, service, or fabric networks. CPU hot-add allows a supported hypervisor to add virtual CPUs to a running Talos node without rebooting the guest.

Why host-level features matter more on Talos

On a typical Linux server, operators can fix networking or device issues with shell commands, local scripts, packages, or new udev rules. Talos removes these options on purpose. Its read-only, API-managed model aims to make machines reproducible and reduce configuration drift.

This changes how low-level features reach Kubernetes nodes. If the operating system does not support a routing setup or hot-plug workflow, operators cannot rely on manual changes to the host as a lasting solution.

Talos 1.13 approached both features in a way that fits that operating model. VRFs became a machine configuration object. CPU hot-add behavior was incorporated into the shipped udev configuration. The operator can continue treating the node as an immutable system rather than creating an exception for advanced networking or VM resizing. 

Where VRFs fit into Kubernetes networking

Kubernetes networking is usually discussed in terms of pods, services, CNIs, ingress, and network policy. A node still has a Linux networking stack underneath those layers, and that stack may need to connect to several external networks.

This is especially clear in bare-metal clusters. A node may have separate interfaces for management, storage, an upstream routed fabric, or traffic for special workloads. Using a single routing table for all these paths can lead to complicated route-selection rules, especially if networks have overlapping address ranges or need different gateways.

A VRF provides each interface with its own routing context. Operators can put certain links into one VRF and leave others in the default routing domain. Routes for that VRF stay with its table and do not compete with the main table. Talos also lets you declare addresses and static routes directly in the VRFConfig document.

VRF is not a firewall on its own. It separates routing domains, but traffic policy still depends on the rest of the Linux and Kubernetes networking setup. Here, its main purpose is to separate routes and give clearer control over which routing table each interface uses.

CPU hot-add removes a reboot from VM resizing

The second change targets virtualized Talos clusters.

Before this feature, users found that adding CPU cores to a running Talos VM did not make the new processors available without rebooting the guest. The original request mentioned environments such as VMware vSphere, Proxmox, and KVM/libvirt, where the hypervisor supports CPU hot-plug, but the guest OS still needs to handle the addition of new processors properly.

Talos 1.13 added udev rules to support this. When a supported virtual environment adds CPUs, Talos can now handle the hot-add event within the running guest without requiring a full node reboot. Sidero Labs lists this change in the 1.13 release as VM Hot-Add Support.

This may seem like a small OS detail, but rebooting a Kubernetes node is more disruptive than rebooting a regular VM. Talos’ upgrade process usually cordons the node, drains workloads, shuts down processes, reboots, rejoins the cluster, and then makes the node available for workloads again.

Removing the guest reboot from a CPU increase gives infrastructure teams another way to adjust compute capacity without immediately forcing that lifecycle sequence.

Hot-add does not remove the need for capacity planning

CPU hot-add is still bounded by the virtualization platform. The hypervisor must support CPU hot-plug, and the VM must be configured for it. Platform-specific restrictions still apply. Talos cannot make a hypervisor expose processors that it does not support adding at runtime.

Kubernetes resource accounting is another layer to watch. The OS recognizing a new CPU and Kubernetes scheduling additional workload are related but separate steps. Operators should verify the node’s reported CPU capacity and kubelet behavior after a resize, rather than assuming that a successful hypervisor operation has automatically changed every scheduling decision.

The feature is best viewed as removing one operating-system limitation from the resizing path. It does not make vertical VM scaling a replacement for cluster autoscaling or for adding worker nodes. Horizontal and vertical scaling address different problems, and the right choice depends on workload placement, disruption constraints, and the underlying infrastructure of the cluster.

Both features fit Talos’ API-driven model

VRF routing and CPU hot-add solve unrelated problems, but they share a design theme.

Talos does not ask operators to temporarily step outside its management model to get these behaviors. VRFs are expressed as machine configuration. CPU hot-add support is handled by the operating system’s device-management rules. That matters because special-case host administration can become difficult to track across a fleet.

For bare-metal operators, VRFConfig provides a cleaner, declarative representation of host routing when nodes span multiple networks. For virtualized fleets, CPU hot-add reduces the need to reboot a worker simply to make newly assigned processors available to the guest.

The additions are relatively low-level and do not change how Kubernetes applications are written. They change the machinery underneath Kubernetes: how packets select a route in the routing table and how a running node reacts when its virtual hardware changes. For teams operating Talos across physical and virtual infrastructure, there are small OS changes that can eliminate recurring work in node operations.