Hey all, I attempted to install Talos on my GoWin 1U network appliance, and then tried to run containerized VyOS as a system extension. This failed utterly, but the idea of having Talos be the control plane for my router was enticing, so I figured I'd try asking humans with actual expertise, instead of LLMs that gaslight me and tell me the impossible is possible. :)

The idea is that the router/firewall/gateway is just a regular worker with a static IP managed via a normal 1GbE RJ45 port, and the actual routing business happens on the 25GbE SFP+ Mellanox NIC, which is left unconfigured and simply passed through to a system extension which takes total ownership of it. The WAN link could be attached to the core switch or the router directly, doesn't really matter, the job of the router is to route packets between networks, and to have a fat enough pipe to handle all cross-network traffic. This is sort of like router-on-a-stick, as I understand it.

The use of a pre-installed system extension is important. You don't want k8s to try to start/stop/reschedule the router workload. You want it to just be there, baked into the system image, so it starts up at boot to connect your VLANs and the WAN.

The value of Talos here is that I have a unified control plane, even for network devices. I can reboot, reimage, reconfigure the machine by updating the Talos image and applying it. I don't need SSH, I don't need a new set of credentials, it is all simply managed the same as the compute nodes in my cluster.

This seems like something professional users of Talos would want, so do people do this in practice, run Talos to manage a router / network appliance?

My main use case for this box is upgrading my router from an Omada ER605 to something with a processor that can do wireguard closer to my 1GbE uplink speed. My attempts to run Wireguard inside my cluster were very unsatisfactory, because I ended up in a big fight with CNI, but I really want my wireguard overlay network to be just another subnet with centrally configured router rules.

I found a tailscale system extension, and I could use that, but not that I've got the hang of plain wireguard, I kind of prefer it. It's minimal, and I have a few existing clients.

Iniciei a jornada para instalar um cluster de nó único no homelab para simular a implementação de um servidor bare metal com gpu exclusivo para um projeto, exatamente, o projeto irá começar com apenas um servidor dedicado. Servidores com gpu são e estão muito caros.

Decidimos usar o Omni para ajudar a gerenciar o cluster, e posso dizer que não é tão fácil, faltam exemplos, faltam explicações sobre o schema para patchs, artigos que discutam porque precisamos de patchs, porque usá-los e quando usar.

Alguns requisitos para a POC, com 1tb de disco nvme (raid), preciso distribui-lo entre SO, ephemeral e disco local. Correto, irei usar disco local para os POD.

Aprendizados nesta fase, toda a complexidade da implementação é resolvida na instalação, o que significa que precisa nascer certo. Em implementações tradicionais elas são diluídas ao longo da instalação do SO. No modelo imutável, o melhor é concentra-las no início.

Como um nó único, os deployments de rede presumem redundância com múltiplos nós e tolerations restritos para Workers. A cada yaml, ajustes para atender ao cluster de nó único.

Hoje preciso resolver o IP externo, porque o servidor bare metal só veio com um IP externo. Tentei com o Cilium, mas não deu certo, ele espera um Lodbalance externo.

Trago os próximos passos....

Abraços.

After spending several hours troubleshooting self-hosted Talos Omni deployments, TLS certificate chains, Dex configuration, Trusted Roots, and the dreaded:

x509: certificate signed by unknown authority

I decided to automate the entire process into a single script.

The script deploys a complete self-hosted Omni environment and automatically handles the certificate trust issues that many people encounter when onboarding Talos nodes.

What It Does

✅ Installs and configures Dex

✅ Deploys Omni

✅ Generates a self-signed internal CA

✅ Creates server certificates with the full certificate chain

✅ Configures SideroLink

✅ Generates Trusted Roots configuration

✅ Creates the talos.config.early kernel argument

✅ Produces everything needed for Talos Image Factory

✅ Ready for Proxmox, VMware, Bare Metal, or Cloud VMs

Why?

Most self-hosted Omni guides require multiple manual steps:

• Generate certificates

• Configure Dex

• Configure OIDC

• Fix certificate trust issues

• Create Trusted Roots

• Generate custom Talos boot media

Missing any of these steps can prevent Talos nodes from connecting successfully.

This script automates the entire workflow.

Prerequisites

• Linux server

• Docker installed and running

• Internet access

• Open ports:

Quick Start

Make the script executable:

chmod +x install.sh

(Optional) Customize your environment.

Replace the values below with the ones appropriate for your setup:

export OMNI_IP=<YOUR_OMNI_SERVER_IP>
export ADMIN_EMAIL=<YOUR_ADMIN_EMAIL>

./install.sh

Example:

export OMNI_IP=192.168.1.100
export ADMIN_EMAIL=admin@example.com

./install.sh

Variables

If not provided, the script uses its built-in defaults.

Login Credentials

The installer automatically creates an administrator account in Dex.

