Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2020 - Virtual, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Tutorial: Migration 101: From VMs to Kubernetes - Luke Kysow, HashiCorp

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.

Tutorial: Migration 101: From VMs to Kubernetes - Luke Kysow, HashiCorp

In this hands-on tutorial, you will learn how to progressively adopt Kubernetes by migrating one of your apps from VMs onto Kubernetes. You will perform the full migration process: from preparing your app for running in Kubernetes, to configuring routing, to performing a no-downtime migration and monitoring your app. We will cover: - Dockerizing your app - Creating a Kubernetes YAML spec - Deployments - Configuring routing between K8s and VMs and discussing different topologies including using Consul - Performing a no-downtime migration from VMs to K8s - Viewing application logs with Fluentd, Elasticsearch and Kibana - Viewing application metrics with Prometheus and Grafana - Managing your hybrid environment This will be a completely hands-on tutorial. Pre-requisites: Docker

https://sched.co/ekFi

A

All right, everyone uh welcome to the talk. So today uh we're gonna talk about migrating vms to kubernetes. uh My name is luke kaiso, I'm an engineer at hashicorp and I work on console and our kubernetes integration.

B

Hi everyone, my name, is irina shistava. I also work as an engineer at hashicorp working on our console. Kubernetes integration.

A

Yeah, so uh let's just uh share screen here and I'm going to get into the slides and we can intro the talk here. So um I'm going to present here so yeah. This talk today is migration 101 from vms to kubernetes.

A

So what we're going to do in today's talk is we're going to have our two applications over here we're going to have the web application and the iepi application and they're both going to be running on vms and then what we're going to do is we're going to deploy the api application onto kubernetes. So we're going to go through everything. You need to know about how to get these applications from what it would be like to deploy on a vm to deploy onto kubernetes and then what we're.

B

A

Is we're going to deal with the routing so that the web can actually route to api and we're going to swap the routing over in a no downtime migration so that the api service is now running on kubernetes? So that's.

B

A

The overview of the whole talk, that's our goal. So uh to get there.

B

A

We're gonna start with like an introduction, uh a little bit of the setup and how we're gonna do everything and the interesting thing about our workshop here is we're actually going to be able to run everything uh on our laptops.

A

uh We have a full set of instructions for folks to either follow along, so they can run the commands themselves on their laptops or, if you don't have a laptop that you have access to, uh or it doesn't have enough like a ram or something like that you're having some issues you can just follow along with us, because we're going to be running the same steps at the same time.

A

B

So to get to that.

A

Point where we migrate from vms over to kubernetes what we're going to do is we're going to uh first build a docker image. So in order to deploy anything on kubernetes, you need a docker image, then we're going to actually deploy into kubernetes. So this is going to be talking about like the kubernetes resources, the difference between vms and kubernetes, and also of course, it wouldn't be a kubernetes talk without yaml. So we're going to talk about what your yaml needs to look like once your app is deployed onto kubernetes.

A

Obviously we now need to route to it. So then uh I'm going to be doing the first part here and then we're going to switch over to irena and she's going to be talking about the next parts, and so the first thing she's going to talk about is the routing. So how.

B

Do we actually route from like.

A

On our vms, all the way over into the into kubernetes we're also gonna talk about logging and metrics, um often you're gonna be using your own log in metrics, like whatever systems you had before, you moved to kubernetes, but we wanted to show you some of the cool cloud native tooling that is available out there and how to run it and you'll actually be able to run it on your cluster and play around with it yourself.

A

Once we have all our metrics in place, we're able to know whether our app is working as expected, we're going to perform a no downtime migration um and then, basically, what that means is we're going to have both the app running on vms and.

B

A

And then we're going to swap over in a safe way that allows us to swap back without missing any traffic and then, finally, at the end, uh we're gonna do a quick demo of console service mesh. So we don't recommend, uh depending on on your use case, it doesn't make sense necessarily to go into service mesh and one of the things we actually talk about at the end of the talk is about how, like you, got to keep it simple and don't try to boil the ocean and use all the new cool technology.

A

However, there are some like use cases and problems that the service mesh does solve, and so we're going to give you a quick demo of what that would look like if you did go down that road.

A

So um before we do anything, we want you folks to start getting downloading the prerequisites. If you haven't already so uh this url is going to be available in the chat right now. uh Wherever that chat is um so, I'm gonna switch over and just show you what you need to do to get started and then you can come back to us and we can. We can start with the workshop so we're going to go to this url here and we want to click into the prerequisites here.

A

So what you need is you need docker desktop, so you see here, I have docker running. You need to install kind, which is a kubernetes and docker. That's going to allow us to run kubernetes locally and you need to install cube ctl and help so get started downloading those things. Maybe you want to pause the video until you have them all downloaded.

A

Some of them will take a little bit of time to download, and also one thing worth noting is that you need to have four gigs of memory: 16 gigs of ram and 6 cpu or 60 16 gigs of disk and 6 cpus. So when you get docker running, you can go into preferences here, uh resources and so like uh we say there. So four gigs of memory and six cpus.

A

So six and I have six gigs of memory um and then you don't need this much disk, but uh you do need uh what do I say: 16, gigs of disk um and so that'll make because we're going to be running so many things on your laptop here. uh That'll make it things a lot easier, so uh get started downloading those things, and so I'm going to continue here with uh with the talk.

A

So when we talk about.

B

Like migrating.

A

To kubernetes adopting kubernetes uh there's a there's a couple different ways to do it. One common way to do it is, instead of migrating, an existing application to kubernetes. What we do is we actually we're building a new application and we're going to deploy into kubernetes for the first time.

A

So in this diagram here we have our old web and api applications, and what we're doing is we have a new application coming the food application and we're going to deploy that onto kubernetes and one of the benefits of this patterns, or this pattern is that um foo isn't being called by any production traffic. It's not being used many users, uh it's not dependent on by the web service, and so we can deploy to kubernetes and if it breaks or there's some issues with it. It's not a big deal right. There's no downtime!

A

When you're talking about what we're doing today, which is when we're moving an existing application, that's actually getting full traffic over your kubernetes. You got to be a little bit more careful um once you're deploying this into production. uh You know there's actual legit users going through your web and talking to api right, and so if this breaks you know, there's going to be some trouble, and so that's.

B

A

To be a little bit careful here, we would be doing a no downtime migration. We might want to. You know, build in some even more complicated things around here around like automatically failing over if something breaks um so yeah. That's that's what we're going to cover today, but just note like there's different ways to adopt kubernetes, um often like, if you don't have a new application to coming down the pipeline. This is going to.

A

This is going to be how you adopt kubernetes and even if you are adopting it, this way, eventually you're probably going to want to move some of these applications over into kubernetes and so you'll need to tackle this kind of thing.

A

So, let's get into the initial setup here.

A

So what we want to do is we're actually going to deploy our our services here, the web and api on our local machine, and uh what we're going to do is we're going to have the web service it's going to be running on localhost, oops, logo, host 8080 and then our.

B

A

Service is going to be running on localhost 80 and we're going to be able to access it using this hostname http colon, slash class api and the way we're going to be doing that is etsy hosts. So I know what you're thinking you know. This is supposed to talk about vms and now you're running everything on your macbook, like what the heck I'm getting out of here. Okay, hold.

B

A

A second, so what we're.

B

Going to learn today.

A

A lot of the things we're learning: we can teach them in this environment here which allows us to play around a lot easier. We don't have to get you to spin up vms and spin up a brand new kubernetes cluster and start paying cloud providers for it. And so, if we look at what vms look like, you can kind of see that they're actually quite similar to the setup here and basically we can. We can mimic almost everything on our laptops here.

A

So if we look at what a normal vm setup looks like we're, gonna have something like this: where we have a set of vms and the web service would be deployed to maybe three of them and the api service would deploy to another three of them and then we're gonna have a load balancer somewhere out on the internet, that our users come into and the load balancer is gonna. The request is gonna come and it's gonna have to find a way to split them between, like three different web service vms right.

