Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building the Cloud Native Telco with Network Service Mesh - Ivana Atanasova & Radoslav Dimitrov

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Building the Cloud Native Telco with Network Service Mesh - Ivana Atanasova & Radoslav Dimitrov, VMware

Nowadays, the rapid technology development, significant increase of the number of connected devices and overall generated traffic, are challenging the networking solutions to evolve fast. Those solutions would hardly meet the higher demands for scalability and resiliency without adopting a cloud-native approach. Therefore, network service providers, like ISPs and Telco operators, are at the point of looking for a way to adopt the new cloud-native paradigm for their sophisticated network demands. Network Service Mesh is a CNCF project that offers a potential solution. In this talk we are going to introduce the approach Network Service Mesh is using to solve complicated L2/L3 challenges in Kubernetes and provide an example of building real cloud-native network topology using the tools provided by the NSM project. We are also going to show a demo of that topology implementation with NSM.

https://sched.co/ZepE

A

Hey welcome everybody and thank you for joining this virtual session. My name is rodusov dimitrov and I'm here with ivana tonassova and we're both part of vmware's open source technology center. Today we're going to talk about a project called network service mesh.

B

Hello, looking for a good point to start from, let's talk about the technology evolution through the years first, we had those monolithic applications ring on bare metal machines.

B

Then the vmwave came out and we started migrating our work walls to virtual machines. We did that for benefits like reduced operational costs, faster provisioning, improved efficiency and much more now, it's all about containers and microservices.

B

Here, projects like docker and kubernetes are becoming the standard for such systems. Of course, this maps perfectly in use cases that allow rapid and fast adoption of new technologies.

B

But let's see how this looks like through the eyes of a talk.

A

So apparently, tokus are moving a bit slower, but that's not always bad. Due to their nature. They prefer to use only well-established technologies in their systems, so, for example, this is how a typical telco system evolved through the years. Initially temple consisted of lots of physical boxes each and everyone implementing a specific network function within that system.

A

Then they decided to adopt virtualization. So all those physical boxes were migrated to virtual machines.

A

This introduced the concepts called virtual network functions or vnfs, and it pretty much changed the way networking was done for the last couple of decades and it is known as the first wave of nv now decors are looking again at the enterprise to leverage the benefits of the cloud native world and, for example, adopt technologies like kubernetes and docker in their systems.

A

This introduces a new concept called cloud native network functions or cnfs.

A

At some point, the end goal would be to have a mixed setup of network functions, meaning that bare metal machines, virtual machines and containers live as a single entity network.

B

A

Mesh is a project that aims to be part of that transition.

B

Let's talk about what is a network service? Imagine there is an application and that it runs in the public cloud. It needs to connect to another cloud or to a corporate internet in order to consume some custom service. That is exposed, and this opens a problem because usually the application takes care of implementing the connection logic and the app doesn't actually want to know about that.

B

Why, for example, what if the connection changes and what, if we have multiple applications in that case, we would need to update each of that of them in order to apply those connection changes, and we need to do that every time when there is such change, we can agree that this is not very efficient, so what we can do. Instead, we can offer that to a network service that provides such functionality.

B

In this case, we have clients that requests a network service. We have endpoints that implement a network service and the communication between them happens through wires that are payable agnostic. All these components form the concept of network service mesh.

A

B

Is network service.

A

Mesh, it is an infrastructure layer for managing layer, 2 and layer 3 service to service communication. It provides on-demand and negotiated point-to-point connections and it exposes a grpc api through which you can publish and consume network services. And finally, the great thing is that all that happens without any changes to kubernetes or the underlying cni network.

B

Let's see how we can describe the previous example of a network service in a simple yaml file, we need to specify a payload type, for example an ip. We need source and destination selection. In our example, the client was connecting to a firewall and then through the vpn gateway. So in our yaml file, the default match is going to the firewall, and then it goes through. Gvpn gateway.

B

This way of service definition makes it possible to chain multiple clients or endpoints and to create the so-called service composition. This allows us to describe to the technology that serves our needs.

B

How this example looks like in typical kubernetes deployment, we have kubernetes, we have network service mesh deployed on top and we have three parts to rank. One client and two end points: what happens? First, the endpoints announce themselves to network service mesh. Then the client requests a network service from network service mesh.

B

Finally, any same takes care of creating the necessary connections. It injects network interfaces to all the pots and it creates a communication to know between them, and this creates the connection.

B

A really great thing here is that all this happens without any changes to the underlying cni. The cni is great enough, so why it changed now, let's zoom a little and see how network service mesh works in more details.

A

So how it works nsm consists of two main building blocks: it has a manager and a forwarding plane the two live on every node, but have different responsibilities.

A

We also use the case api as a registry for our network services. The manager is responsible for negotiating the connection details and to make sure that the job will be done and everything is okay. Once we have set that details, then we need someone to actually do the work right. Well, that someone is the forwarding plane.

A

Now, let's see how a connection request looks like we start by deploying our network service via the yaml file from before, once our endpoint is started, it announces itself to its local manager. That then saves that information inside the registry.

A

On the other side, we have a client that wants to consume our network service.

A

It requests it from its local manager that seeks for information about that network service inside the registry once it finds out, which is the manager responsible for that network service. The two majors start to negotiate the connection details.

A

Once this is completed, they fit that information down to the forwarding place.

A