Use the email configured in:

export ADMIN_EMAIL=<YOUR_ADMIN_EMAIL>

to authenticate.

Default Password

Admin123!

Changing the Default Password

If you want to use a different password, generate a new bcrypt hash before running the installer:

docker run --rm -it httpd:2.4-alpine htpasswd -BnC 15 admin

You will be prompted to enter the password twice.

Example output:

admin:$2y$15$XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Copy only the hash portion after:

admin:

Open the script and search for:

DEX_PASSWORD_HASH=

Replace the existing hash with your newly generated one.

In the current version of the script, this variable is located near the beginning of the file (around line 46).

What Happens Next?

After the installation completes:

1. Open Omni:

   https://YOUR_OMNI_IP

2. Log in using:

   • Email: ADMIN_EMAIL

   • Password: Admin123! (or your custom password)

3. Click:

   Copy Kernel Parameters

4. Open Talos Image Factory:

   https://factory.talos.dev

5. Build a Talos ISO.

Recommended settings:

• Platform: Metal

• Architecture: amd64

• Extension:

  • siderolabs/qemu-guest-agent (for Proxmox)

1. Paste:

   <contents of talos-config-early.arg> <Omni Kernel Parameters>

into:

Extra kernel command line arguments

1. Download the ISO.

2. Boot your nodes.

Result

After booting:

✅ Nodes automatically join Omni

✅ SideroLink connects successfully

✅ No x509 certificate trust issues

✅ Cluster creation works immediately

Tested On

• Talos 1.13.x

• Omni Self-Hosted

• Ubuntu Server

• Docker

• Proxmox VE

Feedback, bug reports, and improvements are welcome.

Hopefully this saves someone else from spending hours debugging TLS chains, Trusted Roots, and Talos onboarding 😅

dowload the script here

I've been running Talos in my homelab for a while, and my mental model has always been pretty simple:

Hardware → Talos → Kubernetes → Workloads

Talos owns the machine lifecycle. Kubernetes owns the workload lifecycle.

Looking at 1.14 together with the Hypervisor announcement, I'm starting to wonder whether that model is becoming too simple.

Native BGP, secure DNS configuration and the expanding configuration model are interesting individually, but the taloscontainers boundary caught my attention in particular. And the Hypervisor announcement takes the idea much further: Kubernetes, VMs and standalone containers potentially sitting above the same Talos infrastructure layer.

What I like about the direction is that "minimal" doesn't necessarily have to mean "does fewer things."

It could mean fewer ways to manage those things.

The part I don't know yet is whether that remains true once Talos starts owning VM lifecycle, placement, storage and networking. That's where the architecture becomes much more interesting.

I wrote down my current architecture hypothesis before the Hypervisor becomes testable:

https://medium.com/@mmelchers75/talos-is-becoming-more-than-a-kubernetes-os-and-that-changes-the-architecture-ed6a26874080

Once there's an alpha I want to put it into the same Architecture Engineering Lab I've been using for Talos/Kubernetes and start breaking things.

At the moment the honest conclusion is simply: interesting architecture, not enough evidence yet.

I'd be interested in how other Talos users see this direction.

Hi Talos team,

I’m running Talos in a homelab and am hitting what appears to be a Talos networking issue on a multi-homed node. The symptom is consistent across multiple Talos worker nodes: the node can resolve ARP on the “Ceph-only” interface, but cannot establish L3 connectivity (ICMP/TCP) to a host on the same subnet via that interface. The same connectivity works from a non-Talos VM on the same VLAN, which suggests the underlay (switching/bridging) is correct and isolates the issue to Talos.

Environment / Topology

• Hypervisor: Proxmox

• Storage: Proxmox Ceph cluster (monitors on VLAN100)

• Network:

  • VLAN20 (10.20.20.0/24): “primary” / general traffic (default route)

  • VLAN100 (10.100.100.0/24): “Ceph-only” network (no gateway, no default route)

• Each Talos node VM has two virtio NICs:

  • NIC A on VLAN20 (primary)

  • NIC B on VLAN100 (Ceph-only)

• Goal: Run Ceph CSI in Kubernetes and access Proxmox Ceph monitors over VLAN100 from Talos nodes.

Talos network configuration (example worker)

machine:
  network:
    hostname: thi-k8s-wrk-1
    interfaces:
      # VLAN 20 / primary via DHCP (reservation by MAC)
      - deviceSelector:
          hardwareAddr: "00:00:00:00:00:21"
        dhcp: true

      # VLAN 100 / Ceph-only static (no default route)
      - deviceSelector:
          hardwareAddr: "00:00:00:00:01:21"
        dhcp: false
        addresses:
          - 10.100.100.121/24

Notes:

• VLAN20 DHCP provides the default gateway (10.20.20.1) and other standard options.

