Containers are a hot commodity for public cloud operators and enterprises, and the rate of adoption has ramped up over the last couple of years. While most telcos aren’t among the early adopters, container technology and the supporting ecosystem are rapidly evolving to meet carrier-grade requirements. These developments look to be perfectly timed so that telcos can benefit from container technology in their 5G strategies. Indeed, 5G requires a totally new approach to building packet core networks that is essentially mandating it.
For Metaswitch, containers have been the next evolution in our 35-year history of delivering highly portable networking software that can run on any platform: appliance, COTS, cloud... Containers are units of software that are partitioned based on namespaces in which one or more Linux processes run, supported by the Linux kernel installed on the host system. The difference between a container and a virtual machine is that a virtual machine needs a complete operating system installed in it to support the application, whereas a container only needs to package up the application software, with any application-specific OS dependencies, and leverages the operating system kernel running on the host.
Containers have a number of cost saving advantages. Compared to VMs, containers use less hardware resources because they don’t need the complete OS, they have faster startup times, they require less maintenance, and they are very portable. A container image can run on any Linux host. So, a container app can be written just once and then deployed anywhere.
Furthermore, a blossoming ecosystem of tools have made containers much easier to use. Noteworthy projects include:
- Kubernetes, which manages and orchestrates containerized workloads and services
- Helm, which manages Kubernetes apps via Helm Charts, making it easier to define, install and upgrade apps
- Prometheus, used to provide monitoring and alerts, and
- Grafana, a dashboard to visualize the monitoring data
There are still areas specific to telco requirements that need further work, particularly as they relate to the 5G core. But they are all solvable problems and solutions are in the works. For example, the most common problem with the Kubernetes ecosystem for containers is that there is only ever one network interface. So, as containers are grouped into pods, each pod has a common network interface that is shared by all the containers within it. Telco networks in general and the control and user plane functions in the 5G Core, need multiple network interfaces.
One of the solutions for multiple interfaces is the Multus CNI (container network interface) plugin, which was proposed by Intel and is currently being adopted in the next version of Kubernetes. Multus provides multiple interfaces into a container pod.
Along with multiple networking interfaces, telcos apps also need accelerated networking. In the 5G Core, fast packet processing is critical for the user plane function (UPF), for example. We’ve used CNI plugins to apply single root I/O virtualization (SR-IOV) to provide this accelerated packet handling and networking
Looking at the network functions in the 5G core, control plane functions such as the Session Management Function (SMF) or Access and Mobility Management Function (AMF) are also well suited to the Kubernetes containers model. The UPF is more complicated, but it can also be architected in cloud native software with an innovative approach to packet processing, as delivered by our Composable Network Application Processor (CNAP).
The rapid adoption of Kubernetes by public cloud operators and enterprises will simplify the deployment, provide the flexibility and enable the new service delivery models of 5G networks. A carrier-grade 5G Core can be deployed on containers, so long as telcos adopt the entire container ecosystem using well-defined APIs.
Obviously the core software will also need to be natively designed for containers (“cloud native”) and, critically, also include a declarative configuration model that defines how the system should be considered and automated. APIs will obviously also be needed that can be interacted with by all of the ecosystem partners, processes and workflows involved.
For more on containers, check out our previous posts:
