Running 5G Network Functions on Bare Metal: What to Size
Running Cloud-Native Network Functions on Bare Metal: What Telecom Teams Should Size First
Operators, neutral hosts and enterprises building private 5G networks increasingly deploy the 5G core as cloud-native network functions running on Kubernetes. The software is portable, but the hardware underneath still decides whether a deployment meets its throughput and latency targets. Packet processing in particular punishes guesswork: a cluster that looks generous on paper can drop traffic once real subscribers arrive.
This guide covers what to size first when running network functions on bare-metal servers, which Kubernetes settings matter most and how to test a design before it carries production traffic.
Control Plane and User Plane Have Different Needs
A 5G core splits into control-plane functions, such as the access and mobility management function (AMF) and the session management function (SMF), and the user plane function (UPF), which forwards subscriber traffic.
Control-plane functions handle signaling. Their load grows with the number of devices, registrations and session events, and they behave much like other stateful microservices: they need reliable CPU, enough memory and solid redundancy, but rarely extreme network throughput.
The UPF is different. It moves every user packet, so its performance depends on how many packets per second each CPU core can process, how quickly data moves between memory and network cards, and how consistently the system avoids interruptions. Many deployments therefore place control-plane functions on general-purpose nodes and give the UPF dedicated bare-metal hosts.
In private 5G and edge deployments, the UPF often runs close to users, at a factory or campus site, while the control plane stays in a central data center. That split makes the user-plane hosts the ones to size most carefully, because there may be only one or two of them per site.
Why Cores, Memory Channels and PCIe Lanes Matter
High-performance packet processing usually relies on user-space frameworks such as DPDK, which poll network cards from dedicated CPU cores instead of waiting for interrupts. That design has direct hardware consequences.
- Core count. Each polling thread occupies a core full time, and you still need cores for the operating system, Kubernetes and monitoring. Servers with many cores leave room for both.
- Memory bandwidth. Packets travel between network cards, memory and CPU caches constantly. More memory channels help keep that path from becoming the bottleneck.
- PCIe lanes. Several high-speed network cards, and sometimes accelerators, need enough PCIe lanes to run at full speed at the same time.
- NUMA layout. Performance drops when a network card is attached to one processor socket while the cores processing its traffic sit on another. Single-socket servers with many cores avoid that cross-socket hop entirely, which simplifies tuning.
Kubernetes Settings That Make or Break Performance
Default Kubernetes scheduling is designed for sharing, which is the opposite of what a UPF needs. A few settings change that.
Exclusive CPUs
The kubelet’s static CPU management policy can give a pod exclusive use of specific cores when it requests whole CPUs in the Guaranteed quality-of-service class. Polling threads then run without being moved between cores or sharing them with other workloads.
Topology, Huge Pages and Device Access
The Topology Manager helps keep CPUs, memory and devices on the same NUMA node. Huge pages reduce memory-management overhead for packet buffers. SR-IOV device plugins expose virtual functions of a network card directly to pods, so traffic bypasses much of the host networking stack.
Housekeeping Cores
Reserve a few cores for the operating system, the kubelet and logging agents, and keep them away from packet-processing threads. Mixing the two is a common cause of unexplained latency spikes. Document which cores are reserved and why, so that a later change to a kubelet setting does not silently undo the isolation.
From Lab Results to Hardware
Vendor figures are a starting point, not a plan. The hardware decision should follow measurements from a lab that mirrors the production design.
Size a Lab Before Production
Build a small lab and measure it with traffic that resembles your subscribers. The table lists what to record. Fill it with your own measurements rather than published examples.
| Item | What to measure | Notes |
|---|---|---|
| Throughput per core | Packets and gigabits per second at your packet-size mix | Small packets are the hardest case |
| Latency | Median and 99th percentile under load | Spikes matter more than averages |
| CPU headroom | Utilization of polling and housekeeping cores | Leave room for traffic peaks |
| Failover | Time to recover when a node or link fails | Test it, do not assume it |
| Upgrade impact | Traffic loss during a rolling update | Shows whether you need spare capacity |
Run tests long enough to catch slow memory leaks and thermal effects, and repeat them after every major software update.
Choosing the Hardware
Once the lab shows how much throughput each core delivers, the server choice becomes arithmetic plus headroom. Many teams test on rented hardware first, because it lets them compare configurations without buying equipment. Bare-metal providers such as Unihost offer AMD EPYC dedicated servers across several generations, and the high core counts, many memory channels and generous PCIe connectivity of that platform suit packet-processing nodes that need many dedicated cores alongside housekeeping capacity.
Check the details that matter for network functions specifically: which network cards are available, whether SR-IOV is supported, how many public and private interfaces the server provides and how quickly failed hardware is replaced. Ask about the data center’s connectivity as well, because the fastest server cannot compensate for a poorly connected location.
Operating the Platform
Network functions run continuously, so operational planning belongs in the design rather than after launch:
- Keep at least one spare node, or enough headroom, to absorb a failure without dropping traffic.
- Automate node configuration, including BIOS settings, huge pages and kernel parameters, so every host is identical.
- Monitor per-core utilization, packet drops and latency, not just overall CPU usage.
- Rehearse upgrades in the lab before touching production.
- Keep firmware and network card drivers on a tested baseline, and change them only together with a lab run.
Running a 5G core on Kubernetes is achievable on standard servers, but only when the hardware and configuration respect how packet processing works. Separate the control plane from the user plane, give polling threads exclusive cores on the right NUMA node, measure throughput per core in a lab and choose servers with enough cores, memory bandwidth and PCIe lanes to grow. Done this way, the network behaves predictably long after the first subscribers connect.