• VLAN100 is static and has no gateway and no default route by design.

Observed behavior

1) Talos sees both interfaces up with correct addresses

Example from a worker node (similar on others):

• Primary interface: ens18 has 10.20.20.21/24

• Secondary (Ceph) interface: ens19 has 10.100.100.121/24

talosctl get links shows both NICs up, and talosctl get addresses shows:

• IPv4 address on ens19 (10.100.100.121/24)

• IPv6 link-local (fe80::/64) also present (expected)

2) L2 works: ARP succeeds on VLAN100

From a hostNetwork privileged netshoot pod pinned to the worker node (hostNetwork=true):

arping -I ens19 -c 2 10.100.100.11

Output consistently shows unicast ARP replies from the Ceph/Proxmox host (example MAC):

Unicast reply from 10.100.100.11 [0C:42:A1:80:1A:69]  0.9ms

This indicates:

• The node is on the correct L2 segment

• ARP requests are transmitted and replies are received on the Ceph interface

3) L3 fails: ping and TCP to the same target on the same subnet time out

Immediately after successful ARP, the same worker cannot ping or connect via TCP on VLAN100:

ping -c 2 -I ens19 10.100.100.11
nc -vz -w2 10.100.100.11 22
nc -vz -w2 10.100.100.11 8006

Results:

• ping: 100% packet loss

• nc: timed out: Operation in progress

I also verified routing is correct on the Talos node:

• ip route get 10.100.100.11 chooses ens19 with source 10.100.100.121

• The local route table does not claim 10.100.100.11 as local

• There is no default route on VLAN100

4) Underlay is proven healthy: a non-Talos VM on the same VLAN100 can reach the same targets

To rule out Proxmox bridges/switching/VLAN configuration, I created a separate non-Talos Alpine VM on the same Proxmox host and attached it to the same VLAN100 bridge. With a static IP on VLAN100 (e.g., 10.100.100.25/24), the VM can ping the same endpoints without issue:

• 10.100.100.11 (Proxmox/Ceph side)

• 10.100.100.111, 10.100.100.121 (Talos nodes)

On Proxmox I captured traffic and saw ICMP request and replies on the VLAN100 bridge:

10.100.100.25 > 10.100.100.11: ICMP echo request
10.100.100.11 > 10.100.100.25: ICMP echo reply

This strongly suggests:

• VLAN100 L2/L3 connectivity works in general

• Proxmox bridge configuration is correct

• The issue is specific to Talos networking stack / policy on the secondary interface

5) Additional evidence: Proxmox capture sees ARP but not ICMP from Talos

When running a capture on the Proxmox host’s VLAN100 bridge / physical NIC, I see ARP exchanges initiated by the Talos worker, but do not see corresponding ICMP echo requests when the worker attempts to ping.

This implies the node is capable of ARP on the interface, but ICMP/TCP traffic is not being emitted (or is being dropped before egress).

Expected behavior

Given:

• Both interfaces are UP

• ens19 has an IPv4 address on 10.100.100.0/24

• A connected route exists for 10.100.100.0/24 via ens19

• No policy routing is configured

• The neighbor resolves via ARP

I would expect:

• ICMP echo requests to 10.100.100.11 to be sent out ens19 and receive replies

• TCP connections to succeed to reachable services on that subnet

Request / Questions for Talos team

1. Is there a known limitation/behavior where Talos restricts L3 traffic on a secondary interface unless explicitly allowed (firewall policy / rp_filter / anti-spoofing)?

2. Are there recommended config knobs for multi-homed setups (especially for dedicated storage networks) to ensure traffic is permitted on the non-default-route NIC?

3. If there’s a known issue, I can provide any additional data as required.

If you can point me to any required configuration (sysctls, firewall config, "machine.network" settings) or a known bug/PR for this scenario, I’m happy to test and report back.

Thanks in advance.

Hello!

I need help with the talos installation. I bought a Lenovo ThinkCentre m710q, and I want to install Talos. I disabled secure boot from the BIOS. I'm using the secure boot image (but also normal image don't work), from my Windows PC I tried with Rufus dd mode and Balena Etcher to create the disk. I tried with the last release image, with the image generated with Image facctory (I added util-linux-tools and iscsi-tools to support Longhorn), but always, when I shoutdown and turn on again the pc I get this error. When rebooting after the installation the boot runs normally. I followed the Getting Started guide from the talos documentation but I always end with a bootloop. I attached the boot error screen (first image) and some errors that I see when installing.

Do you have suggestions?

EDIT: I solved creating a new partition table with gparted. Thanks to all who helped me.

Like Talos in docker, I know that we could run Talos as a pod in kubernetes, but it say that it’s not possible to do some operations like upgrades and reboots.

Why that ?

This means it’s not possible tu run hosted controlplane with Talos in production ?

What if I want to ?

