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

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Hacking on Network Service Mesh Dataplane for a True Multi-c... Aleksandra Kowalska & Jaroslaw Lukow

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.

Hacking on Network Service Mesh Dataplane for a True Multi-cloud Experience - Aleksandra Kowalska, Netcompany & Jaroslaw Lukow, Nine Fives Labs

In this session the presenters will guide you through integrating Network Service Mesh with the Tungsten Fabric SDN controller as the dataplane tunnel provider. The session will bring both information about the NSM architecture and its use-cases. The TF's ubiquity of integrations (Kubernetes, OpenStack, VMware, physical appliances etc.) enables to demonstrate the true concept of cloud-native networking - when the location of the network service is irrevelant to the consumer and she can focus only on the required functionality. Thus, we can mix and match different clusters, orchestrators and technologies to provide a flexible networking environment.

https://sched.co/Zepf

A

Hi, my name is ola and.

B

I'm jarek greetings from warsaw.

A

We are devops engineers and we help developers in optimizing, build and deployment processes on different environments, mostly kubernetes.

B

We would like to tell you about two great pieces of technology, namely network service, mesh and the tungsten fabric virtual network controller, and how to make them work together to form a nice multi-cloud setup.

B

If you have ever deployed an application in a kubernetes environment, there is a high chance that you encountered some problems when trying to connect to the outside world. Everything works perfectly as long as all your dependencies are contained inside a single kubernetes cluster. But when you start to integrate with some external services, you need to deal with stuff like routers firewalls security policies and different vpn applications that don't really fit into the cloud native automation provided by kubernetes, and they actually shouldn't be a concern for your application.

A

Network service mesh is a tool that aims to solve this exact cloud native networking problem and be a game changer in this field. It brings cloud native to the networking world by exposing an api that allows you to dynamically, create and attach your workloads to services. Inside and outside of your deployment, environment and tungsten fabric appears to be a great complementary technology for network service mesh, and we would like to show you why.

B

So here comes the agenda for today.

A

We will start with a brief introduction about network service mesh, so what it is and what architecture it has. Then we'll explain on a high level how the connectivity between apple and external world can be established with nsm.

B

Then we'll say a few words about what is tungsten fabric and we will give um overview of the implementation of a tungsten fabric for water for nsm, which we've prepared for this presentation. At the end, we'll give a demo of tungsten fabric for water with openstack cluster and kubernetes cluster.

A

Okay, so, let's start with a question: what is network service mesh, so network service mesh is cncf standalone project that extends networking solutions implemented in kubernetes, and it provides l2 l3 networking for applications deployed in kubernetes and facilitates the configuration of connectivity between a pod and external services, for example, pods from different cluster.

A

Basically, you can think of it as a way to dynamically attach additional network interface to a pod.

A

Let's take a look at a few network service, mesh components relevant for this presentation, so network service registry- it's here- and it contains all the available virtual networks. In this case it's alice and bob network service manager. uh It is a control plane component, it is a demon set deployed on each node in a cluster.

A

It accepts network service, requests from pods, verifies network service presence in network service registry and forwards. The request to the forwarder and network service mesh forwarders. So ford is a data plane component.

A

It provides the connectivity requested by the manager, and this is a plugable component, so official network service, mesh called repository provides implementation for vpp and kernel, but we want to show you how the new implementation can be done on tungsten fabric example.

A

So, let's talk now about how network service mesh is used to establish connectivity between a kubernetes board and an external service, so we have a kubernetes node with a pod pod a inside, and how can we connect with an external network from the pod?

A

So, first we need to install network service mesh in the cluster, so this part and it will provide network service manager and for other modules and network services manager, maintains a list of available folders and network services and it's called network service registry, and in this example, we have two forwarders here and two networks already registered.

A

So what happens? Next?

A

Pod a creates network service requests to network service manager to attach to a new service to a new network service in request it specifies to which service it wants to be connected to and which mechanism should it should be used with uh which for order, so it wants to be connected to alice and it wants to use vpp forwarder in this case.

A

And and this request can be sent whenever application needs to connect to the network, uh so yeah now uh manager takes over and manager verifies if alice network is available in the registry. So, yes, it is available. The response, positive response goes back and now network service manager forwards the request to the forwarder to the vbp forwarder, because this is what pod a requested and forwarder adds an interface to port a and enables connectivity to alice network, and that's it.

A

We have pod a connected to the external service through newly created network service network interface, sorry, but of course default. Kubernetes bot network is still available, so this is how network service mesh works and each forwarder has its own mechanism for providing connectivity to the services.

