I’d like to propose adding support for Talos Linux in the Kubernetes SIGs Image Builder project.
Talos (https://www.talos.dev/) is a secure, minimal, API-driven operating system purpose-built for Kubernetes. It is increasingly adopted in both homelab and production environments due to its immutability, reduced attack surface, and tight integration with Kubernetes lifecycle management.
Motivation
Image Builder currently supports several OS distributions (Ubuntu, CentOS, etc.) to produce Kubernetes node images across various platforms. However, Talos follows a different paradigm:
No SSH access; fully API-managed
Immutable, minimal OS designed specifically for Kubernetes
Native support for declarative machine configuration
Built-in support for modern infrastructure platforms (bare metal, vSphere, OpenStack, cloud providers)
Adding Talos support would:
Broaden Image Builder’s ecosystem to include immutable OS approaches
Enable Cluster API providers to consume Talos images in a more standardized way
Reduce the need for external image pipelines when using Talos with Cluster API
Align with ongoing trends toward minimal and secure node operating systems
Proposal
There are a few possible integration approaches:
Add a Talos "provider" or "OS flavor" in Image Builder, leveraging Talos image factory or APIs
Integrate Talos image generation workflows (e.g., via talosctl or image factory endpoints)
Provide reference templates or pipelines for producing Talos-compatible images per platform
Considerations
Talos does not use traditional provisioning mechanisms (cloud-init, SSH), so some Image Builder assumptions may not apply
Image customization is handled via machine configuration rather than image baking
Integration may focus more on image retrieval/packaging than full build pipelines
Questions
Would maintainers be open to supporting a non-traditional OS like Talos in Image Builder?
Is there an existing design direction for supporting immutable or API-driven OSes?
Would this be better handled as an external plugin or maintained outside the core repository?
I’d be happy to contribute or help prototype an implementation if there is interest.
Thanks for your time and feedback!
I’d like to propose adding support for Talos Linux in the Kubernetes SIGs Image Builder project.
Talos (https://www.talos.dev/) is a secure, minimal, API-driven operating system purpose-built for Kubernetes. It is increasingly adopted in both homelab and production environments due to its immutability, reduced attack surface, and tight integration with Kubernetes lifecycle management.
Motivation
Image Builder currently supports several OS distributions (Ubuntu, CentOS, etc.) to produce Kubernetes node images across various platforms. However, Talos follows a different paradigm:
No SSH access; fully API-managed
Immutable, minimal OS designed specifically for Kubernetes
Native support for declarative machine configuration
Built-in support for modern infrastructure platforms (bare metal, vSphere, OpenStack, cloud providers)
Adding Talos support would:
Broaden Image Builder’s ecosystem to include immutable OS approaches
Enable Cluster API providers to consume Talos images in a more standardized way
Reduce the need for external image pipelines when using Talos with Cluster API
Align with ongoing trends toward minimal and secure node operating systems
Proposal
There are a few possible integration approaches:
Add a Talos "provider" or "OS flavor" in Image Builder, leveraging Talos image factory or APIs
Integrate Talos image generation workflows (e.g., via talosctl or image factory endpoints)
Provide reference templates or pipelines for producing Talos-compatible images per platform
Considerations
Talos does not use traditional provisioning mechanisms (cloud-init, SSH), so some Image Builder assumptions may not apply
Image customization is handled via machine configuration rather than image baking
Integration may focus more on image retrieval/packaging than full build pipelines
Questions
Would maintainers be open to supporting a non-traditional OS like Talos in Image Builder?
Is there an existing design direction for supporting immutable or API-driven OSes?
Would this be better handled as an external plugin or maintained outside the core repository?
I’d be happy to contribute or help prototype an implementation if there is interest.
Thanks for your time and feedback!