Then it's up to them to create the communication tunnel between the two nodes, create the necessary interfaces and inject them inside the pods, and thus complete the connection between the client and the firewall.

A

Now, let's have a more talk oriented example in this case we're going to recreate the topology of a 4g lte network using network service mesh.

A

Now, let's see how a standard 4g network looks like. First, we have the user equipment, which are the devices that use that network stuff, like phones, cars, iot devices and so on.

A

B

We have the radio access network.

A

Which which are basically lots of antennas or base stations, then we have the evolved packet, core network or epc, which are a set of components. Each responsible for different service within that system, for example, stuff, like user authentication, charging gateways that manage quality of service and so on.

A

The output then goes to the data network, for example the internet. In this talk, we're going to focus on that box in the middle and recreate the network topology for the packet core network.

A

So, let's see how to do that using network service mesh first, we decide that each component is going to be a different pot within kubernetes.

A

Now that we have a bunch of ports, we want to connect. We need to decide how to map that to network service mesh, although we can have a port that is both client and endpoints to simplify it, we'll create the setup in such a way that the single body side of the client or an endpoint, considering that the end result looks like the following.

A

For example, we chose mme to be an endpoint and hss to be a client.

A

Once we have covered that, then we need to describe the topology in the network service yaml file, as we said before, it consists of a set of matches and each much have a source, selector and a destination selector.

A

This means that if your request is coming with a label matching the source selector, we should put it for an endpoint with a label from the destination selector.

A

For example, s6a is our source selector, which is a label coming from the hss client and mme, is our destination selector, which is the label advertised by the mme endpoint.

A

We complete describing the whole topology using that same approach for each connection.

A

B

A

How the ktml files looks like for both endpoint and client for the endpoint, we specify the network service it belongs to. In this case this is 4g network. Then we specify the endpoint label we'll advertise from this endpoint. In this case, this is mme for the client. We want to say which network service it wants to consume right to do so, we specify the network service and the label we're going to advertise as a client. In our case, this is 4g network and s6a.

B

Now, let's see the actual demo of the 4g network, topology example, we will be using network service mesh with kubernetes. So we have a simple burnet is deployment. We have to note cluster. There is nothing fancy in it.

B

Then we deploy network service mesh infrastructure using here we will wait for a while until the deployment is done and until all the pots are available and are ready.

B

So once there once the deployment is completed, we can see that there are two nsm managers and there are two forwarding planes, each of them for each note of the cluster, as we showed in the previous in the examples, then we proceeded by deploying the yaml files that we created earlier after that we can see that each client and endpoint are being deployed.

B

Here are all the components that we already showed in the example once this is done and once all the pots are ready. This completes deploying the 4g network topology that we described in the yaml file.

B

This means that all the necessary interfaces and connections were created created by the forwarding planes, in that all the components can communicate with each other. But we now need to verify that so that we have everything deployed. We need to make sure that it is created as we wanted it to be. For that reason, we have a script that verifies the connections between each client and endpoint, the the script loops through all the clients and it pings the corresponding and from endpoint.

B

For that client we can see the successful pings from the output, and we can also see the endpoint and client port names in the same output.

A

So what else can we do? We can use a dashboard like skydive to better visualize our deployment, and what do we see? We see our two worker nodes being there and we can see the pots that live on each node. You can see the clients and we can see the end points for each pot. We can see the containers that live inside it and the available network interfaces has a good thing that we can visualize here is that we can see the pot to pot connections that are created by network service mesh.

A

We can also see some specific information for each interface stuff, like type state address and even its matrix, and this is available for both nsm and cni created interfaces with that we can see that having a dashboard like skydive presents a pretty neat way to better understand your deployment and visualize it in a nice and simple manner.

B

With that example, we showcase that nsa makes it possible to have flexible and dynamically defined infrastructure using a simple api. This is something really important for use. Cases such as telco. Another thing to share is that we are also actively involved in the cncfcnf facebook for those of you that don't know about it. This is an initiative to evaluate how cnf architectures compare to the more traditional vnf ones.

B

There are two already there are two network service mesh based use cases that are present there and there is an ongoing work by ericsson to provide a network separation use case.

B

What's next, with the project, we have an ongoing multi-rep refactoring that will improve the project structure. We have a kubernetes operator for deploying and managing network service mesh. There are also very interesting contributions in the forwarding playing context.

B

We have. We are working on support for multiple simultaneous foreigners.

B

Also ericsson are working on a forwarder with hardware offloading to smart mix, and this will deliver a pci passthrough performance for clients and endpoints in the context of network service mesh, and this will also deliver no host consumed compared to dpdk.

B

We are also working on an srov forwarder and for those of you that are interested, there will be a same seminar covering how network service mesh can address. The networking challenges that cloud native tech applications face in 5g.

B

There will be details and proof of concept on how network service mesh decouples the infrastructure from applications and the speakers. You also give an update of the network separation use case that is ongoing in the cnf.

A

Testbed so the.

B

A

That we see here is that teleco operators and service providers are actively looking at the cloud native world to build their next generation solutions, meaning that containers and all that ecosystem of projects around them will be the next building blocks for that projects like network service mesh aim to provide features that will help to create those future systems and, at the end, be part of that transition, and with that I believe, we've covered all the slides. For this talk, we'd like to say thank you again for attending our virtual session at kubecon europe.

A

We hope everyone enjoyed it and got some var out of it. Thank you.

B

Thank you, and we are also open for questions from the audience.