Cloud Native Computing Foundation ServiceMeshCon 2019 (San Diego), 17 Dec 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk - Connecting and Migrating Heterogeneous Applications with Consul Servi... Luke Kysow

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Lightning Talk - Connecting and Migrating Heterogeneous Applications with Consul Service Mesh - Luke Kysow, HashiCorp

Without question, systems are moving to a highly decoupled distributed approach running on modern schedulers like Kubernetes. There are two challenges which practitioners are often faced with while on this journey. How do you migrate legacy applications safely and without interruption to the new world? Once you have migrated, how do you ensure the connectivity and security of applications, potentially running in multiple Kubernetes clusters?
This talk takes a demo driven approach to how the service mesh can solve both of these problems. You will learn how Consul Service Mesh can help to seamlessly and safely migrate an application from Virtual Machines to Kubernetes. Also, how Consul Service Mesh can help connect and secure heterogeneous applications running in multiple Kubernetes clusters.

A

All right so hi everyone, my name, is Luke ISIL and I'm. The only thing between you and lunch so today we're gonna talk about migrating, an application from VMs over to kubernetes, using console Service mesh and, like I, said my name's Luke and I'm an engineer on the console team. So what exactly is console?

A

So it's a tool from Hoshi Corp, it's been around for a little while, and actually you came out probably before service meshes were a big thing, but it's always been focused on registering services knowing where they are and knowing what their IP addresses are, and so before service match came out, people started to kind of build their own homegrown service meshes on top of console, so I, my old company.

A

We actually use something we use console template, we use nginx, we built their own homegrown service mesh, like Cordy 1.0, actually used hunk console for its service registry, and so, as we saw the rise of kubernetes as I saw how a service meshes have become more and more important. We decide to build our own, so the three things that I'm gonna talk about today. The three features a console service mesh are one that is secured by default.

A

So all the traffic between all your pots is going to be M TLS encrypted and to end and we're using spiffy identities. The other thing that we're gonna talk about here is multi-platform, so Hoshi Corpse always been about multi cloud multi-platform and a console service mesh is no different. So what we're gonna do today is actually connect. Our cube cluster to our VMs and what we're gonna do is we're.

A

Gonna need layer, 7, traffic management to do the migration that we're gonna run through and so we'll show the config that exists in console connect, so I'm Canadian. So in an effort to kind of relate to I'm, Mary American friends here we're gonna migrate, the charger service from the San Diego data center running on a set of VMs over to our IKS data center running in Los Angeles. And what we're seeing here is the NFL service is calling the charger service and we don't want any downtime during this migration.

A

So this is the what its gonna look like before we migrate, and this is what its gonna look like after we migrate. So here's the steps. The first step is we're going to deploy the charger service to both data centers, but we're not going to route any traffic to this charger service running in IKS, because we want to test out that it's actually working as we expect. So what we're gonna do.

A

Gonna set up some l7 rules that allow us to target when a request comes with a specific header: okay, let's route to the azure, kubernetes cluster and not route over two VMs, but most of the production traffic will continue to route over to the charger service running in VMs, then we're gonna split things: 50/50, we're gonna mirror some traffic over there, so it's not mirroring is just 50/50 splitting and then we're gonna route 100 of the traffic over and the migration will be complete, so I think what I might be interesting here is like okay.

A

Well, we have our kubernetes cluster running in IKS and we have our VMs running. They're gonna be running at GCP. How does the networking all work I'm gonna, get into that after the demo.

A

All right so here we have our console UI. So we have our VMs data center, which is running our Chargers service and it's proxy, and then we have our Azure data center, which is running the NFL service.

A

So what I'm gonna do is I'm gonna go back over to the VMS data center. Here I'm gonna go into GCP, where I'm running my VM and I'm gonna ssh in there just to show you that actually something is running there and this isn't all smoke and mirrors. So we're gonna copy that g-cloud command, bring it over to our terminal and ssh in there.

