News
From customer request to open source:
Why we built the missing link for Talos on OpenNebula
“Can we run Kubernetes on OpenNebula using Talos Linux?
Over the past few months, we’ve heard this question repeatedly from organizations moving to open-source virtualization, often driven by concerns over licensing costs or geopolitical dependencies. The short answer was always yes. We use this exact combination for our own managed services, so OpenNebula handles the virtual machines Talos requires without an issue. However, getting a system to run is fundamentally different from giving an end user an easy way to deploy and manage a cluster. That’s why we built the missing piece: talos-opennebula, an open-source integration that lets you deploy Talos Kubernetes clusters as native OpenNebula OneFlow services.
Why Talos on OpenNebula?
If you want to start with Kubernetes on OpenNebula, there’s an obvious starting point: OneKS. This is OpenNebula’s built-in Kubernetes solution based on ClusterAPI, CAPONE, and RKE2. If you want Kubernetes delivered as an integrated OpenNebula service, that's where you look first
Our situation was slightly different. We were talking to organizations that had already chosen Talos and wanted to keep that exact workflow on OpenNebula.
Talos approaches the OS under Kubernetes differently. It’s minimalist, immutable, operates without SSH or a shell, and is managed entirely via an API. For teams selecting Talos, preventing configuration drift and keeping nodes predictable are essential design requirements.
We wanted to preserve that lightweight approach on OpenNebula. Instead of wrapping it in a brand-new automation stack, we decided to see how far we could get using OpenNebula’s native building blocks. As it turned out, pretty far.
Strategic value of this approach
True control over your infrastructure: Building on open standards like OpenNebula and Talos keeps you independent from sudden licensing shifts or mandatory price hikes from proprietary vendors.
Less complexity, lower risk: Talos is immutable and has no interactive SSH login. Because servers can't be modified manually, updates are handled by replacing nodes automatically. This significantly reduces human error and downtime.
Long-term flexibility: A modular, open-source foundation keeps your IT landscape adaptable. You avoid lock-in and stay free to adjust your setup as your organization evolves.
No extra layers
We kept the architecture intentionally lean. OneFlow handles the multi-VM service lifecycle, while OneGate manages node discovery and state exchange. A gateway exposes the Kubernetes API, and a lightweight orchestrator handles the initial cluster bootstrap configuration for Talos.
The control plane and worker nodes remain plain Talos nodes. There is no OpenNebula agent installed, no SSH configuration, and no external automation stack wrapped around it. The base setup doesn't require Terraform, Ansible, Vault, GitOps tooling, or external DNS automation.Once installed, it appears as a standard service template in OpenNebula. An operator can launch a Talos cluster directly
from the Sunstone GUI, just like any other service. In our lab environment, creating or destroying a cluster takes around four minutes. While that's a lab metric, it makes the implementation very practical for testing, development, and evaluation.
Built for real-world use cases
The demand for a simple way to run Talos clusters on OpenNebula came from organizations exploring sovereign infrastructure and immutable Kubernetes. This project complements the OpenNebula ecosystem rather than replacing OneKS.
It comes down to architectural preference: You choose OneKS when you want Kubernetes delivered as a fully managed OpenNebula service. You look at talos-opennebula when Talos itself is an explicit requirement in your platform architecture.
We deliberately built this implementation outside our internal production infrastructure. Our managed environments rely on internal tooling and automation that wouldn't exist in a standard OpenNebula setup. By building talos-opennebula in test environments and on our TrueFullstaq Homelabs, we ensured the architecture remains easy to understand, free of hidden dependencies, and aligned with standard OpenNebula practices.
Before publishing the code, we shared the implementation with OpenNebula Engineering and incorporated their feedback.
A foundation to build on
We are releasing this project as a proof of concept and reference implementation. The current version uses a single gateway for the Kubernetes API. Other topologies are planned in the design but aren't fully wired up yet, leaving clear room for community additions. That is an intentional choice. We prefer delivering a lean, understandable architecture over hiding complexity behind heavy abstractions.
For OpenNebula administrators, this offers a practical way to test Talos. For teams standardizing on Talos, it provides a clear starting point on OpenNebula. And for us, it gives a solid foundation to iterate on alongside the organizations that asked for it.
The full codebase, documentation, architectural decision records, and instructions are available in the TrueFullstaq/talos-opennebula GitHub repository under the Apache 2.0 license. Feel free to use, test, and adapt the code. If you plan to run Talos on OpenNebula in production, we’d love to hear your feedback.
