Architecture, Implementation, and Optimization of Talos OS on Proxmox: The Ultimate Guide for Homelabs and Production Environments

The technological evolution of home data centers and corporate infrastructures has led to the emergence of solutions that challenge traditional paradigms of system administration. In this context, Talos OS stands out not as a simple Linux distribution, but as a radical reinterpretation of the operating system designed exclusively for Kubernetes. Its immutable, minimal, and entirely API-governed nature represents an ideal solution for those desiring a stable, secure Proxmox environment free from the technical debt associated with manual management via SSH.1 This report examines in depth every aspect necessary to take a Talos OS cluster from scratch to a production configuration on Proxmox VE, analyzing the complexities of networking, data persistence, and hypervisor-specific optimizations.

Architectural Fundamentals of Talos OS and the Immutable Approach

#

The philosophy behind Talos OS is centered on eliminating everything that is not strictly necessary for running Kubernetes. Unlike a traditional Linux distribution, Talos does not include a shell, has no package manager, and does not allow SSH access.1 All management occurs through a gRPC interface protected by mTLS (Mutual TLS), ensuring that every interaction with the system is authenticated and encrypted from the ground up.2

Filesystem Structure and Layer Management

#

The Talos filesystem architecture is one of its most distinctive traits and ensures system resilience against accidental corruption or malicious attacks. The core of the system resides in a read-only root partition, structured as a SquashFS image.5 During boot, this image is mounted as a loop device in memory, creating an immutable base. Over this base, Talos overlays different layers to handle runtime needs:

This separation ensures that a configuration error or a corrupted temporary file never compromises the integrity of the underlying operating system. The EPHEMERAL partition, mounted at /var, hosts everything Kubernetes requires to function: from the etcd database in control plane nodes to images downloaded by the container runtime (containerd).5 A critical aspect of Talos’s design is that changes made to files like /etc/resolv.conf or /etc/hosts are managed via bind mounts from a system directory that is completely regenerated at every reboot, forcing the administrator to define such settings exclusively in the declarative configuration file.5

The API-driven Operating Model

#

The shift from imperative management (commands executed via shell) to declarative (desired state defined in YAML) is the heart of the Talos experience. The talosctl tool acts as the primary client communicating with the apid daemon running on each node.5 This architecture allows treating cluster nodes as “cattle” rather than “pets”, where replacing a non-functioning node is preferable to manual repair. The absence of SSH drastically reduces the attack surface, as it eliminates one of the most common entry points for malware and lateral movements within a network.2

Infrastructure Planning on Proxmox VE

#

Implementing Talos on Proxmox requires careful virtual machine configuration to ensure that paravirtualized drivers and security features are properly leveraged. Proxmox, based on KVM/QEMU, offers excellent support for Talos, but some default settings can cause instability or sub-optimal performance.8

Resource Allocation and Hardware Requirements

#

While Talos is extremely efficient, Kubernetes requires minimum resources to manage the control plane and workloads. Resource distribution must take into account not only current needs but also future cluster growth.

A fundamental technical detail concerns the CPU microarchitecture. Starting from version 1.0, Talos requires support for the x86-64-v2 instruction set.10 In Proxmox, the default “kvm64” CPU type might not expose the necessary flags (such as cx16, popcnt, or sse4.2). It is highly recommended to set the VM CPU type to “host” or use a custom configuration that explicitly enables these extensions to avoid boot failure or sudden crashes during intensive workload execution.10

VM Configuration for Optimal Performance

#

For a smooth integration, the virtual machine configuration must reflect modern virtualization standards. Using UEFI (OVMF) is preferable to traditional BIOS, as it allows for more secure boot management and supports larger disks with GPT partitioning.10 The chipset should be set to q35, which offers superior native PCIe support compared to the outdated i440fx. Regarding storage, using the VirtIO SCSI Single controller with the “iothread” option and enabling “discard” support (if supported by the physical backend) ensures efficient disk space management and high input/output performance.6

Implementation: From Boot to Cluster Ready

#

The Talos installation process does not include a traditional interactive installer. Booting occurs via an ISO that loads the operating system entirely into RAM, leaving the node awaiting remote configuration.6

Workstation Preparation and talosctl