A

So maybe you do something you have like a dns entry and then each vm here.

B

Has an ip address.

A

That gets added to this dns entry and so you're, doing kind of like splitting, based on dns they're around dns and the same thing for like the web service. That needs to talk to its own api service. uh You might have a dns entry for like api and then these vms have their ip.

B

A

Registered and so you're calling over here like this, and so this is very similar to what we set up over here, where we have our browser coming instead of load balancer and it's coming directly into this web uh via localhost 880.

A

But you know, there's not a big difference there with that, and then api we're using a hostname here api, but it's not dns, there's no dns behind it, but behind the scenes we're actually using etsy hosts, but that's basically just mimicking dns and again because we're running on the same laptop, we do need to use different ports, but that's not a big difference between these two setups here. So take our word for it.

A

We're still going to learn a lot today with the how to do the vms and you're going to be able to do it all locally on your laptop, which I think is really really nice.

A

So, speaking of on your laptop, uh like I said uh you can do all this on your on your own too or you can follow along with us or kind of do the same thing at the same time as of right now, this workshop only works on mac, but uh depending on what we're saying in the chat right right now, when you're, when you're, actually watching this at kubecon, we may have got it working on windows too, so just check the chat there and see if it works.

A

So what we're going to do here is hopefully you've got all the prerequisites set up, and so we're going to go to this first step here. uh If you, if you're coming from the root of the repo just go to click, one dash, setup, okay, cool! So in this in this uh step here the setup step we're going to start the web and api services running on our laptops and then we're going to let the web servers talk to the api service, so hopefully you've cloned this vehicle here, and so I have it over here.

A

So that's the repo there and so what it says in one term, it'll start web. So I'm just going to copy this. Okay, we see now we have web running. So if you remember, our diagram web is running on localhost 8080 here. So if I go to host 80.

A

we'll see that we have the web service running, it returns web here, but- and it's upstream calls it's dependencies- it's saying like hey. I can't talk to api service. Well, we haven't even started it yet. So we kind of expect this not to work so like.

B

A

That's what you should be.

B

Getting so then we're going to go over here and.

A

Start the api service, so I'm going to open up a new terminal tab here and I'm going to start the api service. Now here, I'm using sudo! That's because api is binding to port 80, so I'll type, my password in there, which is a hundred two um and so now this is up and running here it's running on a localhost 80.. So, let's see if the web service can now talk to its api service, ah so there's still something wrong. So.

B

The issue here.

A

Is that this api, this hostname, it doesn't exist right, um there's no website out there that says api, and so what I need to do is actually need to kind of hack dns by editing my local etsy hosts file and create and create an entry that says hey when you get this api hostname. Actually I want you to route it to localhost, so we have the instructions here like that, um so we need to edit etsy hosts, so I'm going to open up a whole new set of terminals.

A

Here, oh and I gotta make it a little bit bigger for everybody. Okay, so edit etsy hosts again enter my password hunter 2.. Oh my gosh, poorly.

A

Okay and at the end here, I'm gonna go back into my docs here. It says: add this line to the bottom. So let's copy that make sure you don't add it with a comment. So what this says is when someone goes to http api, actually route them to 127, which is just localhost right.

A

So we save that and we go back to our web service. We should now be hitting our api service and I'm going to switch over here. Just click enter a couple times on these logs, so we should see a request coming here.

A

Okay, awesome, so we saw that the response changed here a little bit so here we can see that it's correctly calling it's upstream, which is its dependency and then the name of it is api dash or vm, and obviously indeed this is going to change when we deploy indicates onto kubernetes but everything's working as we expect here and we go over to our logs. We see that you know that's where I pressed enter way up here and now we get like getting requests in here. So what have we just done?

A

Well, when we go back to our diagram here, all we've done is: we've got our browser, it's logos, 8080 is talking the web service, which is then calling the api service, which is exactly what we wanted to do for this stage.

A

B

So, let's go back to our slides here.

A

B

We've got everything set up.

A

For uh for our our migration here and so now, what we want to do is we want to start deploying onto kubernetes, but before we can deploy to kubernetes, we actually need to build a docker image.

A

So this is dockerizing and it's not a real word, but that's what I like to call it when you try to stick your app into a docker image.

A

So if we look at what we had with vms, like I kind of want to motivate why docker right? So we look at what we have with the vms you're, usually running one app per vm.

A

Now, when you run a docker image or a docker container, what this allows you to do is actually allows you to run multiple apps in a single vm. So I mean I'm only showing two here, but you can run literally like 30, pods or they're called pause credits, but you can run like literally 30 containers on on a single vm.

A

If you have a really big van, you can run even more than that, um and so what this allows you to do obviously is have a lot less vms and also what it allows you to do. Is you can treat your vms um like uh there's this cattle versus pets, analogy which I really don't like, um but basically the idea is: if you lose a vm, then it's not a special vm. It can run anything.

A

So all you need to do is bring up another vm of the same type and then you can run any docker containers on it right. So this is kind of like what kubernetes uh it does. It's the whole, it's a whole mechanism of kubernetes, it's a container orchestration, but before we can orchestrate containers, what do we need? We need containers.

A

So what exactly is a container? Well, let's compare it to vms and and and docker so over. Here we have vms and then over here we have docker. So a vm consists of your app, so you know the binary or its dependencies. It's going to have it's it's libraries. So if you're running like a node.js, you're gonna have like a bunch of like javascript files, you know your known modules and then it's operating systems, ubuntu or red hat or whatever you're running, and that's your bm and then under the hood.

A

It's actually sitting on a hypervisor and this eventually there's actual like real server with real cpu underneath. But this is pretty big right and um one of the things with this is that if you wanted to run app a on the same vm at that b, well, what if they're using different versions of node.js, for example, then you're going to run to these issues right, because the apps aren't contained within like the app themselves they're actually like they have they kind of spread out over the whole vm.

A

When we look at a docker container, what we do is we actually contain the app and its uh binaries and libraries within a container. So with is within its own like namespace, it doesn't even know, what's going over here on app a it doesn't know about its files or anything like that. It doesn't even know about this processes or even its network, and so what this allows us to do is because it's now contained it's a container right. This allows us to stick a ton of them all on the same vms.

A

They don't even know about each other until they get cpu throttle, because I was using a lot of cpu, but for the most part you don't really notice it. So that's what we're gonna do in the step. Two here is we're gonna uh package, our application, which is currently running our vm on our laptop into a docker image.

A

So I'm over here in step, two, if you're coming with a route there, just click on step, two dockerize.

A

Okay, so in this step we're gonna build a docker image for the api service because we're only migrating. Let's go back to our premise here: we're only migrating api onto cube, we're going to leave web over here on the vms. We only need to build a docker image for api right now, at least.

A

So. Let's do that. So, in order to build a docker image, you need to write, what's called a docker file, which is literally just like a build script for for your docker image. So the first thing you need to start on is you need to think about? What's your base for this image, so just.

B

A

In order to run your app, you might need to be running on like an operating system like ubudu or something like that uh with docker images. You still need like a base. Now, technically, you could actually start with nothing. So you could just like stick your binary into this image and all that would be there is your. Is your binary but say you want to like run a command in your container, because remember this is like isolated, so you wanted to like, maybe like ls or look at the files there.

A

Well, you don't have ls in your container right. You might not have cd, you might want to like curl something, but you don't have curl in that container. It's not going to work right, so uh there are some a lot of benefits for starting from scratch. It's called where, basically, you have nothing in the image, but your binary, but for this example, where we're kind of messing around with the demo- and I think also for when you're first starting out when you actually might want to run commands inside a container.

A

I recommend, starting out with like a base image with the haslamic utilities and things in it already, in this case we're going to use alpine.

A

