Mesh Service for OSI Layers 2 and 3
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
...Buy this article as PDF
(incl. VAT)