A

So we're using system D to run our charger service over on the VM. So let's show a little units there and it's running on port 8000. So when I curl localhost 8,000 US we get from the Chargers service, so it says: go San, Diego Chargers, so super simple HTTP service and you notice this running on HTTP, not TLS, all right! So now, if we go back over to the console UI and we switch over to our asher data center, we'll see we're running the NFL service. So there's our aks cluster running.

A

If we go over to the coop dashboard, we look at the workloads we'll see we have console running. We have this NFL service running. So let's click through the replica sets to get the pod here and I just want to note a couple annotations we have here. So one is the annotation that every service match has, which is this connect inject annotation.

A

So this is telling us whether we automatically inject the sidecar or not, and another annotation here which unique to console is we're actually annotating which service our upstream is so that in this case chargers and which port the proxy is gonna. Listen on for routing to that service. In this case one two, three four, which means: if we're in the container, we run curl one to localhost one, two, three four and we're out so here: I'm copying the pot ID from the coop UI and finding out as a trailing new line.

A

Then I'm scrambling through my bass, completion and then using another copy to actually exact it into the pod properly. So when we get in there, we're just gonna run curl localhost. One two three four and that request is going all the way out of aks all the way over to GCP, and we get our expected response, go San, Diego Chargers, so everything looks good over there.

A

So now, what we want to do is this first step in the migration which it's just to deploy our Chargers service into IKS.

A

Before we do that, though, we need to set up some l7 configs, so by default, console is going to prefer routing to the exact same data center you're in so if we deploy the Chargers service over into IKS immediately, all the traffic would route to it, which is not what we want, because we want to make sure that it's actually working over there. So what we're gonna do here is we're gonna, create a service resolve our config.

A

This is gonna target the charger service running in over VMs cluster and we're gonna, give it a new name, an alias it's gonna, be Chargers of VMs, and that will allow us to actually target that VM service. So you see here that the name is charges VMs and that we're using this redirect config here that says: ok route over to Chargers running into VMs. We're gonna write the identical service resolver config, so we can target the azure charger service. Specifically now don't freak out. This is in the amyl.

A

Okay, it's HDL, but it's the same thing. So we're gonna write this config over here and then we're gonna set up our splitter. So we make sure we wrote a hundred percent of the traffic to VMs so that when we deploy our service over into kubernetes, we're not going to get any traffic routing to it. Unexpectedly, we want to test that it's actually working and running as we expect in kubernetes. So we're gonna write that config their console, config write service, splitter.

A

All right so before we deploy we're gonna set up a curl running in a loop just so we can be sure that the traffic isn't isn't doing anything weird see here. We are we're running and we're just grabbing for that body there. So we only get that part of the response so now we're ready to deploy our service and kubernetes it's a normal deployment.

A

The only difference is that we have this annotation here which says to inject our sidecar and we're changing the message, because now we're running in the LA datacenter so is gonna, be going la chargers that way we'll be able to tell which one we're routing to so. Let's run QT I applied a chef and deploy that service into kubernetes.

A

When we list the pods will see that how she has two containers, that's because we're adding our sidecar as expected- and it says still the small- keep seal to get pod grab charger. We see it's got zero, no two containers and we do it again and we'll see it's fully up and running. But when we switch back over to our terminal here, we'll see that nothing's changed. We're still writing to our VM service or l7 config.

A

There works as expected all right, so we got Chargers running kubernetes, let's actually route to it and see if it's actually working as expected. So we're gonna create a new config here and we're gonna target the charger service, and when we see a header, that's X data center and the value is a sure, we're gonna route to our Chargers azure service. Remember, that's the one running an AAS cluster! So let's write this config console, config, right and I. Think I called it service router, alright!

A

So now we're gonna open up a new terminal window and we're gonna curl with that header, so open up a new terminal window. We're gonna find the NFL pod again we're gonna keep CTL exact into the NFL pod and then we're gonna run curl H, X, datacenter, coal and Azure. So we're gonna add this header here and we should see the response from the AKS for the service running in IKS, which has a different body.