#

Before interacting with VMs on Proxmox, the local management environment must be prepared. The talosctl binary must be installed on the administrator’s workstation. This tool handles secret generation, node configuration, and cluster monitoring.6 It is critical that the talosctl version is aligned with the Talos OS version intended for deployment to avoid gRPC protocol incompatibilities.13

Bash

# Esempio di installazione su macOS tramite Homebrew
brew install siderolabs/tap/talosctl

Once the Talos ISO image is downloaded (preferably customized via the Image Factory to include necessary drivers), it must be uploaded to the Proxmox ISO storage.6 Upon the first VM boot, the console will show a temporary IP address obtained via DHCP. This IP is the entry point for sending the initial configuration.6

Configuration File Generation and Secret Management

#

Talos security is based on a set of locally generated secrets. These secrets are never transmitted in clear text and form the basis for mTLS certificate signing.14 Configuration generation requires defining the Kubernetes API endpoint, which usually coincides with the IP of the first master node or a managed virtual IP.6

Bash

# Generazione dei segreti del cluster
talosctl gen secrets -o secrets.yaml

# Generazione dei file di configurazione per nodi master e worker
talosctl gen config my-homelab-cluster https://192.168.1.50:6443 \
–with-secrets secrets.yaml \
–output-dir _out

This operation generates three main components:

• controlplane.yaml: Contains definitions for nodes that will manage etcd and the API server.
• worker.yaml: Contains configuration for nodes that will run workloads.
• talosconfig: The client file allowing the administrator to authenticate with the cluster.6

Configuration Application and etcd Bootstrap

#

Applying the configuration transforms the node from maintenance mode to an installed and functional operating system. It is essential to verify the target disk name (e.g., /dev/sda or /dev/vda) before sending the YAML file.8 Initial sending occurs in “insecure” mode since mTLS certificates have not yet been distributed to the node.6

Bash

talosctl apply-config –insecure –nodes 192.168.1.10 –file _out/controlplane.yaml

After reboot, the first control plane node must be instructed to initialize the Kubernetes cluster via the bootstrap command. This operation configures the etcd distributed database and starts the core control plane components.6 Only after this phase does the cluster become self-aware and the Kubernetes API endpoint becomes reachable.

Networking: Optimization and High Availability

#

Networking is the area where Talos expresses its maximum flexibility, allowing the administrator to choose between standard configurations and advanced eBPF-based solutions.17

Choosing Between Flannel and Cilium

#

By default, Talos uses Flannel as the network interface (CNI), a simple solution providing pod-to-pod connectivity via a VXLAN overlay.17 However, Flannel lacks support for Network Policies and does not offer advanced observability features. For a production-oriented homelab, Cilium represents the gold standard.17 Thanks to intensive use of eBPF, Cilium can entirely replace the kube-proxy component, drastically improving routing performance and reducing CPU load by eliminating the thousands of iptables rules typical of traditional Kubernetes clusters.19

Implementing Cilium requires explicitly disabling the default CNI and kube-proxy in the Talos configuration.16 This is done via a YAML patch applied during generation or configuration modification:

YAML

cluster:
network:
cni:
name: none
proxy:
disabled: true

Removing kube-proxy is not without challenges. Cilium must be configured to manage services via eBPF host routing. A critical detail often overlooked is the need to set bpf.hostLegacyRouting=true if DNS resolution or pod-to-host connectivity issues are encountered in particular kernel versions.21

High Availability with kube-vip

#

In a cluster with multiple control plane nodes, it is essential that the API server is reachable through a single stable IP address, even if one master node fails. Talos offers an integrated Virtual IP (VIP) feature operating at layer 2 (ARP) or layer 3 (BGP).14 This function is based on leader election managed directly by etcd.22

A widely used alternative is kube-vip, which can operate both as a VIP for the control plane and as a Load Balancer for Kubernetes services of type LoadBalancer.23 Kube-vip in ARP mode elects a leader among nodes hosting the virtual IP. To avoid bottlenecks, “leader election per service” can be enabled, allowing different cluster nodes to host different service IPs, thus distributing the network load.24

Using the native Talos VIP is recommended for its simplicity in ensuring API server access, while kube-vip is the ideal choice for exposing internal services (like an Ingress Controller) with static IPs from your local network.23

