Tailoring Kubernetes for Telcos

In the IT world, Kubernetes is everywhere. Supported by more than 43,000 contributors, this open-source system has become the default way to deploy modern applications in the cloud. Why? Simply put, Kubernetes makes life much easier for developers, speeding up the rollout of apps and adding value to the underlying platform for end-users.

Kubernetes, also known as k8s, has recently turned heads in the telecoms industry, as operators look to make the transition from walled gardens to open platforms. The system is set to be an intrinsic part of the flexible cloud-native architecture required to bring out the best in standalone 5G networks. A true cloud-native network offers a myriad of benefits, from rapid deployment of services and automation to much greater resiliency and efficiency. As a case in point, Google deploys more than two billion containers a week using its internal platform Borg, which was the predecessor to Kubernetes.

This kind of flexibility and scalability is fundamental to the telco 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 telcos to deploy apps in portable containers, Kubernetes can, for example, bring services to the edge of the network, closer to end-users, reducing latency.

Abstract and appealing for developers

So, what does Kubernetes actually do? A modern application is typically built out of different microservices, each handling a specific function, such as order management, reporting, or payments. Once the microservices are packaged in containers, Kubernetes automates their deployment, scaling, and management. Kubernetes can also support auto-healing in the case of a failure in a cluster of microservices.

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

A Kubernetes ingress controller is the conduit 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. 

Telcos will need to think differently

All these benefits can be harnessed by 5G networks’ service-based architecture, but only if telcos adopt a new mindset. Although Kubernetes delivers many benefits, the system can seem somewhat orthogonal to what telecoms engineers are accustomed to. As they live and breathe networking, telcos 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.

However, this kind of manual configuration would undermine the whole point of Kubernetes: it would prevent the rapid deployment and automated scaling that are hallmarks of the major cloud platforms, such as AWS and Azure. The first network functions virtualization (NFV) solutions deployed by telcos in 4G networks have tended to employ manual scripting and, as a result, lack the dynamism and automation of a modern IT architecture.

A square peg in a round hole?

With the rollout of 5G core networks, telcos have a blank slate. But, unfortunately, they can’t simply transplant a standard Kubernetes system. The vast majority of telcos are deploying 5G networks alongside 4G networks, so they will need a Kubernetes ingress that can also support standard telco 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 complication 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, telcos 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. Telcos 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.

Why cutting corners is a bad idea

One option would be to dispense with Kubernetes and just deploy a 5G function in a container with a static IP address that is accessible to the outside world. But if you cut corners in this way, you would pay a big price in terms of scalability and flexibility. You would not, for example, be able to deploy 5G functions anywhere in the network simply by pressing a button. If you want that level of automation, which will be the future, you can’t cut corners with Kubernetes.

F5 has long straddled the telecoms and IT worlds, and we have figured out how to help telcos harness the extensive benefits of Kubernetes. This includes our BIG-IP SPK solution, which enables a Kubernetes ingress to support telco protocols, as well as HTTP. It also uses network address translation (NAT) and routing to enable a Kubernetes egress to provide a static predefined IP address to the outside world, without impacting the internal dynamism of the cluster. Regardless of what happens inside the cluster, you can always provide the same IP address to external entities. Further, our Aspen Mesh service mesh supports 'telco-grade' observability and tracing. It can give telcos full visibility and tracing for the traffic flowing between the 5G microservices, thereby bolstering security. 

If approached correctly, Kubernetes can be truly transformative for telcos: it can unlock 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 telecoms environment, this open-source system will surely be an integral part of the 5G future.

This article is the first in a two-part series. Next time, we’ll explore how F5 technology can solve the operational headache of managing IT and telco workloads across large numbers of Kubernetes clusters running on different platforms.