This post was initially published here by Nils Fuerste and is reposted here with permission.
This post starts a series on deploying and operating a RAN on top of a telco cloud. The focus is on a practical setup using Sylva and OCUDU, following the process from initial deployment to running a complete network.
Why this series
Over the last months, I have had the chance to work with different telco cloud implementations and started looking more closely at how these platforms actually behave in practice.
In this series, I focus on deploying OCUDU on Sylva and understanding how it fits into a telco cloud setup. The goal is to understand how a RAN workload integrates into a cloud-native infrastructure that is closer to what operators actually use.
OCUDU supports O1 and integrates naturally into the management plane, which makes it a good fit for this kind of environment. At the same time, these setups are very different from the ones I explored before. The main shift is that infrastructure and network management are no longer separate concerns.
Instead of only running components on Kubernetes, infrastructure provisioning, RAN configuration, and lifecycle management become part of the same system.
In previous posts, I focused on running RAN components directly on Kubernetes and understanding what is required to make them work reliably. In this series, I want to move one step further and explore how more structured, production-oriented environments are built and operated.
What this series is about
This series focuses on Sylva and shows how to deploy and operate a small network on top of it.
It is not an introduction to Kubernetes or RAN concepts from scratch. Instead, it builds on an existing setup and moves it into a telco cloud model where infrastructure, lifecycle management, and workloads are all defined declaratively.
Since I do not have access to large-scale hardware, the lab relies on virtual machines wherever possible. The goal is not to replicate a production environment perfectly, but to keep the workflow and constraints close enough to understand how these systems behave.
If you are new to OCUDU or O-RAN, I recommend starting with my previous series Building a Test Lab using srsRAN, since many of the same concepts and configurations are reused here.
The main objectives of this series are:
- zero-touch provisioning of a full RAN network using open source components
- running OCUDU and other RAN workloads on a telco cloud platform
- understanding how infrastructure and RAN management interact in practice
The series walks through the setup step by step, from cluster deployment to running a complete network.
Why Sylva
I attended Sylva Developer Day 2026, and that was the starting point for exploring the platform more deeply.
What stood out is that Sylva is not just about running Kubernetes. It is an attempt to define a common cloud-native infrastructure framework for telco and edge workloads, built collaboratively by operators and vendors.
This becomes relevant very quickly once you move beyond small lab setups. Running a network with a few nodes is manageable. Operating infrastructure at scale introduces fragmentation, inconsistent environments, and a lot of operational overhead.
Sylva tries to address exactly that by defining a shared foundation. It brings together multiple layers into a single model:
- cluster lifecycle management (Cluster API)
- infrastructure provisioning (Metal3, Redfish/IPMI)
- GitOps-based operations (Flux)
- telco-specific capabilities like networking, observability, and security
None of these technologies are new individually. The interesting part is how they are combined and validated as a system.
At its core, Sylva is built around a declarative lifecycle:
- Day 0: provisioning and deployment
- Day 1: running workloads
- Day 2: operations, upgrades, and maintenance
Everything is driven through Git-based workflows and continuously reconciled.
Another important aspect is that Sylva is designed around operator requirements. It is not a product, but a production-grade framework and reference implementation that operators and vendors can build on.
This includes:
- managing distributed clusters across edge, regional, and core sites
- standardizing infrastructure across environments
- validating CNFs on a common platform
- reducing fragmentation between vendors
This is not just theoretical. Projects like Orange Telco Cloud are already using Sylva as part of their cloud-native infrastructure strategy, showing how it can be applied to real deployments.
My goal in this series is to explore Sylva by actually using it. Each step is implemented in a lab setup and validated by running the actual system.
I will deploy Sylva together with a full RAN setup and use that process to understand how the different components are configured, how they interact, and where things become complex.
This includes:
- how infrastructure is provisioned and managed declaratively
- how clusters are created and operated
- how security and platform constraints are applied
- how RAN workloads fit into this model
Sylva Under The Hood
Sylva in this setup is built around Cluster API, Metal3, and Flux, with a bootstrap cluster acting as the initial control plane.
The process starts with the bootstrap script, which creates a temporary Kubernetes cluster using kind and installs Cluster API together with the kubeadm bootstrap and control plane providers, CAPM3 for infrastructure, and the initial Sylva components managed through Flux.
This bootstrap cluster is responsible for provisioning the management cluster and installing the initial Sylva control plane components.
The environment configuration is then applied through Cluster API resources, defining the management cluster using objects such as Cluster, KubeadmControlPlane, and MachineDeployment, along with BareMetalHost objects that represent the nodes.
Cluster API controllers reconcile these resources and trigger the creation of the management cluster, with CAPM3 and Metal3 handling the underlying infrastructure provisioning.
Provisioning is handled through CAPM3 and Metal3. The Metal3 stack deploys Ironic and the BareMetal Operator, which interact with the nodes via Redfish. In this lab, those Redfish endpoints are provided by sushy-tools, which allows Metal3 to provision the libvirt VMs as if they were physical machines.
Once provisioning starts, Ironic handles inspection and image deployment, while kubeadm initializes the control plane and joins the nodes to the cluster.
Once the management cluster becomes available, control shifts from the bootstrap cluster to it. It now runs its own Cluster API and Metal3 controllers and becomes responsible for further lifecycle management.
Sylva defines the platform as a set of units, which translate into Helm releases and manifests. Flux is already used during bootstrap to install the initial Sylva stack, and continues running on the management cluster once it becomes available. From there, it continuously reconciles the system from Git, installing and maintaining components such as networking, registry, observability, and security.
From this stage onward, the system operates entirely through reconciliation loops. The management cluster provisions infrastructure, manages cluster lifecycle, and maintains platform services as a single declarative system.
In practice, this means the bootstrap cluster installs the initial control plane, Cluster API and Metal3 provision the infrastructure, and Flux turns the cluster into a complete platform through continuous reconciliation.
For more details on the overall architecture, see the Sylva Solutions Overview.
Lab setup
The lab is intentionally minimal, but it follows the same structure as real production deployments.
Slyva requires a BMC for the management cluster. Since this lab does not fully rely on bare-metal infrastructure, the management cluster is provisioned using virtual machines while still following a bare-metal workflow.
This is done using libvirt together with sushy-tools.
libvirt is used to create and manage the virtual machines that act as nodes. On top of that, sushy-tools exposes a Redfish-compatible API backed by libvirt. This effectively turns each VM into something that behaves like a real server with a BMC.
From the outside, these VMs are not treated as virtual machines but as bare-metal nodes with a Redfish endpoint. This is important because Metal3 does not interact with hypervisors directly. It expects a BMC and uses Redfish to control the lifecycle of a machine. sushy-tools bridges that gap by translating Redfish operations intOnce provisioning starts, Ironic handles inspection and image deployment, while kubeadm initializes the control plane and joins the nodes to the cluster.
o libvirt actions.
As a result, operations like power management, boot device changes, and image provisioning are executed through Redfish, even though the underlying node is a VM.
This allows the full Metal3 and Cluster API workflow to run unchanged in a lab environment, without requiring additional physical hardware.
The workload cluster runs on a single-node Advantech server and is also provisioned via Redfish. I will look into this in the next post.
The general goal of the test lab is not to simplify the system, but to reduce hardware while keeping the deployment model realistic.
What this series will cover
The series builds the system step by step:
- deploying the management cluster
- deploying and tuning the workload cluster for RAN workloads
- setting up a GitOps workflow
- deploying the full RAN using Flux
Each step focuses on what actually happens during deployment, including where things work as expected and where they do not.
What this is not
This is not:
- a complete Sylva reference guide
- a minimal quick start
- a comparison of telco cloud platforms
It is a practical walkthrough of one setup, including the design decisions, trade-offs, and issues encountered along the way.
Next steps
The next post focuses setting up the Slyva management cluster. This includes defining the cluster layout, setting up the infrastructure using libvirt and sushy-tools, selecting the required components, and deploying the first cluster with Sylva.
From there, the focus shifts to deploying and preparing the workload cluster so it is ready to run RAN workloads.