Kubernetes has quickly become a major player in the containerization of 5G network deployments, but the Istio service mesh project initially designed to help micromanage those containers is gaining ground as the real driver of those efforts toward the network edge.

That push was the topic of a 5G-focused panel at this week’s inaugural IstioCon virtual event. The panel noted that Istio’s role in 5G networks is tied to the edge deployments and microservices running on containerized environments needed to support 5G use cases.

David Lenrow, an “open source service mesh evangelist” and senior principal cloud security architect at Verizon, explained that while Kubernetes can handle the orchestration of those cloud native network functions (CNFs) from a central point, Istio’s lower overhead allows it to deal with the layer 7 networking challenges of those CNFs running at scale in a resource constrained environment like the edge.

A service mesh like Istio typically acts as the chain that links CNFs to form more complex networking functions. It does this through a sidecar implementation that allows the service mesh to act as that link through which shared resources can travel between the individual CNFs. Kubernetes remains the overall orchestrator for those CNFs from a more centralized position, while the service mesh is the link out at the actual CNF deployments.

Lenrow also explained that Istio’s ability to live out on the edge and act as an immediate intermediary between functions also enhances network security.

“The fact that the sidecar itself is adjacent to the operating system and application space rather than one hop away in the middle box ends up with a scenario where you have much better context to build strong identity by looking at process tables and socket tables and things of that nature,” he explained.

Neeraj Poddar, co-founder and chief architect at Aspen Mesh, added that Istio can also act as a way to bridge communication between legacy virtual network functions (VNFs) that are built to run on virtual machines (VMs) and CNFs that are built to run in a containerized environment.

“This is a common problem that you will have whether it's a 5G platform, or whether it's enterprise application, you will have legacy functions that have to talk to containerize modern applications,” Poddar said.

Istio is not the only service mesh platform targeting the 5G ecosystem. Google, for instance, has its Kubernetes-focused Anthos platform at the center of its 5G telecom efforts. This is through its Anthos for Telecom product that moves its Anthos platform closer to an operator’s network edge. Anthos offers its own Anthos Service Mesh that is based on Istio.

And F5 late last year rolled out its Carrier-Grade Aspen Mesh service that is based on its Aspen Mesh platform that rides on top of Istio.

This initial IstioCon event comes after what was an eventful year for the service mesh community.

Google, which along with IBM and Lyft initially created the service mesh platform, made a controversial decision to move the Istio project into its newly formed Open Usage Commons (OUC) group instead of into a traditional open source group as was expected.

The project has since been active in attempting to assuage backers that it remains the control plane layer of choice. And those efforts seem to be paying off as a recent Cloud Native Computing Foundation (CNCF) user survey found that Istio remained the service mesh of choice.

Other service mesh platforms have since taken the uncertainty surrounding Istio to offer up their own offerings as an alternative. This includes the long-standing Linkerd open source project, the Kong-backed Kuma service mesh, and Microsoft’s Open Service Mesh (OSM) and Service Mesh Interface (SMI).