It’s the course change that has already changed the face of enterprise data centers: containerized infrastructure. Portable components that are automatically deployed and not tied down to virtual machines, usually orchestrated by the most pervasive new software tool since Linux: Kubernetes. Now telecommunications companies are preparing to enable containerized network functions (CNF) — highly distributed, highly resilient services distributed throughout their cloud platforms. They may be easier to manage than their hypervisor-based virtual network function (VNF) counterparts, as well as simpler to upgrade, easier to secure, and even cheaper to operate.
It is, as some have argued, the encroachment of Kubernetes into the telco data center, and into the very heart of the 5G Packet Core that will host modern communications. But there are others who are arguing against that point of view, saying that the style of orchestration that enterprises rely upon to manage web and cloud applications does not apply to the telco world, where tenancy is secured on a deeper level of the network, and functions are apportioned into slices for high security.
“Cloud is fundamental to 5G, and it’s going hand-in-hand,” explained Chandresh Ruparel, director of 5G Wireless core infrastructure at Intel, during a recent press conference. “Carriers are both migrating to a new cloud-native framework, as well as deploying a 5G infrastructure at the same time.” The expression “cloud native” usually describes an infrastructure where containers and orchestrators like Kubernetes are fundamental.
Ruparel described two examples of Intel adaptations, plugins for Kubernetes that use its Container Network Interface (CNI). These plugins are specifically for making Kubernetes functional as an orchestrator in a telco environment. One is SR-IOV, which makes the physical resources exposed by PCI Express devices addressable as virtual functions. Another, called Multus, leverages Intel’s Data Plane Development Kit (DPDK) — used in telco environments everywhere — to make multiple physical network interfaces in the user plane addressable in a single Kubernetes workflow. Both are explained in this December 2018 Intel document [PDF].
The same week as Intel’s press conference, however, a principal Cisco 5G engineer advanced a convincing counter-argument. At its heart was this theme: Containerization does not necessarily mandate Kubernetes.
“Kubernetes is a tool that was designed for generic application workloads,” said Aeneas Dodd-Noble, principal 5G architect at Cisco. “It is not for network applications. They have unique requirements in terms of performance, availability, connectivity, scale, and redundancy. What this essentially means is that those great tools that are good for running enterprise applications, or Web applications, are not totally well designed for running telco applications — especially the user plane ones.”
So which is it? Either Kubernetes is a vital resource or it’s a square peg in a round hole. At least from these descriptions, it certainly can’t be both or something in-between.
“I think the answer is a little bit of both,” responded Craig McLuckie. He, along with Brendan Burns and Joe Beda, is a pioneer of container orchestration, who brought Kubernetes into being as an engineer at Google. Now McLuckie is VP of research and development at VMware.
“The way I tend to look at this: Kubernetes and the cloud-native patterns introduce a tremendous amount of opportunity in the 5G Core space,” continued McLuckie, in an exclusive interview with Data Center Knowledge. “In general, I tend to steer customers towards virtualized environments, because they benefit from decades of work in resource isolation and security isolation space, all the way down to the silicon. In the case of network function virtualization [NFV], obviously, those data plane workloads have relatively unique profiles. So there’s naturally going to be relatively high levels of customization required, both in terms of the runtime environment in which it’s running, but also as it relates to the scheduling module.”
Unlocking the 5G Core requires high customization, he conceded. The software engineering community as a whole could tackle this problem, he believes, to make this feasible.
“The thing that makes it still Kubernetes,” added McLuckie, “is the question around whether the core Kubernetes patterns and capabilities still hold. Kubernetes as a system was always built to be highly modular, highly pluggable, highly extensible. I think that’s been a foundation for a lot of its success. While you may not have success taking an off-the-shelf, upstream Kubernetes distribution without modification, and looking to run CNF workloads… I do believe there’s a tremendous amount of value to staying true to a lot of the core Kubernetes principles, as it relates to building and managing highly complex, distributed systems. So my perspective is that, it’s somewhere in-between.”
McLuckie puts forth a vision where a data plane workload orchestrator built on Kubernetes’ principles, if not the system itself, but utilizing plugins that fit the CNI interface originally developed for Kubernetes, becomes pervasive through the 5G Core and the cloud built around it. It may not be called Kubernetes when it’s all done, but that may end up depending on whether implementers such as Intel, HPE, and Cisco choose to invoke that image.
