Originally reported by Light Reading (October 2019). This article summarizes and expands on the original reporting.
Red Hat’s Strategy: One Platform for CNFs and VNFs
Red Hat has been working to make OpenShift a first-class platform for telecommunications network functions, aiming to support both containerized network functions (CNFs) and virtualized network functions (VNFs) on Kubernetes. As of late 2019, these workloads ran on separate Red Hat products: VNFs on Red Hat OpenStack, and containerized applications on OpenShift. Red Hat’s goal was to converge these platforms.
“Today these are two separate products from Red Hat,” Azhar Sayeed, Red Hat Chief Architect for Telecommunications, told Light Reading. “From our perspective, it’s about preparing the infrastructure to run VNFs and CNFs.”
OpenShift was already a strategically important product for Red Hat, extending Red Hat Enterprise Linux (RHEL) into cloud-native infrastructure. It runs on-premises, on bare metal, on private clouds (OpenStack, VMware), and on public clouds including AWS, Microsoft Azure, and Google Cloud.
Key OpenShift Enhancements for Telecommunications
Red Hat was expanding OpenShift capabilities specifically to address the unique requirements of network functions. The enhancements covered several critical areas:
- Performance and hardware acceleration: Necessary for latency-sensitive network workloads that previously relied on purpose-built hardware.
- IPv6 support: Upstream Kubernetes was expected to receive IPv6 support, a requirement for many telco network functions. Red Hat indicated it expected to support IPv6 within approximately three months of the October 2019 announcement.
- IP networking enhancements: Improvements to support the demanding IP networking requirements inherent in CNFs.
- Application lifecycle management: Extended capabilities for upgrading, deploying, packaging, and managing network functions — covering compute, network, and storage resources. Red Hat was bringing to applications the same lifecycle management it already provided for infrastructure.
Earlier in May 2019, Red Hat had also added capabilities relevant to telco operators: service mesh for virtual networking between microservices, Knative for serverless application support, and a partnership with Microsoft on Kubernetes-based Event-Driven Autoscaling (KEDA).
Why CNFs Matter: The Case Over VNFs
Network Function Virtualization (NFV) emerged as a way for telecommunications operators to reduce vendor lock-in by replacing proprietary hardware appliances with software running on commercial off-the-shelf (COTS) servers. The first generation of NFV produced VNFs — network functions running inside virtual machines (VMs).
CNFs represent the next evolution. Sayeed explained the key architectural difference: each VM carries its own full copy of the operating system, database, and supporting infrastructure, while containers share those layers. This makes CNFs significantly lighter weight. The practical advantages include:
- Higher workload density: More network functions can run on the same hardware.
- Improved resource efficiency: Shared OS and runtime layers reduce overhead.
- Better uptime characteristics: Microservices-based design supports independent scaling and faster recovery.
- Potential performance benefits: Reduced overhead can translate to lower latency in suitable configurations.
Beyond the technical advantages of containers themselves, running CNFs on Kubernetes creates an operational benefit: operators can use a single, unified platform for both IT workloads and network functions. This consolidation can improve utilization of hardware, reduce software licensing complexity, and lower the skills burden on engineering teams.
The Real Bottleneck: CNF Availability from Vendors
Sayeed was candid about where the real constraint lay. The major bottleneck to deploying CNFs on OpenShift was not gaps in OpenShift’s capabilities — it was the limited availability of CNFs from network equipment vendors. As of late 2019, the primary CNFs available were load balancers, firewalls, and policy control functions. Vendors that had committed to supporting OpenShift with network functions included Metaswitch and Clearwater.
This vendor readiness gap is a common pattern in platform transitions: the infrastructure platform can mature faster than the application ecosystem that must run on it.
Operator Adoption and IBM Acquisition Context
OpenShift had attracted meaningful support from telecommunications service providers. AT&T included OpenShift as part of a strategic alliance with IBM, Red Hat’s parent company following IBM’s $34 billion acquisition of Red Hat, which closed in July 2019. Turkcell, operating with more than 35 million subscribers and near-total population coverage in Turkey, was relying on Red Hat OpenStack to support an ambitious target of virtualizing 40% of its network by the end of 2019.
The IBM acquisition provided Red Hat with additional resources and enterprise reach, while keeping Red Hat’s open-source model intact — a critical requirement for maintaining operator and developer trust in OpenShift as a neutral platform.
KubeCon 2019 Demonstration
Red Hat planned to demonstrate an end-to-end 5G network running on OpenShift at KubeCon North America 2019 in San Diego. The demonstration was intended to show the platform running CNFs both on-premises and in the public cloud, providing a practical proof point for the telco-on-Kubernetes story Red Hat was building.
Takeaways for DevOps and Platform Engineers
- Kubernetes is increasingly being positioned not just for IT workloads, but for telecommunications network control plane functions — a significant expansion of its operational scope.
- The convergence of VNF (OpenStack-based) and CNF (Kubernetes-based) infrastructure is an active engineering challenge, not a solved problem.
- Features like IPv6 support, hardware acceleration, and robust application lifecycle management are prerequisites for running production network functions on Kubernetes — not nice-to-haves.
- The ecosystem readiness of CNF vendors is a practical constraint that platform maturity alone cannot solve.
- Operators evaluating Kubernetes for network functions should assess both platform capabilities and the CNF vendor ecosystem for their specific function types.