A

Today we want to show you how tungsten fabric can be used as such mechanism, so to do so, we've prepared our own forwarder, which we'll present later on, but let's talk about tungsten fabric first, so what is tungsten fabric tungsten fabric is networking backend for kubernetes openstack and for public clouds.

A

For example, it allows to create virtual networks to provide connectivity between virtual machines on openstack and bottom kubernetes, and in the demo we will show interoperability between kubernetes and openstack, but the same approach can be used to connect ports to any other environment supported by by tungsten fabric. So it gives you an opportunity to create multi-cloud architectures.

A

So on the slide, we have an example of timestamp fabric installed on openstack, environment and tanks. Fabric is the main network provider in this cluster, so tungsten fabric connects virtual machines and private networks. It provides overlay networking in the picture. You have four virtual machines on two openstack hosts with tanks and fabric v. Routers installed within and tungsten fabric maintains a global routing table and keeps it synchronized between the vibrators.

A

So now we'd like to connect this word to a kubernetes cluster. So here comes network service, mesh for border for tax and fabric.

A

So first, let's get back to the setup of kubernetes cluster with network service mesh already installed and, let's add the tungsten fabric cluster to the picture.

A

So what we need to do is to install two new components: a tungsten fabric, v router and thanks a fabric forwarder for network service mesh, so that v router is data plane component. It is responsible for packets, tunneling to other v routers and the forwarder is control plane and it carries out stitching the port together with the v router.

A

Okay, so again, pod a wants to connect to the network, so it creates a request to network service manager to attach to a network, but this time it says it wants to use tanks and fabric for order, and it still wants to connect to alice network.

A

Okay, so network service manager takes over and it asks network service registries is there and, yes, it is so response go back, and now, thanks for fabric forwarder takes over. So thanks and fabric for links, port a to alice network by adding an interface to a pod, an interface is plugged into v router.

A

An entry is added to the tungsten fabric writing table with a new ip address associated with kubernetes node, and in result we have configuration set up in v, router and virtual network routing table, and that enables pod a to have two-way communication with virtual hosts in the tungsten fabric network.

A

So now, thanks the fabric controller ensures that all the routers have a consistent view of the network.

A

All the routing table entries are continuously synchronized among all the hosts, so that, in this way, virtual machines can talk to the pod and vice versa.

A

uh Our example covers connectivity to openstack, but it's not the only cloud computing platform supported so yeah. That's it uh that's it when it comes to the theory, but now I'm giving the floor to yarik, who will show you how it works in practice.

B

Okay thanks and welcome back, I will now show you a short demo of the integration between a kubernetes cluster and an openstack cluster. I will connect a pod to a network l3 network with virtual machines using a network service mesh and the tags and fabric virtual network controller. So, let's start with our environment.

B

We have a plain empty openstack cluster over here. We view it using the graphical interface horizon and we also have a working kubernetes cluster.

B

With the nsm installation already provisioned and we can see the network service manager and the network service mesh tax and fabric forwarder already registered over here, so we can use it to service network service, meshware applications, okay, and we also have the our data plane, which will be the toxin fabric. Virtual network controller and taxon fabric is already connected to the openstack cluster as a neutron plug-in. So it's servicing all the interfaces, all the network interfaces for virtual machines in the cluster.

B

However, it's not configured as a cni for kubernetes, and it's just to show you that you don't need you, you may use it as a cni because it it has the feature, but you don't have to use it as a cni. So you can use a totally different cni in your kubernetes blaster and at the same time, use tf as.

A

B

Networking back-end as a data plane back-end for network service mesh to achieve the connectivity for uh for the multi-cloud architecture. Okay, so right now we don't have any any networking configured in our environment. So, let's start with creating our infrastructure on the openstack side, and I will create two networks: red and blue, to demonstrate the connectivity and to show you that we can use different.

B

We can use different networks and choose them using network service. Mesh requests so we'll create first red subnet with a 10.1.1 addresses.

B

And then a blue.

B

Network with a subnet of 10.2.2.0.

B

Okay and with both networks configured, we can see that tungsten fabric is synchronized with the openstack cluster and it already shows the networks with proper, proper configuration and let's go ahead and create.

B

Two virtual machines in the red network: this will be our first experiment.

B

Okay, we are choosing the red network, so we want uh the virtual machines to be attached to the red network. Okay, they are running and and on the tanks and fabric side we should see them.

B

