K8S and Telecom

Kubernetes has recently turned heads in the telecom's industry, the Kubernetes.io show several use cases. The system is set to be an intrinsic part of the flexible cloud-native architecture required to bring out the best in 5G networks. A cloud-native network should offer benefits, from rapid deployment of services and automation to much greater resiliency and efficiency.

This kind of flexibility and scalability is fundamental to the telecom cloud vision — the idea that 5G networks will become a versatile platform for a wide range of services and apps developed by third parties. As it enables telcoms to deploy apps in portable containers, Kubernetes can, for example, bring services to the edge of the network, closer to end-users for variety performance use cases.

Kubernetes abstracts away some of the underlying internal networking complexities for app developers that makes life much easier for the typical app developer. It enables apps to be made accessible to the outside world in a simple and straightforward way.

A Kubernetes ingress controller is the tunnel through which an end-user interacts with a web application via the HTTP protocol. The ingress controller also provides traffic management, ensuring that user requests get routed to the right microservice within the Kubernetes cluster.

Why am I writing you info you already know? All these benefits will be required by 5G networks’ service-based architecture. However, the system can seem misaligned to what telecom's engineers are accustomed to. Telecoms are comfortable manually configuring the IP addresses of networking equipment and setting their own rules for routing and load balancing, and other parameters that Kubernetes is designed to abstract.

This kind of manual configuration would undermine the whole point of Kubernetes, it would prevent the rapid deployment and automated scaling that are fundamentals in cloud platforms, such as AWS and Azure. The first attempts virtual 4G networks have tended to employ manual scripting and, as a result, lack the automation of a modern IT architecture.

Theoretically with the rollout of 5G core networks, telcmos are in green fields, but they can’t simply transplant a standard Kubernetes system. The vast majority of telcmos are deploying 5G networks alongside 4G networks, so they will need a Kubernetes ingress that can also support standard telcom protocols — SCTP, Diameter and GTP — as well as HTTP. That is because the Kubernetes ingress that front ends the 5G services won’t interface directly with a user via HTTP but will instead connect to other 4G and 5G core elements. In some cases, an interworking function will be required that translates HTTP/2 messages into diameter messages and vice versa.

Another complexity is how to support internal communication within the application cluster. In a standard Kubernetes deployment, a service mesh is typically used to securely manage and track the communication between different microservices. While such service meshes support IT-centric tracing capabilities, telecoms are discovering that the associated functionality is not optimally adapted to their requirements.

The third issue is how the 5G functions within the Kubernetes cluster will talk to the outside world. Opening up the dynamic internal IP addresses assigned by Kubernetes is not a good idea. The addresses will change over time and giving this level visibility to the outside world would constitute a major security risk. Telcoms want full control over the assignment of IP addresses to certain 5G functions. These should be independent from the IP addresses used by the underlying containers that make up this 5G function. A smart Kubernetes egress function is required to achieve this.

One option would be to deploy a 5G function in a container with a static IP address that is accessible to the outside world. However, cutting corners this way carries big price in terms of scalability and flexibility. For example, telecom's will not be able to deploy 5G functions anywhere in the network simply by clicking a button. If you want that level of automation, which will be the future, you can’t make shortcuts here.

If designed correctly, Kubernetes can be truly transformative for telcoms: it can provide the many benefits of a cloud-native architecture and make it much easier for operators to interact with the outside world. Once it is fully tailored to a telecom's environment, this open-source system will surely be an integral part of the 5G future.