This is like a really really lightweight linux distribution um and it contains like a bunch of likes, really small kind of utilities that you'll need, but it's only like five megabytes, so it doesn't really add much to your docker image size. So I'm going to copy that and then what we need to do here is I'm going to do this in my editor, so I'm going to create a new file called dockerfile.

A

I can make this.

B

A little bigger.

A

We're going to copy that first line in there, so let's go back to our instructions here.

A

So now that you have your base image, you got to think about something specific to your application right, so a good place to start to know what you need to put in your docker image is just look at the startup script for the thing you're you're actually uh dockerizing. So in this case our startup script here is a start api darwin, and if we look at it, it's that's, like you know, username bath bash.

A

It says uh these like bash like uh command, so that, like the command wax, if it fails, so we don't really need that and then it exports two environment variables and then it runs our binary, which is like the api service.

A

So if we first start with these export instructions, well in a docker file, you can basically do the same thing using the m command. So what we're going to do is we're going to copy these into our docker file and we're going to change export to env.

A

Now, let's closely look at these, uh in this case, we're actually going to change this from vm to case because we're going to be pulling this docker image onto kubernetes, and so we we're kind of like we wanted to have a different name. So we know we're hitting it in your case you're not going to want to do that. Obviously, um you're going to want to keep like your app the same and then the second thing.

B

A

This listen address, so if we kept this as 127, what would happen is when we deployed into kubernetes the application, the container wouldn't actually be listening on any, inter any um interfaces network interfaces that you could hit from the outside. You actually have to be in the container to actually curl it.

A

um This is because uh docker containers have like their own networking, so we actually want this to be 0 and this to be zero, so that we're listening outside of us, because we're remember we're trying to route into this container here um most like most most, like most of your apps they're, going to be listing on all interfaces anyways because, like if you're in running in a vm, you would need to be listening on all interfaces, so you wouldn't really have to make this change, but because we're doing this down what we do, okay, the final thing here is this uh binary here, so the first thing we do is you actually need to get this binary into the app?

A

You would probably do this in your build script, where you'd actually be building these binaries up. Now, maybe you have like if it's like a node or python, or something like that. You're gonna have like literally files, so you need copies files from wherever you're building it into the docker image. So we can do it like this, so this dot, slash bin is basically where I'm running my command from so I'm gonna be running it from like uh the root, and you see over here it's a little bit small here, but we have bin.

A

So this is where the app lives. So we want to copy the bin over into slash a app slash api notice, we're using the linux one, not like the darwin or the windows, one. That's because uh we're gonna be running our kubernetes cluster on linux, and so we need like a linux, docker images, but you might notice here like slash app that doesn't exist yet, probably that's not really a well-known directory, so what we can do is we can actually run commands, so we want to run make deer, slash app.

A

um That looks good. The final thing here is: we actually need to execute um a command so.

B

This is basically kind of like you can think of it as like. Just.

A

A single process that we're building here so like what does that process actually execute? Well, obviously, we wanted to run our app. So this is where you set up the entry point here, so we have slash app api and hopefully this should all work. So let's go back to our instructions.

A

This is what your docker file should look like and all you need to do is run docker build and then the current directory. So I'm going to switch over here to this tab here. So here we see that we have this docker file now, so I should be able to drill a docker build dot.

A

It's going to send the current context of this uh directory over to the docker daemon, and then it's going to run all our commands. So that's really fast, so this might take a little bit longer for you, because you might actually have to be downloading uh alpine, um but you can see here our steps here. So we've got the from alpine. We set up our environment variables.

A

Everything looks good. We built this docker mission, so the very.

B

A

Thing we want to do is we want to run this docker image before we load into kubernetes and get all the way down that road? We can actually run this uh to see if it actually works, so we can go docker on this image and what we want to do is because, on on a mac like docker, is actually running in a vm, it looks like a hypervisor kind of little mini vm, I'm not even sure what the technology they're using nowadays is.

A

um We actually want to publish our our port from our mac over to wherever this container is running whatever magic they have running, so we're just going to use 80 or 888, and then we're going to publish to 80, because remember that's where the docker image is listed.

A

B

A

There's some good news here. um First of all, we have uh uh we, we can see the log, so that means it's working and we should be able to go over here 888. I believe, and we can see cool we're hitting our docker image and it's api dash case. uh This actually has like a nice ui too. I believe not slash you.

A

So we have our api here as well, um but the important thing here is our document is working as expected. So that's that docker build section here. We've done docker run here all right, so we're really close here. We have our docker image build, but it only exists on our laptops. So what we need to do now is in order to run kubernetes or have this run at kubernetes. Kubernetes needs to be able to pull this image from somewhere right. So that's where this docker, the idea of a docker registry comes in.

A

So what we can do is we can tag our image id with like a proper name, and in this case I have I, I have a docker hub registry under elk iso and then I'm going to be able to push this up here now, if you don't have a docker hub registry you're. Actually in luck here, um because we're running kind, which is like kubernetes in docker, we're actually running that on our vm on our on our macbooks right now, there's a way to actually load the image directly into kubernetes.

A

um So it's kind of a little bit cheap here. If we don't actually have a docker hub account, um but for those that do that is definitely a little bit easier to push that image up there. So what I'm going to do first, is I'm going to do this? Where I'm going to tag and push into my docker hub, and then I'm also going to show what you can do with with kind? If you don't have a docker out, so I'm going to control c here, because this is the docker container.

A

We were running all right, so that's all done there. So what I want to do is: oh, I did control okay. What was I okay? This.

B

Is the remember.

A

This image id you need to you need this to be able to tag it so docker tag and then uh docker dot, io, slash, alkaiso or but this will be whatever yours is and then api and then v0.1.0, it's the the 1.0 of the app.

A

uh So I should be able to take that there and this doesn't push it anywhere. It just exists now, if I do docker images, okay, a couple more lines uh you can see here, we've just tagged this image. So now what I'm gonna do is I'm gonna. Do docker push. I'm gonna push this image up.

A

Here, all right, so that's now pushed um and if you folks don't have a docker, uh a docker hub account. What we can do is we can actually uh load this directly into kind. So kind is our kubernetes and docker system. So what we wanna do is we have a script here? That's going to start that up so just run that.

A

Oh so what happened here so we've got this error here, and this binded address is already in use so because of the way we're doing this migration we're actually binding to port 80, with both our our kubernetes cluster and our vm api. So you need to do this kind of funny dance here. We actually need to stop both our web and api services, so ctrl c those start kind again.

A

This will work this time and then we're going to go back over and restart those uh those image, those uh those vm uh processes. So that's I know that's actually.

B

A

So I can start our web and start api here again after typing the password.

A

Go back over here to kind we see the control point here is starting and then, when this comes up, what we're going to do is we're going to load our docker image directly into kind, and you can use any name you want because you're not actually like, like you, you folks, won't be able to push to elk. So because that's like my my registry right, but you could actually tag your docker image like this tag, command will work. You can put anything in here.

A

It's when you push that the authorization comes in there where it says. Oh, you can actually push there, but what we can do is we can actually use this command called um here, this kind load.

A

So what we can do is we can load our docker image directly into kind here. This is going to bypass the docker registry.

A

All right so that's been added. There now awesome so success. We we built a docker image. uh We now have a docker image up under kubernetes yeah and uh now we're ready to kubernetes. So let's just quickly jump back into the slides here.

A

So what we've done so far is we've built this docker image now we're ready to deploy kubernetes and just like.

B

It was dockerizing.

A

Now it's kubernetes, so let's just do a really quick overview of what things are going to look like into kubernetes. We don't have a lot of time with this workshop, so we can't go into like everything about kubernetes but kind of one of the primitive building blocks of kubernetes. Is this idea of a pod?

A

A pod is actually a collection of containers, so you can actually have multiple docker containers running in one pod, but for a lot of the use cases, especially when you're first starting out you're only going to have one docker container running inside that pod, um and it's going to be your app so that one we just built so, for instance, that's what we'll be running in the pod.

A