A

And we do, we see, says, go la Chargers, so that's the l7 config working. You can imagine running this for a while testing us out with different headers running some canary traffic through it. But unlike Sven was saying Google we gotta go slow, slow, slow. We have 10 minutes left in this lightning talk, so we're gonna go fast. So a 50% of our traffic sounds about right for our first step: migration after testing it for two seconds, so 50% of our traffic is going to go over here to our service.

A

We're gonna apply this splitter and immediately. My connection is gonna drop, so we're gonna to restart that curl over there as I wait. Okay! Let's do that again. We get back in there we'll see that 50% of our traffic is randomly load balancing between the charge of service and LA Chargers in VMs. So that looks good I've looked at about 10 responses and that's enough for me. So we're gonna route, a Haunter percent traffic now to our service running in kubernetes, so we're gonna change that to 100 not to zero.

A

We're gonna round console config, write service splitter and we should see all of our traffic now routing to the la charger service and our migration is complete and it took six minutes.

A

So how did that all work that was kind of cool like when the charger service was running in a chaos? It was like: okay, cool you're routing between two pots of kubernetes. That's not that interesting, but when I was running in IKS, everyone is running all the way in VMs like what was going on there, that was kind of a little bit magic.

A

So what we did was we deployed a console server cluster in our VMs and then we used our console helm chart to deploy our console server cluster in kubernetes and we federated the two of them so now they're talking to each other. They know about which services exist. Where then we deploy our mesh gateways at the edge, so in the VMS. This is another binary.

A

You just need console and evolve and in the in kubernetes you just use the helm chart, and so these mesh gateways are gonna, be using an old load balancer, and so they actually have public ip's because we need to route across the Internet. That's dangerous, we'll get into that later.

A

So we add our sidecars, everyone left side, cars, and so the request path here is the NFL service hits localhost one two three four: that's gonna go through the Envoy sidecar, that's gonna get TLS encrypted with its spiffy identity, the routes to the mesh gateway in the AKS cluster out over the public Internet.

A

That's okay, though it's TLS encrypted into our mesh gate, we're running our VMs over into the sidecar running on the VMS and into the charter service, and you see here it's unencrypted, so that's just getting it over a puree, CH t TP cool, so that was kind of cool. We just did a migration from VMs all the way over into kubernetes. You could imagine that you're, probably not going to be migrating everything we're gonna, be kind of in a multi-platform world for a long time.

A

So it's really useful to be able to route between things and use the same service mesh we'd like to use in kubernetes across all of our other platforms. Okay, but what about kubernetes, secure, Bernese? Well, unfortunately, I don't have time to show you that, because we're about to have lunch but suffice to say it's as simple as switching your coop config to your second context.

A

For instance, if you were migrating the charger service to London and you run helm install and you get up and running in kubernetes all right, so, like I said, is lightning talk. We didn't have a lot to cover, so a thumps did some things that are worth talking to me about, or maybe you come to the booth and talk with us about you can install with helm and obviously there's a ton of different options. There are lots of different ways. You can configure things.

A

We didn't talk about our integration with different observer abilities, so Prometheus and data Dog. You can send your envoy metrics over there. We also didn't talk about intentions, so how was the NFL service even allowed to talk to the charger service? So that's a kind of like network policy. We use service identity to allow the requests to go over there, and also we didn't talk about how we can integrate with external certificate authorities, so the TLS you saw there was all done using console.

A

It's super cool like three-day certs, we do cross signing a rotation for you, but if you want to use an external certificate authority, you can use vault we're assuming their release an integration with AWS PCA, so lots of stuff to cover enforce I didn't have time. Please come grab me I'll, be here for the whole coupon. My name is Luke. I saw at ELQ I so want Twitter, and thanks a lot.