The interface is attached to the virtual router okay here and we can see the two interfaces in the red network, 1.3 and 1.4, and just for the sake of this presentation, just and just for the purpose of this presentation, we will use uh the router internal interface to connect to them so ssh.

B

Okay, go cubs go and we are in, and we can see that we are on the first virtual machine 1.3 and from here we can ssh to.

B

B

Okay- and this is 1.4 virtual machine and going back there's a two-way connectivity, so I did it just to check if everything's working, okay and it's obvious- that the openstack virtual machines in the same network can communicate with each other okay. So now it's time for the network service mesh pod, I will use pod manifests that are located over here and they are adapted from the official network service mesh examples.

B

And here you can see uh a pod uh with a busy box container inside the deployment with an annotation network service, mesh io and the what's called the fully qualified name of the network inside the tanks and fabric database. So we have a default domain, the project name, which is admin and then the network name. So let's create this part. This deployment apply red deployment, okay,.

B

Now, let's see what's happening inside our namespace, the red part is initializing and you can see that there is something unexpected going over here, because uh we see that it's running some in it containers, while our original deployment has got just only a single main container- and I will explain this in a minute- but for now it's already running so we can see what's inside.

B

B

Okay and we can see that we have two interfaces. First, one is the default uh pod network cluster pod network. This is the default interface and then we have um interface with a random name, which is a member of the red network, and we can see if we are able to connect to the virtual machines in openstack. And yes, both three and four are reachable from our pod.

B

So the tanks and fabric forwarder successfully uh bridged us to the uh onto the red network on openstack, okay and now, let's explain how it all happened. As you can see here, we have a network service mesh admission, webhook pod over here and it's uh and it's a piece of an sam that is listening to all the objects that are onboarded into the namespace.

B

And if it detects a network service mesh annotation, it will modify the pod the manifest and it will add sidecar containers that will configure the appropriate interface and it will. They will handle a communication with the nsm api. So, let's see how the modified specification of the of the red part looks like.

B

Okay, so we have the the container the base container that we we've seen inside the original manifest, and then we have additional nsm monitor container and then the important part in it. Containers dns in it container and the nsm init container and the nsm in it is responsible for talking to the network service, mesh api and creating the interface. According to this uh network service request- and in our case, the network service is the network itself, so we are requesting connectivity and we are requesting to be joined to this particular tungsten fabric network.

B

uh Okay, so you can see that there is a pretty nice separation of concerns in the application manifest. The the application is just this part like it's a regular application. That is totally unaware of any nsm machinery right and while using the deployment while creating the deployment, we are adding a network service mesh annotation that tells the orchestrator to connect us to some specific network. So we have.

B

We have nice layer, nice layers, so we have the application running on a cluster that is equipped with nsm and by modifying metadata of the application we are making it a part of some network environments. So I think that this is a really nice way, a really nice cloud-native way of specifying which network connectivity our applications should receive on the target deployment.

B

Okay, and to see that uh the tanks and fabric forwarder is flexible. I will now create a second third instance in the blue network, a blue demo network with the same configuration except for the network.

B

It's creating, let's wait for it.

B

And the tax on fabric interface, we can see.

B

Okay and create.

B

B

Okay, this is going through the same sequence that the red part.

B

Okay, it's finished and.

B

Let's go inside.

B

And see that we have 10.2.2.4 interface, so we are inside the blue network and we can in the same way see the interface in a blue network on the tanks and fabric site.

B

Okay. So this is it. For this part, we created the taxon fabric for warder as a poc, so it has the basic functionality of creating interfaces and hooking them up to the v router and there's much more to do. But I think that uh it's a nice way to first show you how the uh how the tyson fabric is a nice fit to the network service mesh and its philosophy of cloud native network connectivity and one of the one of the nice appealing.

B

Features of tanks and fabric is also that it is able to connect different workloads into service chains.

B

So, for example, uh cloud native network functions running spots and kubernetes, with virtual network functions, running as instances on openstack, for example, and physical network functions and physical appliances, because it is able to bridge them to overlay networks with switches that are vxlan capable, and the second part is that our source code may serve as a as an example for for other forwarders and for other people that want to customize the network service mesh and add their own functionality or at their own data, plane support.

B

So you can go ahead and see the code in our repo, and I also would like to mention that this idea was inspired by radoslav's talk as the open networking summit europe last year when he talked about his kernel forwarder, which was also meant as a similar thing, to inspire other people to write their own plugins for the network service mesh. Okay. I hope that you liked our idea and our talk, and it's now a time for the qa part thanks.