So these pods can be running on on all of your nodes here um and you can be running like multiple pods on multiple nodes, uh just like we were talking about before that's kind of the benefits of docker containers right, um but you need more than just pods, because the problem with pods is, if I delete this, this node right here that pods gone forever and kubernetes isn't going to automatically restart it. So we need a higher level constant construct. It's going to be something it's going to manage like looking like.

A

Okay, I need three replicas and if one node dies and my replica was on it, then I need you to spin up that replica and schedule it somewhere else, so that higher level construct is called a deployment. So in this case we have deployment here and, for instance, it's managing two web pods.

A

Now, if this node here dies it crashes, the deployment is going to notice that it's running in a loop. It says, oh I'm supposed to have two replicas running. I only have one: I'm gonna try to schedule it somewhere else. It's gonna schedule over here. So those are the two resources like the core resources. We're gonna we're gonna look at next is the deployment and a pod.

A

So let's look over here to step three here.

A

So at the end of this we're gonna have api is gonna, be deployed on kubernetes, so we go back way at the end of this. What we're gonna have is we're gonna have api running over here in kubernetes. We're also gonna. Have it running on vms.

A

So if you haven't already started kind, make sure you do that and make sure you do that little dance with like the ports, so that you have everything running and you can verify it's working by running qtl get node.

A

Okay cool, so it's up and running as expected.

A

So let's first start with a pod. I know we're going to get to replicas next, but I want to talk a little bit about first, so it's a single replica of this of the application. um It has like an api version here that almost every kubernetes resource kind of starts with an api version and a kind. So what kind of resource is it? It has some metadata like a name and then it has a spec and then inside the spec.

A

This is going to be different, depending on which resource um your your your scheduling but everything's going to have this like this first same kind of part here, so the spec for a pod is the list of containers like we talked about in this case. We're only going to have one.

A

We have a name for the container, here's the image so.

B

Whatever image.

A

You had you're pushing previously. This is what you want to have in here, and then we specify the port so in this case we're going to be using 480.. So if I create this file here,.

A

I can then use cubectl apply, so this is takes it into yaml file and it's gonna um apply this to the cluster. It's gonna post it to kubernetes and say hey. This is what I want to exist here. It says pod api created, so I should be able to go cube. Ctl get pods all right. We see this listing here. We have api running, that's pretty awesome!

A

um We can get us logs by running qctl logs api. We see it's running as expected, that's pretty great um and we can also uh port forward to it. uh We're gonna do that in a bit when we get to the deployment, but remember how I was saying, like I think it's paused, it's not enough. So what happens.

B

A

I do qtl delete pod api.

A

I go get pods again, it's gone, there's nothing like managing it. There's nothing restarting it! It's just literally gone. If I were to delete that kind, nobody would never come back up, so we need more in the pods and what we need is that deployment right.

A

So if we look at a deployment file, it's kind of the same thing right. We have our api version and our kind. We got our metadata now we're adding some labels with a little bit different. Then we have our spec and then you know, then the deployment set stuff. The specific is that is that's what comes next so here we can only have one replica. Obviously, you'd want to set this to more in your production clusters, um but in this case we're running locally, so we only want to have one.

A

uh This is a bunch of metadata and then inside here, you'll notice that this this section here looks pretty familiar. If we look that we have here right. So all this is is like saying: okay. Well, what do my pods look like that are being managed under this deployment? So you can, you can see how these concepts are being mapped here. So this is the exact same thing as I had for my pod.

A

So let's create this deployment.yaml file.

A

Paste that in there and then I'm going to refute ctl apply dash f deployment boom. Our deployment is created, so I should be able to go, qctl get and then the get command at this. The third argument here is going to be the resource type, so whatever resource type you've learned about you can use it. Do that uh type it in here. So in this case we're gonna do get deployment.

A

You see, we have our api deployment and it's got one pod available. It says so I should be able to go, get pause or pod. Here we say we have our api pod running, but it's got this kind of crazy, prefix or suffix here. This is because the deployment's actually managing that and it's giving it like a random id here, so we should be able to do qtl logs and get the logs there.

A

That looks good and then the thing we were talking about before what if what, if the this gets deleted. So if you delete.

A

A

Should be deleted here.

A

But when we do I'm going to control c, that is it's hanging, but it's actually deleting in the back end. If we do get plots here, you see like what how I thought it was deleted. Well, if you look at the id, we deleted this tc774.

A

This is a new pod. That's been spun up 12 seconds ago, so the deployment's not watching that it's like, oh, that pod got deleted. ah I gotta have another replica. It brings it back up, okay, so we're running kubernetes. This is awesome. The final thing we want to check is like: can we curl this app right, so we haven't set up the routing?

A

That's what irene is going to do with us next, but there's one way to kind of directly route directly to a pod and not without having like all the routing work from the outside and that's called port forward. So we can do ctl port forward, the pod id and then just like we were doing with docker. We were publishing ports over we're, going to publish our 888 over up into that pod 80.

A

all right. It says it's forwarding over there. So let's see.

A

B

It's working as expected.

A

We're talking to api kate's here um and remember: that's the docker, which we just built, uh and it's got like the body, hello, world and everything so everything's, working just as expected, so go back into our slides here.

A

This is what we've got so far. We have web running, it's talking api on our vm macbook and now we have api.

B

A

Over into kubernetes, we put it into the docker image: we've kubernetized it. We have our yaml and everything, and so, if we look at like what it would look like, if you're doing this in vms, you would have kind of your your setup here. Nothing's changed right, but now you have api deployed into your kubernetes cluster, so obviously you're thinking like okay great now. What how do I actually route requests over to that?

A

And so that's what we're gonna talk about next and I'm gonna swap over to irena who's. Gonna. Take it from here.

B

All right, hey everyone, um so yeah, I'm taking over from luke. Let me go ahead and share my screen.

B

I'm still here, though, thank you, luke for running us through those uh all these steps, uh we're gonna start with routing and just as a reminder as luke has mentioned, you still should have all your vm quote-unquote vm services running on your laptop at this point in time, and you should have your kubernetes deployment running, so I'm just going to make sure just for my own sake that I do have all of that and I'm in the same state as all of you all right. So, um let's, um let's talk about routing.

B

And really, when we're talking about exposing your service externally in vms, what I imagine is having a load balancer and just as we've shown before you look went over this like you can have your uh web uh vms, maybe in some sort of auto scaling group, as you would in aws, and it's all fronted by a load balancer and you can have the same thing with api and so, for example, if your web service needs to reach your api service they'll, like typically, do it through a load balancer.

B

Now, let's talk about how would you expose a service externally in kubernetes and kubernetes? Really? Has this a concept of a service and there's three types of services? The first one is a cluster ip and a cluster ip service is meant to be used only for things that need to talk to each other within the same cluster.

B

Each service gets assigned an ip, but that ip is kind of a virtual ip. It doesn't work outside the cluster. Only kubernetes knows about that ip, it's not resolvable in any way, then there is a node board service, and that would work great.

B

If, for example, you have your nodes that you can reach externally, the one limitation with that is that there's a specific port range which doesn't really work for our case, because we have a service that runs on port 80 and our web service calls the api service on port 80, and if we want to do that, zero downtime migration without restarting our web service, the node port service really will not work for us because we don't want to change anything.

B

We just want the web to automatically switch to the new api service and the last and the third type of service is the load balancer service. That one really depends on your cloud provider. Most cloud providers have load balancer service. It would definitely work for our use case.

B

However, on kind load, balancer service is not supported, and for that reason we're not we're going to use something different called an ingress, and so an ingress is another abstraction in kubernetes and it's really building on top of the surface abstraction and what it allows you to do. Is you can it's mainly for http services? You can expose your http routes externally outside the cluster.

B

The one benefit to ingress over a load. Balancer service is that you can have your ingress have only basically, you can have only a single load, balancer fronting only the ingress controller instead of having a load balancer per service, and that is really great, because if you're trying to save on like say, infrastructure cost for load balancer using an ingress could really be a better option there.

