Cloud Native Computing Foundation ServiceMeshCon EU 2021, 14 May 2021

Previous Meeting

⏯

youtube image

►

From YouTube: Virtual Machines as First Class Citizens in Service Mesh - Denis Jannot, Solo.io

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Virtual Machines as First Class Citizens in Service Mesh - Denis Jannot, Solo.io

The adoption of containerization is accelerating and running modern applications on Kubernetes became the standard. But what about the legacy applications that can't be deployed on Kubernetes ? Service Mesh seems to be the bridge that everyone wanted to unify these 2 worlds. You can now (somewhat) easily add Virtual Machines (and even Bare Metal servers) into your Mesh. In this talk, I'm going to show how to do that on Istio and speak about the different challenges someone needs to keep in mind: - how to automate the process (from the creation of Service Accounts on Kubernetes to the deployment of the prerequisites in the VMs). - how to add VMs in the Mesh in a multi cluster deployment. - how to allow canary deployments between Pods and VMs I'll also do a demo where I'll show how to automate the testing using Kind and Docker containers (yes, testing the VM integration without a VM !

A

Hi everyone, I hope you enjoyed the service meshcon so far in this talk, we are going to speak about how virtual machines are becoming first-class citizens in service mesh.

A

I am donijano director of feed engineering, emea at solo.io, so at the beginning, everything started with these modernity applications and we've seen the evolution to microservices and obviously kubernetes became the most popular platform to run these micro services.

A

But we ended up with two separate worlds: right on one side, you have some legacy: applications running on bar metal servers or on virtualization platform like vmware and on the other side, the new modern cloud native applications running on kubernetes and then, after that, what we've seen is the service mesh um started to become really popular with this idea that you can have on one side the control plane, where you define all your policies and, on the other side, the data plane where um all these policies are enforced.

A

And when we speak about this policy, we speak about things like um being able to encrypt communication between microservices being able to get some telemetry information and all these things being becoming possible because of this sidecar proxy.

A

That is running on each pod in most of the cases on most of the service mesh out there and that they are based on envoy and basically you don't need to do anything at the application level, but instead um you use the service mesh to provide all these capabilities like uh encryption, telemetry else check and and so on, um and what's very interesting is that it's um it's about to unify um these two worlds. uh What I mean by that is that you have uh the virtualization.

A

um You know the legacy application running on on vmware or bar metal.

A

That can now be part of the mesh and that's very interesting, because it means that I can now have like communication between the legacy, application and the modern applications being encrypted.

A

I can you know, do like some kind of uh canary deployment, for example, um we we will see that just here you can have like the same application running on the legacy environment and on uh kubernetes, and you want to seamlessly migrate from, like you know, from from vmware to uh kubernetes this application that becomes possible, because that's one of the nice thing you can do with service mesh, you can do some kind of you know canary deployment, some kind of traffic shift say.

A

Okay at the beginning, I start by having all my requests for this application are sent to this legacy environment, but slowly I start to send like 25 25 percent of the request um to uh the same application running on kubernetes, and I can check that everything works well and, and then, when um I see that everything is fine, I can migrate completely the application. So I can now do this migration from legacy environment to kubernetes or to containers without any downtime.

A

I can also get some extra benefits for my legacy application, even if I want to keep them running in their current platform, I can still you know, get the encryption like. I said before, but I can also get some telemetry information and and other benefits that uh I generally get with uh with the service mesh.

A

There are different uh service mesh technology uh available, but here we'll focus on histo.

A

If you look at the cncf survey that has been done last year, we can see that estio is definitely the most popular service mesh out there, and uh I would say that uh it will be interesting to see the the results in uh 2021 and I'm pretty sure it's um even you know bigger now, so we are really going to focus on on istio in this talk and also so one of the reason is because uh it's definitely the most popular one, but also the other reason is that it now has a really good support for um vms and environmental servers.

A

So, let's jump directly in the demo and uh and show you uh how all these things are. Are you know done, and uh especially what we will do in the demo is that I will use this uh environment where you see I'm running multiple cubans clusters, using uh kind and on this different cubes cluster.

A

I have deployed like istio and two of them, and I've deployed blue machine in the third one I'll speak about chromage very quickly later on and uh what's interesting here, that I will show you that you can test this vm integration using a docker container as well, and it makes your life a lot easier um if you want to put in place like automated tested and so and so on, like it's, it's very convenient to be able to simulate this vm um as a as a container, so I'll I'll uh I'll show you how we uh we start from uh from a docker container, and we we put in place all the pre-quizzes to to join the mesh, and uh I won't go through all the details, because, uh obviously you can you know you can find them in the list.

A

Your documentation, if you go to virtual machine installation, uh you'll, see a lot of the things that we will do in the demo are described there. The difference is that, um instead of running this command in the vm, I will run them in a container and- and I will have to to adjust a few things just to to make it uh to make it work, but uh but the the baseline for the demo um is uh is here so, um let's jump in the demo environment. So I have like four windows here.

A

You can see one where I will prepare everything for the for the vm and then um what we will do is that uh we will start with a an environment where, um as I said, you know, we have two cubans clusters here and uh I've deployed uh the booking for application on both clusters and we are going to start with this situation where, when I send a request on cluster one and I try to um to go to the the product page, then um you know the product page uh is uh going to send requests to the different services and we will play with this detailed service right.

A

So we will have like uh at the beginning. We will try to have like uh the the product page uh running uh the details, sorry running in the vm and that's why? Where we will start, we will deploy all the prequels so that the vm becomes part of the mesh, and we have like the product page going to the detail service running here and then later we will um show how we can migrate seamlessly like to kubernetes, so migration migrating this app from the vm to kubernetes.

A

uh Slowly, you know like uh taking a canary approach and then at the end I even show you like how you can have like uh requests going. Some requests going to the vm, some requests going to the pod locally and some even other requests going another cluster, and that is, you know, made uh very easy with uh with blue mesh.

A

So let's, uh let's jump into the demo now and uh as you can see here, uh I have like uh my book booking for application running, but uh the details, which is this part of of the demo of the of the page here uh we will make it run in uh in a vm.

A

So to do that uh I'll, just jump here and you see I will call my vm vm1. I will use the namespace virtual machines. I will create a service icon for this vm and- and I specify which network I am on, which is the network uh of the the vm like network. One is the network corresponding to my first cluster, and the vm network uh is uh the network of my vm. That means that I will use gateways to communicate with uh with the clusters.

A

So I just like to copy and paste here then uh I'll create a working directory where I will create all the files that needs to be transferred to the vm, which in my case, would be like a docker container.

A

I will create a namespace for this vm and service account, so the service account that will be used to generate a certificate for this. Vm is also residing on kubernetes, and then you have this notion of like a workload group that you can use if you want to dynamically register vms. But here we are just going to create this dml and we will use this yaml as an input for the istioctl command line. That will prepare all the files that that we need for configuring the vm.

A

So I'm just going to run this command here, and it's here what's interesting is that we can take a look at what has been generated for us and you see um we have like a short living token, so that's kind of a way for the vm to identify itself uh that to prove it to prove that uh it has access to this service account and it will be used to be able to get the certificate from the studio, control, plane and then later on.

A

The certificate will be rotated and every time the vm will identify itself with this certificate, not with the token anymore. We have also some you know information. You can uh take a look at uh what what you have here, but uh I won't go and cover everything. As I said, it's mostly documented, but you can see information about the networks and you know the name of the vm and trust domain and so on.

A

um So then, now I'm going to start docker container. That will be. We will consider as my vm and you see here. What I do is that I use the image the docker image of the details service, so that will be the baseline. It will be easier for me to run the detailed service, because that's already what this image provides, so I'm going to just run this uh image and again you can consider it as a vm. It's not part of the kubernetes cluster. It's running as a docker container like kine is doing so.

A

If I do docker ps, you can see. I have kind my three kind clusters- and uh I have my vm here so now. I have my vm as a container I'm going to just deploy some pre-quizzes that are needed for deploying hto um this your agent and I'm going also to prepare the os file that I will need so that the vm knows how to contact the control plane. So that's the ip of my gateway to reach stod.

A

Then here I'm going to just you see like transfer the different files that I got when I run this command line here. So just you see just doing like docker exec to copy some of the files. When I created you see when I I started my my container, I just mapped this directory here, so I can just like copy internally, then I'm going to deploy the hto sidecar proxy here.

A

So it will be running directly in my in my container and again copying a few other files that I had before uh copying the host file that contains this entry and changing some permissions on directories and at that point in time there is one one special tweak.

A

So the way it works in in a recent version of istio is that you have um a dns proxy running uh within these two agents and there is a iptables rule that redirect all the dns requests to this proxy so that uh it knows about the ip of the different uh you know, pods or in in our case, will be like the gateway and so on. But by default the dns server is this one, which is kind of a local ip as well, and that that prevents this ip table to work properly.

A

So I'm just going to change the reserve.conf of this container so that it's just used like the google dns and the ip tables rules will will work properly.

A

um Finally, I'm going to start istio agent in this uh in this container. So now I have like uh my container that uh you can consider as the vm and uh if everything works well and I I look at the clusters entries here, I should see information for how to reach my services running in the cluster like, for example, if I want to reach the product page- and you see here- I see the if I want to use the product page.

A

This is the ip and this is the port and as you can see, this is the same as you can see here, because I use the history ingress gateway, because my vm is in a different network.

A

We can also check that we can access the product page from the details, which is not really what we we want to do right, download the details, but here is just to show you that the communication from uh the the the vm to uh the the services running in kubernetes is fine, and you see I have a 200 okay and everything is secure by the way I didn't sell it, but everything is secured with mcls.

A

If I would go to cluster or one um and the istio system namespace, I would you could see that there is a peer authentication that has been created here which uh enforced uh strict mtls. So here we will show that we can get like street mtls and encryption between the vm and the pod when it's the vm that initiate the connection and we we are able to reach the services that are running in kubernetes.

A

Now we are going to start the details service in this vm and we are going to create a service and a workload entry so that the pods that are running on kubernetes. They know how to reach the detailed service that is now running in my vm, and you see here.

A

The most important part is here: you see the vmip, which is basically the ip of my docker container, and I can show you that here so we need so it needs to know. You know that this is running here, so I'm going to just create the service and the service entry.

A

And finally, uh what I want- and this is where we start to use blue mesh- we are going to use like a traffic policy.

A

uh It makes our life easier, because I could do that directly with this to create a virtual service, and you know, destination rules and so on, but uh blue mesh makes that uh easier for me to do so. So I create what we call traffic policy, where I say whenever request coming from the default namespace and going to um the cluster going to the detailed service on cluster one.

A

What I want is that I want to send this request to the vm instead, so the product page will send the the request to the detailed service on the vm, because the product page is relating on on this link space.

A

So I'm just going to create this policy here and what I want to do as well is that I want to see uh if I do like a tail minus f. I want to take a look at the access logs here.

A

So I can see the access logs in the different places. So here is the the details spot on cluster one, the details on cluster two and the detail is problem. uh The detail is vm so because of the rule I created here, I should expect now the access locks to change here right on this place, so I'm going to just first of all, try and see if everything works well here.

A

I can still see my details and uh you should see here so that's good. It's going to the vm, that's easy. I can also even go to kelly and I can see that uh it's going, uh you'll see the rating and you see the vm right. So you see the product page is sending traffic to my vm, and I can also even go to bluemesh and see that I have my current policy which says when I have workloads here in the detail in the default namespace that send request to the detailed service.

A

Then everything goes to the vm, so that's the the current state. Now let's say I want to start to send some traffic to the details running on cluster one so that I can start to seamlessly migrate from my legacy environment to my container. So then I would do something like that. You see I say I. I update my traffic policy and the the difference here that you see. I. I only send 75 percent of the request to to the vm, because I start to send 25 percent to the service running on the cluster.

A

So I'm going to update that- and here again now I should see some of the requests going here and some of the requests going there right. So I can go back here. You can refresh, and uh you should see here very quickly, um some access logs uh showing me that you see here and here the requests are going now.

A

They are spread across these two clusters and uh in kelly I can also see that you see it sends some of the requests on the same cluster and the details and some of the requests in in the vm right and and again, if I go to blue mesh, I see that as well.

A

Right, 75 percent are configured to go to the vm and 25 percent and go to the details on cluster one and now what's uh quite nice is that I can also you know even like refresh all the stuff here and I can create a nice policy. First of all, like I can say, uh I want now to go and switch completely to uh kubernetes so that now all the requests will go only here in the clusters.

A

They are not going in the legacy environment any any anymore and again I can just like refresh that here and I should be able to see my access logs uh moving just there, so just proving that uh yeah everything goes on the on the right place like I was expecting. The migration is done now from my legacy environment to kubernetes. I can see that here as well.

A

All the requests go now to the details here they are not going to the vm anymore and I can um show you like a a small bonus that uh and that's also another very nice things you get with blue mesh is that it makes your life a lot easier. When you want to do like uh you know, cross cluster communication. I could have done like uh um an example where I would configure a failover if I cannot switch locally. I go to the other cluster, um but here just to make it simpler.

A

What I did is that I create a traffic policy where I would say fifty percent go to the vm and twenty five percent go to uh cluster one and twenty five percent go to cluster two. So now I spread my request not only between my vms and my pods on cluster 1, but I can spread my requests between my vm, my port and booster, one, my portal, cluster 2 and everything as you can see very easily by you know, just creating like a traffic policy like that. So I just go there.

A

I apply this and now I can refresh my app like click many times here um again I can see the spread is down here and you can see the logs moving everywhere and you can see you know. uh Caddy will also show you like a nice uh picture where um you, you will see um all the requests going.

A

You know across all these different uh environments and and even like, uh depending on how long we wait for the for the matrix, but we will also see uh even like uh the the matrix showing that uh this is going through. You know all the clusters, and normally you should have like a cluster two uh box uh displayed somewhere here.

A

um It's just that it's not showing right now, so let me refresh a little bit more and we we should see like the details here. The the details running in the vm, but uh also the the details uh from the uh from the other cluster, like you see here it just like, took a bit of time to refresh, but you see now. I also see like the request going to the other cluster and that's possible because we consolidate all the matrix with blue mesh uh as well and we can present them today.

A

You consume them the way you want like in kelly, but tomorrow it will be even like integrated in the in the in the blue mesh ui. So, as I said, you know, I I use blue mesh in uh in the in the demo to make my life easier for managing the traffic, but you can also use it like for discovery, so I discover all the workflows on all the clusters instead of having each cluster discovering the workloads on all the other clusters.

A

This discovery is done by blue mesh, it's more secure and it just like make the other clusters. Aware of that. You have the failover I spoke about before you have the ability to have like um consolidation of the matrix, like I said, but also being able to do that with the access logs and being able to um have like a global airbag, where you can define who can do what across all these different clusters, uh we have like a very nice support of web assembly there as well.

A

So if you are interested, you know you can go on our website and or on our slack channel, and you can you can ping us. So thank you very much for attending this session. I I hope it was uh useful and- and I think we we now have some some time for q, a.