Proxmox Optimizations and Advanced Customizations

#

To ensure Talos behaves as a first-class citizen within Proxmox, certain optimizations must be implemented to bridge the gap between the hypervisor and the minimal operating system.

QEMU Guest Agent and System Extensions

#

The QEMU Guest Agent is a fundamental helper allowing Proxmox to manage clean shutdowns and read network information directly from the VM.4 Since Talos has no package manager, it cannot be installed with an apt install command. The solution lies in Talos’s “System Extensions”.4 Using the (https://factory.talos.dev), a custom ISO or installer can be generated including the siderolabs/qemu-guest-agent extension.4

Once the extension is included, the service must be enabled in the machine configuration file:

YAML

machine:
features:
qemuGuestAgent:
enabled: true

This approach ensures the agent is an integral part of the immutable system image, maintaining consistency between nodes and facilitating maintenance operations from the Proxmox web interface.4

Persistence with iSCSI and Longhorn

#

In many homelabs, storage is not local but resides on a NAS or SAN. To use distributed storage solutions like Longhorn or to mount volumes via iSCSI, Talos requires the corresponding system binaries. Again, extensions play a crucial role. Adding siderolabs/iscsi-tools and siderolabs/util-linux-tools provides necessary kernel drivers and user-space utilities to manage iSCSI targets.4

It is also necessary to configure the kubelet to allow mounting specific directories like /var/lib/longhorn with correct permissions (rshared, rw). This ensures that containers managing storage have direct access to hardware or network volumes without interference from operating system isolation mechanisms.9

Lifecycle: Atomic Updates and Maintenance

#

Maintaining a Talos cluster differs radically from traditional systems. Updates are atomic and image-based, reducing the risk of leaving the system in an inconsistent intermediate state to near zero.2

Update and Rollback Strategies

#

Talos implements an A-B update system. When an upgrade command is sent, the system downloads the new image to an inactive partition, updates the bootloader, and reboots.26 If booting the new version fails (e.g., due to a configuration incompatible with the new kernel), Talos automatically rolls back to the previous version.26 This mechanism, borrowed from smartphone operating systems (like Android), ensures extremely high availability.

Recommended procedures involve updating one node at a time, starting with worker nodes and finally proceeding to control plane nodes.13 During the update, Talos automatically performs “cordon” (prevents new pods) and “drain” (moves existing pods) of the node in Kubernetes, ensuring workloads do not suffer abrupt interruptions.26

Monitoring with the Integrated Dashboard

#

For immediate diagnostics, Talos provides an integrated dashboard accessible via talosctl. This tool provides an overview of core service health, resource usage, and system logs, eliminating the need to install heavy external monitoring agents during initial troubleshooting phases.8

Bash

# Avvio della dashboard per un nodo specifico
talosctl dashboard –nodes 192.168.1.10

This dashboard is particularly useful during the bootstrap phase to identify why a node fails to join the cluster or why etcd does not reach quorum.8

Final Considerations and Future Perspectives

#

Adopting Talos OS on Proxmox VE represents a choice of excellence for anyone wanting to build a robust and modern Kubernetes infrastructure. The combination of declarative management, immutability, and the absence of legacy components like SSH raises the standard of security and stability far beyond what is possible with general-purpose Linux distributions.1

Initial challenges related to learning a new paradigm are amply compensated by the ease of managing system updates and the predictability of cluster behavior. In an ecosystem where Kubernetes complexity can often become overwhelming, Talos offers an “opinionated” approach that reduces variables, allowing administrators to focus on applications rather than the operating system. The integration with Proxmox, supported by VirtIO and System Extensions, provides the perfect balance between the power of virtualization and the agility of Cloud Native, making this configuration a benchmark for professional homelabs and edge infrastructures.

Bibliography

#

1. siderolabs/talos: Talos Linux is a modern Linux distribution built for Kubernetes. - GitHub, accessed on December 29, 2025, https://github.com/siderolabs/talos
2. Introduction to Talos, the Kubernetes OS | Yet another enthusiast blog!, accessed on December 29, 2025, https://blog.yadutaf.fr/2024/03/14/introduction-to-talos-kubernetes-os/
3. Sidero Documentation - What is Talos Linux?, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.7/overview/what-is-talos
4. Customizing Talos with Extensions - A cup of coffee, accessed on December 29, 2025, https://a-cup-of.coffee/blog/talos-ext/
5. Architecture - Sidero Documentation - What is Talos Linux?, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.9/learn-more/architecture
6. Talos with Kubernetes on Proxmox | Secsys, accessed on December 29, 2025, https://secsys.pages.dev/posts/talos/
7. Using Talos Linux and Kubernetes bootstrap on OpenStack - Safespring, accessed on December 29, 2025, https://www.safespring.com/blogg/2025/2025-03-talos-linux-on-openstack/
8. Proxmox - Sidero Documentation - What is Talos Linux?, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.9/platform-specific-installations/virtualized-platforms/proxmox
9. Creating a Kubernetes Cluster With Talos Linux on Tailscale | Josh …, accessed on December 29, 2025, https://joshrnoll.com/creating-a-kubernetes-cluster-with-talos-linux-on-tailscale/
10. Talos on Proxmox, accessed on December 29, 2025, https://homelab.casaursus.net/talos-on-proxmox-3/
11. Talos ProxMox - k8s development - GitLab, accessed on December 29, 2025, https://gitlab.com/k8s_development/talos-proxmox
12. Getting Started - Sidero Documentation - What is Talos Linux?, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.9/getting-started/getting-started
13. Upgrade Talos Linux and Kubernetes | Eric Daly’s Blog, accessed on December 29, 2025, https://blog.dalydays.com/post/kubernetes-talos-upgrades/
14. Production Clusters - Sidero Documentation - What is Talos Linux?, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.7/getting-started/prodnotes
15. How to Deploy a Kubernetes Cluster on Talos Linux - HOSTKEY, accessed on December 29, 2025, https://hostkey.com/blog/102-setting-up-a-k8s-cluster-on-talos-linux/
16. “ServiceLB” with cilium on Talos Linux | by Stefan Le Breton | Dev Genius, accessed on December 29, 2025, https://blog.devgenius.io/servicelb-with-cilium-on-talos-linux-8a290d524cb7
17. Kubernetes & Talos - Reddit, accessed on December 29, 2025, https://www.reddit.com/r/kubernetes/comments/1hs6bui/kubernetes_talos/
18. Installing Cilium and Multus on Talos OS for Advanced Kubernetes Networking, accessed on December 29, 2025, https://www.itguyjournals.com/installing-cilium-and-multus-on-talos-os-for-advanced-kubernetes-networking/
19. Deploy Cilium CNI - Sidero Documentation, accessed on December 29, 2025, https://docs.siderolabs.com/kubernetes-guides/cni/deploying-cilium
20. Install in eBPF mode - Calico Documentation - Tigera.io, accessed on December 29, 2025, https://docs.tigera.io/calico/latest/operations/ebpf/install
21. Validating Talos Linux Install and Maintenance Operations - Safespring, accessed on December 29, 2025, https://www.safespring.com/blogg/2025/2025-04-validating-talos-linux-install/
22. Virtual (shared) IP - Sidero Documentation - What is Talos Linux?, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.8/networking/vip
23. kube-vip: Documentation, accessed on December 29, 2025, https://kube-vip.io/
24. Kubernetes Load-Balancer service | kube-vip, accessed on December 29, 2025, https://kube-vip.io/docs/usage/kubernetes-services/
25. Qemu-guest-agent - Proxmox VE, accessed on December 29, 2025, https://pve.proxmox.com/wiki/Qemu-guest-agent
26. Upgrading Talos Linux - Sidero Documentation, accessed on December 29, 2025, https://docs.siderolabs.com/talos/v1.8/configure-your-talos-cluster/lifecycle-management/upgrading-talos
27. omni-docs/tutorials/upgrading-clusters.md at main - GitHub, accessed on December 29, 2025, https://github.com/siderolabs/omni-docs/blob/main/tutorials/upgrading-clusters.md
28. Talos OS - Documentation & FAQ - HOSTKEY, accessed on December 29, 2025, https://hostkey.com/documentation/marketplace/kubernetes/talos/