B

So we're going to show you how to use ingress for two reasons is that it may be beneficial for you in the future, but also our infrastructure doesn't happen to support load balancers.

B

So at this point again to recap: we have our web running evms, calling our api in vms on our local machine, and we have an api um deployment, which is just a single pod, with a single replica and we're going to end up with a service, an engine, an nginx ingress that we will be able to reach locally all right and with that, uh let's dive in into workshop step. Four.

B

So right now, you're, probably on step three, I'm going to go ahead and click next to the step four. So the first thing we're going to do. As I said, ingress builds on top of kubernetes service, so we need to create a service first and since I we don't need any other kind of special kind of service, we're just going to use the cluster ip, which is the default type of service, and, as you can see, the weight structure is you have a selector which, in our case, is just using labels?

B

That is how our api deployment is labeled, and that is how kubernetes will pick pods for for the service to front and then we're going to choose our ports. uh The first port is our kind of like a quote-unquote front-end port. This is our service port um and then the target port is the backend port. This is the port that the container is listening on. So let's go ahead and grab that and create our service.yaml file.

B

In our workshop and let's go ahead and apply that.

B

All right, so our service is created now, let's make sure that we can actually talk to our api through that service. So, first a couple of basic checks: let's go ahead and check that we do have that service, in fact there, and let's also check that we have endpoints for that service and really endpoints uh will show us that there is a pod, that it was able to select with that selector that we've specified for the service.

B

Another last step. Since we've created a cluster ip service, we want to make sure that we can actually talk to that service from within the cluster and for that we're going to create a pod running inside the cluster that will just curl our service at uh api port 9090, and remember that our front-end port for this kubernetes service is 1990, not 80., uh and the dns that we're using in this case is just the cube. Dns cube dns by default will resolve to that ip that will work from within the cluster.

B

So, let's uh let's go ahead and run that.

B

So this will take a few seconds to for the pod to be created, but once it's there, hopefully we can actually reach our service and talk to doctor service.

B

All right, so this is our response. We have an api case. This is our uh kate's deployment within uh kubernetes, the api deployment within kubernetes, um and so it works great now we're in a good shape to add an ingress. On top of that, let's go ahead and delete that test pod that we just created called test api.

B

We will not need it anymore, all right and for ingress we're going to be using an nginx ingress controller where we have provided the file for you to install all the nginx crds the custom resource definitions, as well as the ingress controller. So just go ahead and cd into that folder and run a keep. Ctl apply that nginx ingress.yaml.

B

With with, hopefully the correct command all right, um we want to make sure that we have everything running so um since there is a controller, um the nginx controller, that's running, so let's go and check that we have all the pods there.

B

And once that ingress controller is running, we should be able to create an ingress object. So let's take a look at what it's going to look like so here again we're just going to say kind ingress and in the spec, where, like I said, this is really used mostly for exposing http routes.

B

In our case, we only have kind of like one main route, which is just a slash and for the back end we're going to specify our service that we have just created and tested, and then our service port, which is like the front end port for the service, now turns into the back end port for the ingress.

B

So let's go ahead and grab that check that our ingress is now running and let's create our ingress object here.

B

Let me see d out of this, because we already have an ingress object here, but I'm just gonna do it in the main one. Here we go.

B

Let's apply that.

B

All right so now we should be good to go. We can oops. We can uh double check uh that we do have an ingress uh controller there we can. We now should be able to just curl a local host and yeah be able to reach it from our local machine. So at this point we are ready from the routing perspective, to route make sure our web service can talk to our api service on cades.

B

So that is all good, but as our next step, we want to make sure that our migration will actually go smoothly, and for that we are going to add logging and routing.

B

So I'm going to switch over to configuring logging and routing, and really we want to do that so that you know like kubernetes already has logs like luke has shown, but those logs are going to be gone as soon as you restart those instances, so you're really not uh like accumulating logs. So you you want to uh kind of set up on your platform, so that you're in a good place- and you have your equipment with all the knowledge that you could possibly have so that your migration goes smoothly.

B

All right so for our next step: let's go ahead and dive right in actually and continue uh working on our logging.

B

I'm gonna go ahead and hit next here.

B

Cool um and uh for for the logging infrastructure, we're using elastic uh kibana and fluentd, and I'm gonna go over these tools and explain exactly what each of them does, because uh some of them take a bit of time to install and I'm going to use that time to talk a little bit more about each of those tools to get started. Let's first create our separate namespace because we want to have, or all of our logging infrastructure be running separately from our applications.

B

So let's create our login namespace. Our next step is to create a kubernetes operator for elastic. This is something that elastic provides. Basically, it just allows you to have special custom resources for deploying and managing elastic and kibana clusters.

B

So let's go ahead and do that install the operator.

B

Cool and now we're ready to create our elastic cluster, so this will be an elastic server uh running um running in case for this. uh We have modified this slightly here from the example that they have in their docs because we're running on kind, and we don't have that much memory, so we're adjusting resources to only run with one gigabyte.

B

Let's go ahead and copy this and create our elastic diameter. Here.

B

And let's go ahead and apply that.

B

All right um you can, you can actually pretty nicely check the health of the elasticsearch cluster again. This is because of the how elastic is managing their custom resource definitions, but we can just watch that and wait for the changes to be applied in the meantime, I'm just going to go over and talk about some of the logging infrastructure and how that works in case.

B

So when you're thinking about logging, uh oh one second.

B

Oh I'll, just talk like this when you're thinking about logging in vms and logging in kubernetes is really not that much different in vms. You probably have some agents running together with your application and they're forwarding your um logging directly to some sort of login platform. In this case, it's really not that different, except that everything is running in kubernetes pods.

B

So here you have your three kubernetes hosts and you have some pods running on there and what you add is a lock forwarder to each host and that log forwarder will look at all the pods on that particular host and you can configure that to to forward logs to your specified log storage and then that log storage in our case actually also is running on kubernetes, but it doesn't have to be. It could be external, it could be running in the cluster.

B

It really doesn't matter all right, so that's kind of the basics, it's very similar to vms, um and I'm going to explain a little bit more about like what each piece does as we're continuing to install our logging stuff.

B

All right, so it looks like our elastic server has come up and it's green. The next thing we're going to do is deploy kibana and kibana is really just the ui, that's kind of fronting the elastic cluster.

B

So let's go ahead and create kibana digamol and then apply that we can check the health of the cabana instance in a very similar way.

B

We can watch that, and these are probably I want to say, the most memory intensive things we're installing, because all of them are like packaging, a lot of things and their images could be quite large, so watch out for that docker memory that you've allocated and just if you're running into any issues or pending containers or docker image, pool errors just make sure that you have that enough memory. You go back to the prerequisites here that look has covered in the beginning and just make sure you have enough memory um so yeah.

B

So the what we have so far is the elastic cluster, which is our log storage right here. Additionally, we're installing a ui in front of it, because really elastic server isn't great for visualizing and searching vlogs. uh Just on its own, so kibana will help us with that.

B

um Let's all right looks like we have our kibana uh running. We can double check the health, it's all green and it's all good. So our next step we're going to log in into our kibana instance and just make sure that we can access things that we're allowed to access. So far, let's grab our password. First, I'm going to copy that and let's uh port forward the kibana service.

B

This will be running on port 5601.

B

I'm gonna go ahead and start that you have to say, uh um accept the risk because we're using a custom ca. So we really know what we're doing here and once the ui loads just use the elastic username and then the password that we've copied.

B

B

um And really, when we go to the kibbanis discover thing like we should be able to before we can start using kibana. We have to create an index, so it can index the data that's stored in elasticsearch server when we try to create an index we're seeing that there is no data yet- and this is something that we would expect, because we haven't configured that forwarding part so far. We just have the storage and the ui.

B

