 Which are our best. All right, so tell us about yourself or those that have been living under a rock. Ah, well, I don't even know what's living under a rock. So I'm Brandon Burns. I'm one of the co-founders of the Kubernetes Open Source Project. Kubernetes is a container orchestrator. It's basically a way of taking a whole bunch of computers and joining them together into a single shared resource and then using those resources to deploy a wide variety of containers and put together what has been come to known cloud-native applications. And then I work for Azure, obviously. And they're, in addition to the Azure Kubernetes service you just heard about with Scott. I work on actually, I run a bunch of other teams that deal with sort of DevOps and APIs in general and open source, a lot of open source on Azure. So I know there's a lot of devs that have heard about Kubernetes and maybe I'm in this camp where I need to know a little bit more. How did you come up with that name? Or how did that name even come up with Kubernetes? I mean, it sounds like a future thing. It wasn't me. It was one of my co-founders, Craig McClucky. And we've talked about this a little bit, but the project was originally called Seven of Nine. Because, so the original internal container orchestrator that we used was called Borg. Because it's like the Borg collective. That seems more apropos, I think. And so Seven of Nine, if you've ever watched Star Trek Voyager, which is a way of admitting that I watched too much Star Trek. Oh my goodness. Seven of Nine is like the Borg character in Star Trek Voyager. So I originally called it Seven of Nine as the code name. And then it became Project Seven, or as these names iterate, these code names iterate. Then we went, we had to launch and we needed a launch name. And we were thinking a lot, Craig actually was thinking a lot about, well we were all sort of batting words back and forth, but Craig was driving to work as he tells it. And he was thinking, well what does it do? And Docker sort of had all of these sort of nautical, you know, they had the whale, and they had sort of like, so there's a lot of sort of marine analogies going on. So he's like, well it's like the person who drives the ship. Kubernetes is like the person who drives the ship. And so he looked up Helmsman, the word Helmsman in Greek. And it, and Kubernetes is Greek for us. I, we actually pronounce it wrong. I think if you're actually Greek, you pronounce it something like Kubernetes or something like that, but it's too late. Everyone's saying it wrong, it's too late. It's our fault. So that's, and it stuck and we launched from there. And it turns out in retrospect, it's actually also the root of cyber and cybernetics. So the word cyber actually comes from Kuber in Greek. And it totally looks like we planned it, and we totally didn't. No, we're gonna delete this in post because you totally planned it. So with the advent of this new kind of technology recently, there's a lot of terms floating around. I'm hoping, cause this is Kubernetes for the Clueless. There was like, we have Kubernetes, we have images, we have containers, we have Docker. Can you make sense of that for us? I mean, help us out. Yeah, I mean, so I thought maybe we would do a little whiteboarding. Let's do it. If that works. Yeah, let's do it. Let's go to the screen here. Hopefully this will show up. So, you know, I'll turn it a little bit so you can see there, but hopefully we're broadcasting this out to everybody. Are you on a Surface Go right here? I'm on a Surface Go. And you're doing like a distributed computing talk here on a Surface Go. I love my Surface Go. Man, this is amazing. I totally love it. This is amazing. I walk to work a lot. And so like the fact that it's a pound and a half is just life changing. All right, so, you know, when we're talking about a container, there's actually sort of two parts of the container. There's the image. I wish I had my pen. And then there's the kernel. I should just not spell words. Yeah, I should just not spell words. No, this is okay, I love it. But the, so the image is actually what a lot of people are thinking about because, you know, when you used to build things on a VM, if you had a VM here, you have like, you know, your app here maybe in some shared library and maybe you have a couple of different apps and they both depend on the same shared library. And now you're in this sort of thing that people call DLL hell or dependency hell where it's hard to upgrade one per application because two applications depend on the same thing and you make a little change and it has all these downstream effects that break things. And so people got into containers a lot because they were really interested in separating the images so that you could have, you know, multiple different images and they ran on the same kernel, but all of the dependencies are up here in the image, all of the things that you need. So these images become very hermetically sealed and so you can upgrade each one independently. They never interfere with each other. And they're also isolated from a resource perspective. So in terms of RAM and in terms of memory, they have totally separate sets of resources that they're using. And so they are isolated in a way that makes them easy to use. So that was sort of what got people into containers originally because if you think back to the days of VMs, it was really hard to manage. You ran all these scripts and failed like, and after it failed once, could you run it again? Maybe if you built the script right, it's very hard to understand why it broke, how it broke. Whereas with a container image, it was item potent. You just, if it didn't work, you just installed it again. If you upgraded, you didn't worry about stuff left over from a previous version messing around with stuff. So that's really why people started getting into it. But again, this boundary here, this is all just one machine, right? Like it's all just running on one machine. But most systems when you're building these distributed applications, they need to be on multiple machines. Right. And so that's where an orchestrator is all erased here. Let me pause you there for a second because one of the things that sometimes I conflate or get confused with is the notion of an image versus a container. Is it the same thing or what's the difference? Well, container is this word that's gotten kind of overloaded. So help me out. Maybe you can demystify it. Sure. Maybe I will, I'll try and draw a different picture here. So there's sort of two different pieces. There is, there's the cloud. Very cloudy. It's very cloudy. I'm gonna try and draw a laptop here. There's my laptop. Holy cow. That's not bad, right? The degree in art. That's right. I'm not even kidding. Oh really? You got into distributed systems from art? It was computer science and art. I have a double major in computer science and art. So anyway, you do a bunch of work on your laptop and you build up a container image. And you can think of a container image really as basically just being like an archive. It's really just a bunch of bits, binaries, files all kind of smooshed together, right? So you have that image here. And so image is the same as container. Well, it's a container image. Okay. So I think it's, I guess maybe the right way to say this is it's like a class versus an instance. Okay, okay. So like the image is the class. The container, the running container is the instance. Okay. And so you take the image, you push it up into the cloud, into the registry. And then on a bunch of different servers, you can run that same image. And then they're running on the kernel. And so you have a bunch of, if this is your class, you have a bunch of instances running on different machines. And in this case, an instance might be a whole software stack, for example, for running a service. Right, and the reason they're called containers is that effectively if you inside of the kernel, so like the kernel has things like, like the easiest thing to think about is like the process ID space, PID space. So every process that runs has a number associated with it. Typically on a normal machine, there's only one of those, right? There's only one process one, there's only one process two, there's only one process three. With a running container, you actually create a separate PID name space for each container. And so there's actually a PID, there's a process one in each of those. I see. And they can't see each other. And so that's why they're sort of, the running container part is just like, isolation inside of the kernel. That's cool. To keep the applications apart from each other. And you keep talking about kernel, that basically means the OS, the operating system. Well, you have to be very specific. It actually means kernel, right? Operating system is also a vague word, it turns out. Because like an operating system is the combination of the kernel and the user space. Got it. So like, you look at like an Ubuntu, it's gonna ship a kernel. It also ships things like bash. So the bash isn't in the kernel. Got it. It's an application that uses the kernel. So with a container, all of the user space stuff, all bash and all that kind of stuff, it's in the container image. I see. But the logic that implements like accessing a file or accessing a disk, that's in the kernel. And what's important actually is that, that logic in the kernel is shared between multiple containers. I see. And that's actually important because it means that the containers themselves are actually not secure. Because they share that kernel, if there's an exploit in the kernel, I can jump out of my container and into your container. I see. With like a funky system call. With a bad system call or whatever, right? And so it's really important for people to understand that containers are there to sort of keep us from stepping on each other. But they're not there, like if you're malicious and you're mean, I'm not letting you, I'm not letting you run a container next to me. I see. So it looks like when you're running a container, it thinks it's, you know, because like every process when it's running, it thinks I'm the only one running because I'm the best one. And then you swap it out and it's suspended. Same thing with the- That applied to the file system applied to CPUs. So you can lock them. You have a multi-core CPU. You can lock containers to different cores. So you can say this container has exclusive access to this core. This container has exclusive access to that core. You know, the operating system normally would switch you back and forth, but if you're locked, it won't. And it'll protect your resources that way. That's cool. So now that we understand that we're making these logical things called containers that have functionality, that they think they're the only program running, then we need to start talking about two things. And hopefully you can help me with this because I always have a hard time with this is, how small, because some people might put like their SQL server all the way to their ASP.NET application in a container, but that feels wrong. And some people might put like a single function into a container, but that seems wrong as well. How do you know what granularity is number one? And then the second question, which I think gets to Kubernetes is, how do you start to manage how these things live with each other? Yeah, yeah, yeah, for sure. So in answer to the first question, I mean, in some ways, I said it's like a class in an instance. It is kind of like designing classes. Like you could almost say the same thing about objects in Java or whatever. Like how do you design the right object? But there are guidelines, right? And so generally speaking, the container is a unit of scaling, right? And so you talk about the, your Java Tomcat server and your database. Well, if you put those in the same server, you can only create, you probably can only create one container instance, right? Because you don't want to create lots of copies of that database. You're only going to have one instance of that database. So now you're restricted, your horizontal scaling of your web server is limited by the fact that you've placed it in the same container as your database and you can't scale your database, right? So generally you would say, I want to separate the web serving tier from the database because I want to have 10 copies of my web serving tier, but I might only have one or two copies of my database. And one is a fallback and one is a primary. And one is a fallback and a primary and you know, if I'm living dangerously, maybe I just have one. And so that's what you're thinking about, right? It's how do I break things apart into horizontal scalability? I think the other thing to think about is the container image itself often becomes an artifact that is produced by a team. And so if you want to have, if you want to decouple your teams, oftentimes you decouple them by having them produce different container images. So it's not just a technical thing, it might be an organizational thing as well. Correct. And so you're sort of, I mean the same thing with like object oriented programming and classes come in because you might want to have an interface that separates two teams. And you might do that just to build better teams, right? And I think in general Kubernetes was trying to build these abstractions that allow you to decouple your different pieces from different pieces from one another. Awesome. Well, I've heard the saying in computer science goes that when you have a problem and then you solve it with distributed systems, now you have two problems. 10 problems. Sorry. Yeah, 10 problems. So how does Kubernetes help with orchestrating? Because that's what it is, an orchestrator. Because some people and I confuse this and maybe you did too at home. I confuse Kubernetes with like actual making containers and being Docker, but it's not Docker. Not at all. So tell us about that. No, no. Well, I mean Docker kind of straddles the line, but because it's both the builder and the run. And I think one of the reasons I have this trouble with container and container image is Docker is actually both the thing that builds the image and the thing that runs the image. And that confuses people? Yeah. No, so an orchestrator is really intended to provide tooling around, so like the container, I call it the runnable thingy. It's like you imagine you have this black box and you can press a play button on it and it plays. It runs. And it runs. But there's all sorts of stuff like, what happens if it stops running? What should you do? How do you know it's healthy? What if I want three copies of it? How do I bring load balance traffic to it? All this kind of stuff? That's how, that's what Kubernetes provides. And there's actually a series of examples that we could step through. Let's do that. You wanna do that? Before we do that though, there's a couple of questions. There's lots of chatter on serverless versus containers and what to use when. What do you suggest before we dive in? Well, so I think it's important to distinguish between serverless, meaning I don't have any servers, versus functions as a service, which is a programming model. And I think they got kind of conflated. But we actually, in Azure, offer serverless containers, right? So, Azure Container Instances is serverless containers where you give us a container image, we run it for you. But it's like infrastructure as a service, right? It's like, we just run it. It's like you gave us a VM image and we ran a VM, but instead you give us a container image and we run your container. But it's not, we don't tell you how to program, we don't tell you what language, like functions as a service, there's only a certain number of programming languages you can use, a certain amount of memory you can use. There are none of those restrictions in our serverless container offering, right? I see. It's IaaS. It just happens to be IaaS where you don't see a machine. I see. And then there's functions as a service, which is a programming model, event-driven, on-demand. It's a way of, and tooling, easy to use tooling, makes it really easy for you to take a piece of code and push it up into the cloud. So I think it's important to distinguish between those two things. I think that I see functions as a service being really great for web hooks, for... The glue, the internet glue, yeah. Or like, hey, something asynchronous happened on some queue, somebody uploaded a file and I wanna do something in response to somebody uploading a file. I think containers are more oriented towards longer running processes or large-scale serving where you have thousands or hundreds of thousands of requests a second and you just need to have something that's running all the time. I see. That's the place where our containers are useful. I think ultimately when we look at the apps of the future, what we're gonna see is people are building with a mix of containers, functions as a service, and data stores like Cosmos DB and those sorts of things, right? So when we're talking about Azure Container Instances, that's what you're talking about, containers as a service. But then it begs the question, if you have hundreds of those things that you're spinning up, how do you manage them together? And then now we can get into the corner. And that's Kubernetes. And in fact, actually today, I just announced the preview of virtual nodes for Kubernetes, which basically takes that serverless container infrastructure and marries it up with Kubernetes orchestration. So you can actually orchestrate the serverless containers using the Kubernetes APIs. So you can either decide, do I wanna deploy containers to VMs, or do I wanna deploy containers to the serverless container infrastructure? That's amazing, because then you don't have to worry about, because usually the first time I set up Kubernetes and I did one time and I, because I went through the tutorial, like all good people do, I had to set up VMs to do stuff. But with this, there's no VMs. There's no VMs. It's all Azure service. It's all in Azure service. And there's no, we do all the upgrading of the OS, we manage the OS for you. If a machine fails, it just moves over to a different machine, all that stuff. Can I choose like a machine that has a GPU on it yet? We have GPU in Azure container instances, not in the virtual nodes currently. Okay, cool. But yeah, it's coming. All right, let's take a look. All right, cool. So I have a simple little YAML file here. So one thing you'll see actually is Kubernetes loves its YAML. So when I see here, I'm describing the containers that I'm gonna run. So this is the file, I'm sorry to interrupt you, it's just so I want to understand. This is the file that says here are all the images that I want to run in this publication. Well, in this pod, which is one sort of atomic scheduled thing, one replica of your application. Okay. So this is only just running a single instance, not running multiple instances. There are other primitives for creating replicated things. Three, four, five, six, seven. We'll talk about those in just a second. Let's do that. All right, so at first we're gonna create this pod, so I'm gonna say kubectl create dash f. And what this is doing is this is getting all of those image definitions and getting them ready to run as containers. It's actually making a declarative statement to the cluster saying, please run this. I want this to exist. Okay. And so then having done that, if we say kubectl get pods, you can see that we have this one up and running, it's been running for 17 seconds. So this basically when you create it, it's getting all of those images, creating containers. Downloads them. Yeah, runs it on the orchestrator. And then the pod represents like a logical unit of containers together. Yes, yeah. And the reason it's multiple containers is you might have an application container and then you might have a container that's doing something like log forwarding. So it's reading the logs off the application, shipping them to Azure Monitoring or something like that. Cool. So then Kubernetes actually has a lot of tools for sort of debugability, including the ability to port forward. So that server is running, it's not on the internet, but it's running on port 8080. And actually if we go back over here, you can actually see, you can see it's IP address, whether it's it's IP address, which is inside the cluster. I see. But then I can actually port forward it, which means that I'm gonna port forward traffic from my local machine here out into the cluster so that I can play around in my application without it being exposed to the internet. I can do development, I can push it up, I can run it, test it, without it being exposed to the internet. That's cool. And while that's going, just a quick question. Cause I've done, I've been able to do like Docker run and be able to port forward, so I could expose it. This is more like Docker run, but with multiple images. And well, no, but more importantly, connected to the cloud. Okay. This container is executing in an Azure data center. Oh my goodness. And so the port forwarding is bringing the network from the Azure data center down to the local machine here. Holy cow, that's amazing. So this is a little, this is the QUAR demo, which is the Kubernetes up and running book that I wrote with Kelsey Hightower and Joe Beto, who's one of the founders. It's kind of a way of like exploring some of the features of Kubernetes. And in particular, we can go over here and take a look at this liveness probe. So one of the ways that Kubernetes makes it easier to run these distributed systems is it will automatically restart your application if it fails, right? Oh, cool. And not just if it crashes, but actually if you define it as being unhealthy. And the way you define it as being unhealthy is you can say, hey, please hit this web endpoint. If I return 200, I'm healthy. If I don't return 200 or I don't return anything, I'm unhealthy and I want you to terminate me, right? And cause that's good because maybe you get deadlocked or you get overloaded or something bad happens. Your process is still running, but you're not successfully processing web requests. And you won't get like some beeper in the middle of nothing to restart your application. Right, and so you don't want to get the page and all sort of, you want the automation. The one way to think about this is, there's planes out there that fly by wire, right? Like you just literally fly them and then there's things like the B2 stealth. There's a computer there. The only way that thing stays in the air is cause there's a computer driving it. Kubernetes is the same way, right? There's a computer that's trying to keep your application healthy for you. So we can actually drop back over here and I will terminate this one. I'm gonna delete the instance that I have. And this is running in the cloud. I mean, how did you- This is running in the cloud. So there's like, do you have to like do something with Kube CTL in order to- So when you create the cluster, you download this configuration file. Okay. And the configuration file gives you like the certificates for accessing it. Actually I use AAD for accessing it and the IP address and all that stuff. And then once it's done, it's, but it's through AZ. You just say the AZ tool, you just say AZ get credentials and boom, it's on your file system, you're ready to go. Love it. So then if we go over here to this health check one, what you'll see here is this looks similar except for I've added this liveness probe, right? And so what liveness probe says is, I want you to hit this URL on my container to see if you're healthy or not, right? And it's going to probe it every three seconds. So you can see the period seconds is every three seconds. So every three seconds Kubernetes is going to hit this endpoint. Holy cow, that's amazing. See if you're healthy. So we can run this one. So like if you're making a Flask app, for example, you just have an extra function there ready and be like, yeah, I'm good. Yeah, and you can do stuff. I mean, you can do more advanced stuff. You can check to see if you can talk to the database. Maybe, maybe like, you know, you have a connection pool and the connection to the database has screwed up somehow. And if you can't connect to the database, well, you can serve web requests, but you're not really healthy. You'd prefer that it terminates you and you come back up and maybe you reconnect successfully when you terminate, right? So healthiness is a defined by the program. Healthiness is application defined by the programmer, right? And so just like we do before, we're going to do a key control, create stuff. So we're going to create this, but now we're going to have this health check. And if we reactivate the port forwarding and we go back over to here, I'm going to reload, go to the liveness probe. And what you're going to see here is it's, you can see the health probes happening. That's cool. Right? It's every three seconds. For, you can see that it's three seconds, there's a three second interval. Now what I'm going to actually do is I'm going to set it to fail. So I'm going to set the health check to return 500 permanently. So I'll say it's permanently failing. You're going to see a 500 in there. And now what you're going to see when we go back over to the terminal is, so if you saw here, there's zero restarts. Yeah. Now if I do a cube control. It's going to be restart every three seconds. There's actually, it's only once because it's in memory. Oh, I see. The fail always is an in memory setting. Got it. So it fails once, but then it comes back and I haven't clicked fail again. So it's helping out. Okay, cool. So it's got one restart. And so you can see there like, obviously it's a contrived example with me setting fail, but if you had a real application health check there. That's very cool. It fails, Kubernetes creates it automatically. All right, so let's burn through some of these questions because people have some questions about going, any plans on using Firecracker for better container isolation or does MS contribute? I don't know what Firecracker is. Maybe you don't know what Firecracker is though. Firecracker is interesting. So AWS recently announced, it's an open source, very thin container optimized virtual machine. It's actually very similar, almost identical really to Hyper-V containers. So we've actually had Hyper-V containers for a couple of years at this point. Very similar idea. Because as I said earlier, containers aren't a security boundary. Right, of course. But the Hyper-Viser is. And so what you can do is you can take a Hyper-Viser, a really optimized kernel, very, very stripped down, very small. And so you can boot up something that looks and feels like a container, but is actually more like a really, really thin virtual machine, so it's secure. And so actually there's a number of projects here, Cota containers by Intel is another one. And you can actually run, so you can integrate Kubernetes with these runtimes. So with actually right now on Azure, you can run using nested virtualization, you can run Cota containers and Kubernetes to have secure containers. Cool. And actually Hyper-V containers is the infrastructure that we can use for something like ACI. So I think it's really great to see this kind of innovation happening in open source. It's great to see people thinking about this. I'm sure that we'll all collaborate on a single container runtime at some point. So that's the way we work at it. Great question. Next one, I don't know Kubernetes containers. Let's say I develop web APIs to connect with our mobile apps. What could be a reason to learn Kubernetes and implement it instead of keeping using what I know and just host the API in a normal web service? I would say if you're happy with what you're doing, you should stick with it. And that's it. I think this is important, right? Yeah, yeah, yeah. Because there are new things come out and we're like, oh, we need to spend money doing the new thing. At what point will this thing that she's doing be like, you should probably consider now using Kubernetes. What are the smells? Yeah, so I mean, I think if you're worried about agility, you feel like you can't push code fast enough or rolling out your software is a scary experience. I've talked to teams where it was like, yeah, we do a rollout once a month and everybody's on call for the 48-hour period. And it's this 10-page long checklist of step-by-step of how I roll out the software. And it's like you're burning the bridge behind you. You can't walk back like you're like step-by-step. If you find yourself in that mode, if you're scared of deploying software, that's probably a good indication that you maybe should think about some of this stuff. If you run into outage problems where you log onto a machine, you make some fix, it restores itself, but then you forget what you did to fix things. And you're developing these machines that are snowflakes. That's a good indication that maybe you should. There's something like App Services. App Services is already kind of immutable and has a lot. So if you're content with the limitations of App Services, that's great, fantastic, stay with it. I think Kubernetes will help you, relative to App Services would help you build sort of more multi-layer applications or take advantage of the open-source ecosystem a little bit more. But yeah, I would do it because there's pain if you think that it will help with pain rather than like, oh, we should do this. We want to be buzzword compliant. You don't want to make pain for yourself. You want to alleviate pain. If it does it, then you should do it. All right, so we just did health check. What was the next thing you were going to show us? All right, so I'm going to show you a little bit about load balancing. So when you're load balancing traffic into Kubernetes, it's this thing called a service. And if we take a look here at the service, the basic idea is this defines a load balancer that's going to target a bunch of containers. And the way that it targets it is this selector. My app is demo. And if you looked at the pod definition that we had before, it has a label right here that says app is demo. So it's like tags. So you tag a container. And then the load balancer looks for things with that tag, and it brings traffic to those pods. And so we can actually go and do, I'm going to actually, I'm going to delete because I'm going to delete the one that we have because I'm actually adding a readiness check. I'll talk about readiness checks in just a second. You were saying? Yeah, so as this is loading, I noticed that in your YAML file, are you defining like, because I'm looking at your code, there's no code there at all. There's just YAML files. Where is the actual, where are the actual containers coming from? Well, that's the image. So the image I built separately, I pushed it separately. So the image repository becomes sort of an abstraction point between the build process and the deploy process. I see. So you do a lot of work to build your image. You test it. You qualify it. You push it into a registry. And then you deploy it using the YAML config. So you really have separated the active building from the active deploying. And that's cool because then, for example, if there's a failure, a health check comes back as bad, it can roll back to a previous container if you tell it to do it. You can definitely do that. And hopefully, we actually have a demo of that too. Oh, let's do it. So I'm going to show you the services first. So we can say, kube control, create. We'll create this container. And what's important in the container actually is, in addition to this liveness probe that we saw before, there's now this readiness probe. And the idea behind a readiness probe is it tells whether or not the thing's ready to be part of a load balancer or not. So one tells you I want to be restarted. The other says, hey, I'm not ready to serve. Maybe I'm loading a big database file. Maybe I'm still initializing and booting up. I wanted you to keep me alive, but I want you to not bring me any traffic. Cool. And so now, we can create that service. And when you create this, oh, it already exists. So I must have left over from it when I tested to make sure the demos were working. And while you're typing this, this is actually really cool because I recently deployed to Kubernetes. And I don't know, someone helped me. Lena, one of my coworkers, helped me deploy. We have a machine learning model that's using GPUs that we needed to deploy. And having a readiness check is actually super useful because I'm loading a pretty big machine learning model. Yeah, exactly. And so I got to put this in. Yeah, exactly. So you see this service here? It's got an IP address associated with it. This IP address is different than any of the containers. So when you target that IP address, you get load balanced out to the containers. That's cool. And actually, if you go back over to our app here, we can actually see in the DNS query, I'll have to restart forward forwarding because I restarted the container. Restart forward forwarding. If we go over here, I can actually say demo service and do a DNS query. And what you see here is that there's a DNS entry for that IP address. So in addition to creating a service to be the load balancer, Kubernetes is also programmed DNS for the containers so that when I refer to demo service, I say connect to demo service, it's going to use DNS to look up the IP address and connect. So I can actually use my service's names in my code to connect my various layers of my services together. Oh, that's cool. And that's just internal inside the pod? Inside the cluster. Yeah, and inside all containers in the cluster. I see. So you might have multiple pods that represent logical units of your application. Yeah, they're grouped by services, load balancer, given a DNS name. And so my front end connects to back end. It doesn't connect to a specific pod. It connects to the back end service. And the traffic is load balanced to all of the containers there. That's really cool. And so actually, I can say we can go back over here and I can take a look at the end points. You can say kubectl, it'll say watch. Is it kubectl or kubectl? kubectl, kubectl. Some people say kubectl. I don't. You heard it here first, folks. No, no, no, no. Plenty of people, reasonable people will disagree. OK. Oops, cancel. And so there's the end points for my service. That's the container that it will load balance traffic to. And they have one replica for right now. But you could have multiple replicas. But what I was going to show you is I've got to go over here and I go to the readiness probe. And you can see the probe coming through. I'm going to set it to fail. So it's permanently failing. It's going to throw 500s. If we go back over here, what you're going to see is in a little bit of time, it's actually going to get removed from the load balancer. So it got removed from the load balancer. So now I don't have any, which is bad, which is why I need replicas. But that entry got removed from the load balancer because it's failing its readiness check. And so if I go back over and I say, OK, let's succeed instead. Let's go back to succeeding. So now it's going to start returning 200s, hopefully. Yeah, so now it's starting to return 200s. We go back over here. It's got added back into the load balancer. So that shows you that dynamically you can remove and add different end points from the load balancer, whether or not they're healthy or not. So you can ensure that you can do things like a zero downtime rolling upgrade of the service. So I can go from version one to version two with user traffic coming at me with no downtime. That's really cool, right? Because my service started failing recently. And now I can go in there and actually respond with, hey, this is not healthy. Restart me. Right. And we can actually give, I actually have an example. Let's do it. Do you have? Yeah, let's do it. Yeah, I do. All right, so this is a little bit more of an involved example. I'm actually going to hide just a more screen real estate. This is going to use a deployment. And a deployment is a way of replicating containers and also rolling out from one version of a container to another version of a container. So here we go. So we're going to take a look at that service. We were talking about services before. So here's the service for my deployment. I'm going to create that service. And then I'm going to deploy. It's a deployment with v1 of my app. And so one thing you'll see here is there's five replicas of this application. Version is v1. It's a really simple app, actually. All it is doing, basically, is it's catting v1 into this index.html. And then there's nginx serving that file. OK. Really simple. Cool. All right, so we're going to deploy that. How are you getting it to type all that stuff? It's like secret mojo. Yeah, so we have this demo script that was built. Because whenever you do demos, you always make typos. Yeah, no, I know. It's true. So it's really nice to have it be scripted. It's still live. It's still doing all this stuff live. But it's scripted, and it runs it through a little tool that makes it look like it's typed. So I use it for a lot of my demos. What's the tool called? Is it auto-hockey? No, it's hacked together with a bunch of little Unix tools. It's a combination of, it's this thing called PV, which is a Unix command line extension. Sorry for the little bit. No, no, no. It's like demo or to demo. It's totally cool. No, I love it. I always feel a little bit bad because I have people come up to me afterwards, and sometimes they're like, wow, you typed really fast. I have to admit to you that it was typed for me. All right, so we created that demo with five replicas, and now we're using, this is Tmux to do everything together. So you can see here, I've V1, I want five to be there, and I have five up and running. And what you're gonna see in this middle window here is it's hitting that, and you can see that the host names are changing, which shows you it's going to all of those different replicas, and it's getting V1 back. All right, so let's actually upgrade to V2. So I'm replacing little one-liner to replace V1 with V2. Man, we set an awk. I know, you can do it, all right. So what you can see here though is my V2 is starting to come up, right? And in here, you're gonna see V2 and V1 mixing in, because now I'm in this mode where, I'm in this mode where I'm rolling out from V1 to V2. So you see mostly V2 at this point. I've got four replicas of V2 running, only one replica of V1. And pretty soon we're gonna get to a place where we're gonna, so I have five replicas of V2, no replicas of V1. So I just did a roll out from V1 in my application to V2 in my application. No downtime, done, minute, less than a minute, right? That's amazing. So, but you know, imagine, I don't like it. V2 is not where it's at, that's not where it's at. V1 is. V1, so we're gonna roll it back. So we just say, Q control, roll out, undo. And now a roll back is really just a roll out in reverse. And so what you're gonna see here is now I've got V1, that desired V1, and this is gonna start, V2's are coming down. Four replicas of V2, two replicas of V1, we're gonna keep doing that. And now you're starting to see some V1s in the load that's going to my service. You're seeing V1s start to pop up. And, you know, in another 15 seconds we're gonna have roll back. So not only did we roll out with zero downtime, we rolled back with zero downtime, all while I'm sitting here chatting with you. If you specify like, is there a way to specify like if there's an unhealthy check on a roll out, just go back? Yeah, so that, well it doesn't do the roll back, but it pauses. So that health check that we talked about, every time it creates a new replica, it waits for that replica to become healthy and ready, and you can actually set a period of time. Like I want it to be healthy for 20 minutes. Just because you know from experience that it takes a while for problems to emerge. And so every time it goes, it creates a new replica, it will wait for that health check to go that long, and only then will it move on. And if the health check fails, obviously if it's failing the readiness check, it's not going into the load balancer. So you're not bringing any traffic to it. And if it fails the readiness check for too long, then the deployment is considered failed, and it aborts the deployment, and you can then have monitoring or whatever to say, hey, something bad happened here, or even automatically say, oh roll back. You can detect it and then issue this roll back command if you want. Depends on sort of who you are and what you're building the application for. But I think it gives you an idea of like, some of the power that's built into Kubernetes. That's really cool, like look, traditionally this stuff back when I started programming was me basically rebooting a server and hoping for the best. Yeah, yeah, yeah, yeah, yeah. No, we've come a long way, I think. And this is pretty amazing. So for those that are new to this, where can they go to find this run through this demo themselves to make it work? Yeah, so these demos are gonna go up on GitHub in my repository, but there's also a lot of really great material on the Azure Kubernetes site on azure.com, as well as honestly on the kubernetes.io website has a lot of great material. There's a great kubernetes Slack channel that for the whole community, like the entire kubernetes, like across the world, there's a thousand, 2,000 people on it live, not just subscribed to the channel, but like live at any particular moment. That's impressive. Which is amazing. KubeCon's coming up in Seattle. Oh shoot, what is that? Next week in Seattle. It's sold out, unfortunately. Oh, you need me to pick up chairs or clean toilets or something? It's at the convention center. 7,500 people come to the convention center. That's amazing. It's amazing. Well congratulations, this is amazing. We've really needed this in software development, I think. Yeah, I think hopefully it helps. I think there's more to go, but we'll keep working on it. Awesome.