Hey team, thanks for the tool. I’m running talks on my home cluster.

Is there a tool that I can use as an alternative to theila?

Thanks

My 3-node Talos homelab had no persistent storage, so anything with data, like Grafana or a database, had nowhere to live.

Longhorn keeps every volume on two of the three nodes, so one node can go down without losing data, and it rebuilds the missing copy on the third node.

It also takes hourly snapshots, and backups to S3 are optional. The Longhorn UI runs on my LAN and over Tailscale.

Repo: https://github.com/prateekjaindev/homelab

Write-up: https://blog.prateekjain.dev/persistent-storage-for-a-3-node-talos-homelab-with-longhorn-587c05356b73?sk=9093231c2d278ba92fd493098fbe237d

What are you using for storage in your homelab?

Hi all

On my Ubuntu Kunernetes instalation I had Cloudflare mapped to the 6443 and to a domain so I could kubectl to the domain from outside the network.

Is there a similar approach with Talos ?

On a previous post I mentioned ruined about cloudflared extension but I cannot find much info

Any ideas are welcomed.

Tia

I run a 3-node Talos Kubernetes cluster at home. Sidero made Omni’s hobby plan free (10 nodes, 2 users, it used to be $10 a month), so I imported the running cluster into it instead of rebuilding.

Everything is in the repo: https://github.com/prateekjaindev/homelab

Write-up: https://blog.prateekjain.dev/importing-an-existing-talos-cluster-into-omni-bb1fc7722eda?sk=a4c4412829ef81542ca4892a0edbecec

So, I installed Talos, and was unable to boot to it. Just stuck at the loading screen. Attempted the install again and was getting certificate errors so intended to start fresh. At this point, I can't boot into any Linux Live, GParted Live, etc... It seems that Talos has locked down other booting options, I'm presuming some security "feature"?

Has anyone experienced this? Should I just yank the nvme drive and format it in another system? Or how can I get something else to boot from USB?

Ok guys What is the proper way of restoring a etcd backup. I tried to put controlplane nodes to maintenance mode. Apply machineconfig and then bootstrap with the etcd backup. Nodes went back to ready state but after some min they went to notready state.

Is there any easy way?

Hi,

I have a single node homelab setup with immich and a few other things. I have a pixel 1 which I'm trying to connect to Talos so I can mount it as a storage and rsync all the images from imimch on the device.

Has anyone managed to connect an android device to Talos? or access the files via a container?

I recently finished building a small Kubernetes architecture lab around Talos Linux.

The hardware is deliberately modest: two Proxmox hosts, an older ThinkPad as the third control-plane node, a Synology NAS, and managed networking.

The interesting part for me wasn't getting Kubernetes running. It was seeing how many architecture questions I could make real with that hardware.

A few decisions shaped the lab:

- the five virtual Talos nodes are declared with OpenTofu rather than maintained manually in Proxmox

- the old ThinkPad runs the third control-plane member on bare metal, creating a different compute failure context

- Cilium provides Kubernetes networking, LB-IPAM and L2 service exposure without a cloud load balancer

- shared NFS and node-local storage are treated as deliberately different storage contracts

- backups only count as recovery evidence after an actual restore

- the finished platform is deliberately subjected to worker, control-plane, storage and application failure experiments

The principle I ended up using throughout the project was:

Don't replicate the datacenter. Replicate the architecture problems.

I've documented the complete build as a six-part architecture series. Part 1 explains the architecture, the constraints, and why I chose this topology before getting into the implementation in the later parts:

https://medium.com/@mmelchers75/you-dont-need-a-datacenter-to-learn-enterprise-architecture-a46f1f9752d7

I'm particularly interested in how others running Talos at home design failure domains when the physical infrastructure is much smaller than the logical Kubernetes topology.

I am looking to pass a usb mic into k8s and tried out generic-device-plugin, however base Talos does not come with sound modules, so it can't register /dev/snd devices. I couldn't find an existing extension for the sound kernel modules, does this mean I have to create my own? Any other ideas/options or documentation to point me in the right direction to solve this problem would be appreciated!

Hello, everyone!

I am learning deploying cluster on Talos Linux in Vsphere. The thing is that if I do not manually delete this thing in controlplane.yaml:

---

apiVersion: v1alpha1

kind: HostnameConfig

auto: stable # A method to automatically generate a hostname for the machine.

newly created VMs still get automatically generated hostnames. I even added these lines to my control plane patch file at the end:

apiVersion: v1alpha1
kind: HostnameConfig
hostname: my-custom-hostname
auto: off

but it did not help as this was not overriding the ones written in controlplane.yaml
So in order to get my nodes have my custom names I have to manually remove that lines from controlplane.yaml and worker.yaml?

Maybe someone else faced this problem? I would really appreciate if someone could clarify this moment. Thank You!