So let's go ahead and do that uh for the forwarder we're going to use this tool called fluency and this tool is really uh kind of standard in the for kubernetes and in general, the cloud native space, because it allows you to uh like first of all parse and uh forward logs of any kind of format and then on the back end when it forwards logs to some system.

B

It really is pluggable in many ways as well, where you can configure it to to send logs to any common log storage, lock solution in our case we're using elastic, and it supports that as well.

B

So, uh let's, let's kind of take a look at this fluency daemon set and really this damon said it's just something that is a standard you can look at.

B

You can go to fluentd docs and take a look at that, but I just wanted to show you all these environment variables that we're setting here and those are really the only things you have to modify to provide your elastic host a password potentially like various ssl configuration and and that's pretty much it, and I also have to note that this is a daemon set and the daemon set in kubernetes is something that runs on every host and, as I mentioned before, this is the architecture that we're looking at, for you know we're looking for something that can run on every host and then look at the logs.

B

So let's go ahead and apply that um damon said I'm going to keep kibana running. I want to interrupt that. I'm just going to go to another terminal window and go to.

B

I need to go into logging and then run keep ctl apply. Fluentd.

B

Once applied, we want to make sure that it's all good and running.

B

It's not available yet, but we can check the pods.

B

So that should be pretty fast all right, it's uh already running, so we're good to go um now that saloon d is running. It should as soon as it starts running. It should start forwarding logs immediately.

B

um So here we can just go to our cabana ui and check for new data, and we can see that it now detects that we have some data so we're going to define our index called logs dash. This is just the default name.

B

You can change that if you wish, but in our case that's what we're using go to next step for the time field, we're just going to use the defaults and then create our index pattern.

B

Next, if we go to kind of the main ui we're seeing all the logs are coming in from all kinds of various kubernetes system components, but we want to make sure that we're seeing our logs so let's go ahead and check for logs that have our api label.

B

All right, let's run our query and great, so we've seen our app logs in kibana we're good to go.

B

Let's move over to the next step, where we're going to configure metrics and with the metrics we kind of have a similar sentiment where we have. We want to make sure everything is running and everything is working while we're trying to migrate our service to kubernetes, especially that we want to make sure it's zero downtime.

B

So that's why we need to instrument uh the metrics and in kubernetes, so without further ado, I'm also going to dive right in and then I'm going to cover some of the metric infrastructure in a little bit afterwards, let's create our metrics namespace first it'll be very similar to how we did logging I'm going to interrupt my kibana ui. We don't need that for now.

B

And uh for metrics we're going to be using prometheus and grafana prometheus is a metric server and then grafana is the ui. Similarly, how elastic server is the server and then kibana is the ui and to install these things, we're just going to use the prometheus home chart and the grafina help chart.

B

So let's go ahead and copy these lines to install the primitius helm. Chart we're not changing anything there, we're just using all the default configuration all right, so that should have kicked off the install let's go ahead and do grafana right away as well. We refunded this need to depend on prometheus, so it can be running kind of in parallel, even if prometheus isn't ready.

B

So let's go ahead and do that.

B

And let's make sure that things are running.

B

All right, while these things are creating and getting ready, I'm going to switch over to our slides and talk a little bit about the matrix infrastructure here.

B

So, first of all, in the model that prometheus is using for metrics. This is called the pool model where the server is pulling the app for the metrics data every zone so seconds for that. The application itself needs to expose uh slash, metrics, endpoint and then the prometheus will um query that endpoint every x seconds, which is a configurable amount in our case, we're using whatever is the default on the helm chart.

B

But you can look at the hum values to see how you can change that and tweak that for your use case, and then, furthermore, we have a grafana instance, which is fronting the prometheus server. That grafana instance will help us display the logs and graph things in the beautiful way. Hopefully all right. So, let's, let's check if things are running, looks like all the things are ready.

B

As our next step.

B

We are going to note that in the output of your helm, install for griffin, I'm just going to scroll back a little bit, it tells you kind of how to log in so we're just going to follow this first step, where we will grab the user password.

B

And copy that and then the next in the next step, we'll just port forward the grafina ui. So we can access that locally.

B

We will go to localhost port 3000.

B

The username is admin and the password is the thing that we copy.

B

So this is our grafana ui, but it doesn't know about prometheus yet, so our next step is to configure that prometheus data source so go to configuration and add data source from bts is the first suggestion conveniently and really. The only thing we need here is the http url, which is by default. Http colon, slash, slash prometheus server if you're using the home chart, it really won't change for you as well cool.

B

So it's now working, we should see just kind of the default kubernetes metrics and I'm just going to show you something just to make sure that it's working.

B

For example, we can look at response times of kubernetes rest client just to get a sense and looks like it works, and the response times are looking great as well.

B

So our next type step for metrics is to change our application. So we can. Our application is going to start to send metrics right now our application isn't configured to expose that metrics endpoint that I've talked about, and we need to make a few changes to it. To allow that so I'm going to go to our oh apologies, so I'm going to open our deployment.yml.

B

Okay, one second: where there we go so in our deployment, then yaml we have to do a few things. First of all, we have to enable our application to expose the metrics endpoint and in our case all it's doing, and it's it's just taking an environment variable, so we have to add it under the containers. Stanza here.

B

Oh okay, there we go. Hopefully this will work um and then next we will need to add annotations to our pod and, as luke was talking about how deployment and pod are kind of nested within each other, we have to make sure that those annotations are on the pod metadata, not on the deployment metadata.

B

So let's go ahead and do that as well.

B

This is our pod metadata, so.

B

Okay, um so that should enable the prometheus server to look for this app's uh metrics endpoint and scrape them. So let's go ahead and apply that.

B

I had a feeling this will happen if this is happening to you as well. You can just grab this radio.

B

Deployment.Yml.

B

And use that instead.

B

B

Right- and that is all because yaml is hard, so, as you can see, we have our old pod terminating and the new pod, starting up with this new configuration.

B

We should also go to our app and just kind of try to generate some metrics by just going to localhost.

B

Oh, maybe not this local host.

B

But the one that's running in kids, let's just kind of do that a few times, so we generate some new metrics and now, when we go to grafana, we should be able to see our app specific metrics. So I'm going to refresh that page and one of the metrics that we have is how many times has the server service started. So let's take a look at that and we have that metrics that metric has come in. It's called a service service started total.

B

We should see that it has started a total of one times, which is true and the last thing which I'm not quite sure that this will work quite yet. But we can look at the response times that this app will have currently has.

B

It doesn't look like we have that quite yet. Let me try another query.

B

It's possible that we'll just need to generate a little bit more metrics, but that's okay, because we know that the metrics are coming in, because we've seen that other counter that has started all right. So at this point you have the logs and you have the metrics configured and we're ready to migrate.

B

All right so remember how um luke has mentioned that we're just going to switch our dns right now, just to recap, we still have our web running and we still have our api running locally. So if I go to localhost.

B

B

B

We should see that we're still pointing at vms.

B

And if I go to the ui part, you can see that it's still running in vms.

B

So now to migrate, uh we want to make sure that um basically, we just want to point that dns at the new ip and in our case we're using this ipv6 because any ip that is not a one, two seven zero zero one will default to that. um Basically, uh the one that's listening on all interfaces because remember we have uh one uh that's listening on ip127001 and then we have another one, which is the kind ingress that's running on all interfaces.

B

So basically we just want to choose an ip that our machine understands, but the one that is not going to route to this vm one.

B

This is not really, of course, something you're going to do in real vms, but this is these are the constraints that we're operating so let's go ahead and change our etsy hosts.

B

So you should have this line, that's pointing at api, I'm going to change that to use the ipv6 localhost and save that.

B

And now, if I go to my web, I'm seeing that it's now pointing at api case, which is great awesome- we've switched over we're. Now we haven't restarted our web at all. It's just pointing to our new kubernetes service, which is great, um and the last part, is um let's just double check that our metrics are coming in for um from web going to api.

