Network Lego

Kubernetes is not necessarily the brightest star for people who operate networks, because it does not cover more complex network scenarios, such as those found in ISPs, telecommunications companies, and advanced enterprise networks. The Container Network Interface (CNI) only creates the network interfaces required for containers when creating the pods and nodes and removes them when the resources are deleted [1].

This comes as no surprise, because Kubernetes' flexibility mainly relates to applications. Thanks to application service meshes like Istio, Open Systems Interconnection (OSI) Layers 4 (the level of TCP streams and UDP datagrams) and 7 (HTTP/application protocols) can be configured comprehensively, whereas the underlying Layer 2 and Layer 3 network (frames and IP packet layers) cannot.

Who Needs It?

The developers [2] of Network Service Mesh (NSM) [3] are committed to making their Kubernetes-oriented approach attractive for companies that want to use cloud-native models for Network Function Virtualization (NFV) [4], 5G networks, edge computing, or Internet of Things (IoT). Whereas network functions offered by telcos currently run as virtualizations on hardware (i.e., virtualized network functions, VNFs), in future, they will become cloud-native network functions (CNFs) and reside in containers. The Network Service Mesh project is still at a very early stage; version 0.1.0 (code-named Andromeda) was released in August 2019, but some key points of the intended route for the Network Service Mesh have already been defined.

Theoretically, it would also be possible to reproduce subnets, interfaces, switches, and so on in virtual form as containers or pods in Kubernetes. However, the project managers take a rather skeptical view of this, referring to it as Cloud 1.0, because many benefits of cloud-native applications would be compromised. For example, if a developer in such a scenario wanted to provide a pod with a virtual private network (VPN) interface to connect to their enterprise VPN, they would have to take care of the details of the IP addresses, subnets, routes, and so on.

Enter Service Mesh

The Network Service Mesh project aims to reduce this complexity by adapting the existing service mesh model in Kubernetes to allow connections on network Layers 2 and 3. For this purpose, it introduces three concepts: network services, network service endpoints, and connection interfaces.

The project also provides an illustrative example [5]. The task is to give a pod or network service client (which in the example belongs to a user named Sarah) access to a corporate VPN (Figure 1). The pod requests a network service to this end.

Figure 1: To explain the basic functionality of a Network Service Mesh, the project has developed a well-made presentation. In it, user Sarah tries to connect her pod to a corporate VPN. © Networkservicemesh.io

In the example, the name of the VPN is secure-intranet-connectivity and encapsulates one or more pods on the network, which in turn are referred to as network service endpoints. A network service like this can be defined in YAML format (Listing 1), much like services in Kubernetes.

01 kind: NetworkService
02 apiVersion: V1
03 metadata:
04   name: secure-intranet-connectivity
05 spec:
06   payload: IP
07 [...]

In the example, the network service initially consists of a pod that provides a VPN gateway as a network service endpoint. The idea now is for the client pod to connect to the VPN gateway through which to access the company VPN.

Search and Find

To ensure that the client pod finds the network service with the VPN gateway, the VPN pod identifies itself in the network by what is known as a destination label: app=vpn-gateway. In turn, the client pod sends a destination label with its requests (app:vpn-gateway), which helps the pod find the gateway.