B

So again, here I'm going to um kind of refresh this a few times because to mimic kind of a real back-end service that is probably calling the api continuously um and, as the last step, I'm going to check that these metrics are in grafana. I do not know if they will appear. Hopefully they will cool.

B

So um what this is doing is uh checking the um request, the rate at which the requests are coming in in the last five minutes, and we can see that all of a sudden this has picked up to a new value of 0.06, so yay. This is how we know that it's running our metrics are showing up great we're all healthy and we have migrated to gates.

B

So at this point I, uh let's just kind of go over what we have just accomplished.

B

We had our api and our web and our api pointing to this one, two: seven zero zero one port, and then we switched it over to the one that's pointing to nginx and in the vmworld. You would do something similar where you'll take your dns entry for api.company.com and you will switch it over to let's say your nginx load bouncer as as shown here, um and I I think, we've already covered step, seven so where we are right now and what we did. Let's recap that we have built a docker image.

B

We deployed that to kubernetes using a kubernetes deployment, we've added a kubernetes service and a kubernetes ingress so that we can reach it locally.

B

We've added logging and metrics to our app and then finally perform that zero, no zero, downtime migration, where we switched over our one of our services and pointed it at the one running in queue and as our last step, we're we're gonna cover the console service. Mesh uh luke. Do you? Do you wanna talk about that.

A

Yeah uh before we get into that, let's just go to the next slide there and chat a little bit about what we did.

B

A

There's a couple things uh to think about here. I know this was kind of like a constrained example, um and so, let's kind of talk about like at a higher level kind of general lessons and things about adopting, kubernetes and that might be useful to new folks to the to the ecosystem.

A

So uh I've personally done like a kubernetes migration at two different companies, and I think I just want to like give some advice to folks who are doing it for the first time. um So keep it simple, the the second you start using new tooling, you get really excited and you want to use all the new tools that exist in the ecosystem. So, like the stuff, we just showed you, like. You know your elasticsearch and your fluency. You want to use prometheus and grafana.

A

You want to use a service mesh. You want to use all those new things right, and so what I? What I? What I caution, folks is: keep it simple: don't try to set up this brand new beautiful platform in the sky, focus on what you really want to do, which is get your app onto kubernetes, and I would encourage you to use the existing tooling.

A

So if you already have something you're using for metrics, don't switch to a new metrics provider, use um use whatever tooling existing kubernetes to get your metrics into your existing metrics provider?

A

Okay, if you already have existing logging system use fluid d, but then get it into your existing logging system, don't switch to any logging system and- and the reason I recommend- that is because you really want to be focused on like what provides the most value to your organization and that's going to be having your app running kubernetes once you've got that process smooth and oiled out, you have your build pipelines and everything set up you can deploy over there.

A

You know your migration is good because you're looking at metrics and everything, it's a lot easier to start moving things over and kind of picking that up and eventually you can switch to that that new tool that you really wanted to use. But if you start jumping and trying all these using these things at once when something goes wrong.

B

A

To be like, there's like 100 things that could have gone wrong: you're, not 100 percent, certain, like what part of it went wrong, and so I think, like I really want to caution folks like keep it simple, uh to start kind of focus on providing value, getting your app into communities. Getting that first migration piece done that in and of itself is gonna, be a ton of work.

A

uh Don't don't don't get me wrong because, like if you're moving from vms to kubernetes, this is a whole new set of things you have to deal with, especially around builds and security and access.

A

We did make it look pretty easy here, but there's a lot of things that we didn't kind of show you what you need to figure out so keep it simple: don't try to use all the new shiny new tools unless it actually really makes sense for your use case um irena. Do you want to cover the next two.

B

um Yeah and um definitely one two plus one uh things that you've just said like the tooling that we've shown um is is not necessary, is just showing an example and definitely keep your existing tools. um One thing I wanted to highlight is just the kubernetes ecosystem is a really rich ecosystem that has a lot of tools and, if you're, using something um out that it was different from what we've shown like the likelihood is that that tool or an integration with that tool already exists in the ecosystem.

B

So I would definitely encourage you to look uh and find things that are already implemented, and then the last piece that I wanted to highlight is security, and we kind of I've alluded to that where we have our last step, where we're talking about a service, mesh and really a kubernetes is a service mesh in in some ways, but it doesn't have any of the security features of a service mesh right now, everything within our cluster, our nginx ingress. That's talking to our api service.

B

All of that is in plain text, and if you want to increase like to step up the security, especially the security and the networking within the cluster, then I would highly encourage you to look into something like a service mesh, because it can add, um like this kind of mutual tls encryption by default, um and this is, you know, like definitely don't do it as the first step. But as the next step in your migration, you might want to consider.

B

uh You know, thinking about things like security and zero trust, networking to just kind of increase and harden your cluster and the services that are running in that cluster.

A

Yeah absolutely and that's that's a great segue, uh I'm going to talk about that quickly, just going to go through the console service mesh. Next, I'm actually going to pause here, uh so I can get caught up with all the work irina's done and then, when I resume the recording I'll be all caught up and we can just uh try out console server, smash all right and we're back.

A

uh I've got everything caught up now with all the work I read ended, and so we're just gonna do a really quick demo of console service mesh um and how it might be useful. If you have like a larger deployment, you have a little bit more complexity involved.

A

So let me just share my screen here, so I gotta catch up to here. Okay, so what we have uh is we have our browser talking to web he's talking over to nginx and it's talking over to api so like.

B

Irene said there isn't.

A

Right now, like it's all done in plain text, so web's talking to engine x, so we're playing text and nginx talks to api or playtex, and so one of the benefits of the service mess that it can bring is a mutual tls. So the idea we have tls that goes across the whole connection here and the other thing that a service mesh can bring is what basically it does is it sets up proxies in front of everything, and so these proxies are now programmable.

A

You can you can change the requests to to do whatever you want with them, and so what I want to do is a really quick demo here of uh we're going to swap out nginx for uh console ingress gateway, we're going to put a proxy in front of the api service here. So it's going to be part of the mesh and then we're going to show you some of the cool like routing capabilities we have uh when this api service is now part of the mesh. What we're gonna do is we're.

A

Gonna have api like be really buggy service. Have lots of errors then we're gonna use our routing rules to say: okay. Well, if there's an error, just retry it. So this might be something useful in your migration. If you, if you were finding like, obviously you should look into why there's lots of errors, but uh in this case you might might be something useful to like kind of the stopgap measure, and we have all this documented here in workshop uh workshop step eight. So let's go over here into step eight here.

A

So in this section, what we're going to do is we're going to install console on our kubernetes cluster and then we're going to configure it. So the first thing we need to do is actually need to uninstall nginx. um That's because nginx is kind of listing in place there on port 80.. uh We could do this and we could have our skate. We listed on a different port, but then our nice routing, where the web, the web service, doesn't know it always talking 480 that wouldn't work.

A

So in this case we're just going to take the the quick road here is delete nginx here.

A

So, let's uninstall nginx here and now like we can't we're free to install console. So the first thing we want to do is we need to add our helm repo, so a console is installed by a helm and then we're going to create a values.yaml file for our installation.

A

So this is what's used to configure your your helm installation. So so a couple things to note here, um one we're using one replica for the console servers. Now, usually you want to use three, but uh you want them spread across three different nodes. So if node one node goes down, the other two are up, they still have quorum. Everything works fine uh in kind, there's only one node, so we're gonna set this to one. For this example here this is a connect inject.

A

What this does is it says I want you to inject a sidecar, so a sidecar is just another container. Remember.

B

A

When we talked about how pods can have multiple containers, this is where this is really useful. So we can actually inject a proxy as a sidecar container. So it's just a container that runs in the pod and what this is doing is it's going to automatically inject it. So you don't have to like set it up in your deployment.yaml, but it's going to when it sees that podcast, it's actually going to automatically inject our proxy into there.

A

This controller here is allowing us to use our custom resource definitions which is newly out in the beta on console beta and then here we're setting up our ingress gateways. So this is going to replace our nginx ingress controller, uh so we're setting up our gateway here and it's going to be running on 480..

A

So let's save that file and then we're going to run a helm, install and don't try to keep ctl apply that because that's not going to work so we're going to run a helmet stall here and we're going to point to that.

A

So I'm going to open up another tab over here just so we can just watch that so watch keep ctl.

A

And it's a bit ugly, so I'll make it a little smaller, but basically uh we have our console services coming up here.

A

So this is going to take about two to three minutes. What is happening? It's a little bit, sometimes a little bit slow because we're running on kind, but what we're getting if we look at the components here, let's open this up a little bit wider.

A

Okay, this okay, there we go! So let's look at the components we get so here's api, it's running! It's you know doing its thing. We haven't made any changes to it. Then we have our console server. So this is the where all our data is stored, and this is what we we said. We only want one replica of um then we have our angular gateway. This is a currently in an error state, because the rest of the cluster is kind of up and coming. So you can see here like this console here.

A

This is a what's called a console agent and the ingress gateway relies on that console agent. So this needs to be running for the gateway to actually work. You can see here now that the console agent is ready, that this is coming up. So this is what we're actually going to be. It's actually going to be listing on 480. This is what we're going to hit to get it all working.

A

So I'm going to make this smaller here. This should soon uh be market itself as ready, but I'm immediately going to make some changes to it so well, we don't really have support right now for listening on a host port for the ingress gateway, because it's made more for like running a cloud, so we're just going to do a little bit of a cube, ctl patch here to actually patch that deployment. So it listens on the right port.

A

So um I'm going to run this command here, qctl patch, and it's going to patch that deployment. So it's running on the the expected port, which is port 80.. So then it's going to be bound to the same port as nginx and so we'll actually be able to come through it.

A

And so we can run this rollout status command and we can watch to make sure that that rollout is actually complete. um But what I'm going to do is kind of fast forward here. So I don't want to take too long here. So, uh while that's all coming up, we can actually look at the console ui.

A

So we're going to do a port forward here and it's going to port forward a local 8500. So if we go over here to the vocal host 8500 ui, we should be able to see our console ui.

A

So this is a list of all the services that are in our service mesh right now there isn't any. We can see our console instance, which is running as we expected, and then our english gateway here is starting to come up. We have like one instance coming up, and then there was that that new one coming up on port 80 that we're kind of waiting uh for it to be running um yeah, so it should come up soon and then we'll be good to go.

A

So now we look over here. We see that you know we have our list of services, but there is no api running, so we go back to our notes here. What we want is we want api to be part of the service mesh. Now it's not going to get automatically injected with that sidecar. We wouldn't want uh constant service messages, injecting everything really nearly so you actually have to annotate that service. That says: hey, please and please inject me with a sidecar so to do that.

A

What we're going to do is we're going to use that patch command again and we're going to add an annotation that says: hey inject me with a sidecar.

A

So let's run that patch command here and we can see here that api is now starting to come up and you can.

B

See here it has a zero three.

A

So this is actually the number of containers. So previously we had one now we have three so what's going on there. So this is the injection right, so we're getting our sidecar, which is running our proxy and we're also getting another sidecar. That's like a helper container. It helps with dealing with the life cycle of these pods. So if we go back now over to our console ui, we should see api, and here we do, we see an api and it's connected with proxy.

A

So it's all up and running as we expect it's now part of the service mesh. It's got its proxy running next to it, uh but.

B

We're not done yet. We need to just like we had to configure.

A

Nginx um to to route to a service via the ingress object, we need to uh configure our ingress gateway console to route to the api service. We don't want to just expose any service. You know we have to.

B

A

Explicitly um say that we want it so the first thing we're going to do is we're going to uh set the protocol for our api service to http, and this is so we we know what protocol it's using and we can actually provide better metrics that way, because we know that it's using http and not tcp, so we're going to apply that okay and then we do qtl service defaults just to make sure that's working as effective, and it says it's sync true. So that means that worked, then we're going to configure an ingress gateway.

A

um I'm going to. I can show you what this json is in a second. So let's see this, this youtube.

A

Oh we're just gonna wrap it.

A

So here we're saying: hey ingress gateway, listen on port 80 and you're, using http protocol, and we say: okay, we want you to route to api when you get a request in uh for api, make sure you're out to avi. So this is going to configure the interstate ready to render our api service that's running. So if you look over here, you should see in this gateway. Here we should see that it's configured throughout the api, so that's all that's needed. So we've set this all up here.

A

We have our ingress gateway routing to api with this proxy. So we should be able to go to this here, actually see that working.

A

And we do we see now that we're running through the interstate we've placed the nginx gateway, okay, so you're thinking like hey well, so what what's the point of replacing in the ingress gateway? You know that was already working for me and I'll just show here we're hitting our web service, and you can see here that we're actually getting this new uh header added here. So this is actually the proxy that's adding these headers, so you can see that it's actually going fully through.

A

So one big benefit we have already is that we now have tls going in between the ingress gateway and our application here and this certificate, for this is totally provisioned like uh by consoles. So you don't have to deal with like provisioning certificates and everything like that. It all happens automatically, and if anyone is listening in your cluster to um traffic, then now it's encrypted, so they can't actually like sweep that traffic.

A

But I also want to do a really quick demo of kind of the power that you have now you have these proxies in front of everything. So what we're going to do is we're actually going to cause our service to to have failures. So luckily the service has support something where you can actually set an error rate, and uh this is our api service. I'm talking about, and you know what it'll do is you set to 0.5 50 requests of the service are just going to fail. It's going to fail out right.

A

So let's do that.

A

So we should see api start to come up here with the new. Oh excuse me for the rollout.

A

We have the new one coming up here and now we make requests to it, we're actually going to see half of them fail. So this is probably not ideal right.

A

So if we do this curl again, we see it's not healthy.

A

If we look over here.

A

uh Okay, I think yeah- I think I know what's happening here- okay, so if we curl here okay, so this is what I wanted to show you. So if we curl here- and we can see that this- this request succeeded with 200, but then this request failed with 500. I curled again, you can see here again it's getting 200 curl again, it's failing to the 500, so this is really not ideal right, and so this is, where kind of we have the power of the service mesh.

A

So why don't we just tell the proxy that's running over here this. The ingress gate is it's also a proxy right. Let's just tell it to retry requests uh to have a 500.. I mean it's a bit of a band-aid text. You should probably look into why your services 500, but this could be really something that's valuable for a short-term fix or something like that.

A

So all we need to do is create a new crd called a service router and we look into it spec here it's saying I want you to retry up to three times whenever you see a 500., so let's apply that.

A

And we'll do cube ctl get service router to make sure that apply properly. So it says it's synced true! So now, let's go back to this curl.

A

We're not seeing any errors, so this is uh pretty cool. You can see that the duration is actually changing. um That's because, like so that one you know that one took a while. That's probably because that one we tried three times right.

A

So that's just a really really quick demo of kind of the power of the service mesh. um There's a lot of other things you can get out of it and it's one of those things where it, depending on the complexity and what you're, what you're getting at. We did talk about, keeping it simple, but if you find yourself having to like manually provision a bunch of tls certificates, because you will rule your organization that l, the all the requests have to be mtls, then the service mesh can actually it's complex to add it.

A

But then it's actually solving you. Saving you from a lot of complexity, so, depending on the trade-offs there, it might make a lot of sense for your organization cool. So um that's the end of it there uh you can find us on twitter at ashustava and at el caiso. um Did you have any final words? I reno.

B

Yeah, thank you so much uh that was awesome and thank you all for coming to this workshop yeah feel free to talk to us on twitter. If you want afterwards and we'll probably be in the chat right now talking to you.

A

Yeah, absolutely all right all right. Everyone thanks for listening and uh have good luck with your kubernetes.