 Okay. Hello, everyone. We should be live. Welcome to cloud native.tv. I'm Kaz and Fields and this is Fields Tested. I have a few. It's going to be a fun one today, folks. I have a few housekeeping items before we get started. Sorry. I've got to bring up all of my housekeeping items. Okay. So this is an official stream of cloud native computing foundation. As such, it's governed by the code of conduct. This is an official stream of the CNCF and as such is subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct. Basically, please be respectful of all your fellow participants and presenters. Again, this is Fields Tested and I'm Kaz and Fields. And today I have someone very exciting on with me. I have an expert here to teach me something new. Sarah, I was looking for the exciting person. I was just going to say. Mark Mandel, let's see. Let me switch this screen real quick. Okay. Would you please introduce yourself before me? Look, Kaz, thank you so much for having me. Yeah, I'm wearing a onesie today because why not? So yeah, thanks for having me. Hi, my name is Mark Mandel. I work with Kazlin at Google Cloud. I am a fellow developer advocate. I tech lead the gaming part of our developer relations efforts for gaming at Google Cloud. I'm also a founder and a founder and maintainer on a couple of open source projects, one of which we're talking today, which is a Gones system for scaling game servers for multiplayer games and just released another one with lovely friends over in Embark Studios called Quilkin for communications with multiplayer games. So yeah, I do a bunch of stuff to do with gaming and back ends for games and games. That's that's my jam. And I'm wearing a onesie because Quilkin has a mascot called Quillie who's a hedgehog and this is a hedgehog onesie and it just seemed appropriate. I'm wearing my Gones shirt underneath so I can I can wrap. I got to wrap both projects at the same time. It's very important. All right. Well, I was going to ask about the Kikurumi. So Mark told me that he was going to do this before the stream today. So I am joining him in Kikurumi land. Mine doesn't have as cool of a backstory. Well, my mom doesn't need one. It's not important. As long as you have one, it's fine. Yeah. Well, I'm very curious to see how at what point I just overheat though. I think it's going to be fun. Yeah, that part is challenging. But anyway. So I'm going to be running this very interestingly today. I've reset up my workspace for this. So if you see me floundering between screens and things, that's going to be why. That'll be fine. We'll work it out. Yeah, we'll work it out. To explain, Quilkin's tested a bit before we get started. Let me make my ears pop a little bit. So to explain fields tested a bit, we, what I'm trying to do with this show is to give people a chance to kind of see cloud native technologies as close as we can get to what they would be in the field. So I'm trying to do cool projects with them and show you kind of how these things can really work. So what I wanted to do today was to run a game server on Kubernetes. Because that sounds like a really cool use case that I honestly don't know that much about. So, as Mark has described, that's what he's here to teach us today. And another couple of things before we get right into it. Reminder, and I think I have a fancy little caption for this. Yeah. Join us at KubeCon North America. Tickets are available now for both in-person and online if you want to just join virtually. And then the in-person is in LA. If you're able to travel and comfortable traveling, there is an in-person conference going on with KubeCon this year. And if you want to participate in the chat, I want to warn you now that you need to follow. It takes a few minutes after you follow for you to be able to join the chat. So definitely go ahead and do that if you want to chat with us, which I hope you will. Because it's so much more fun when folks get involved. So please say hello if you're out there watching. Cool. So I guess we'll dive into it. Let me make sure that I got the call. Where would you like to start? Yeah, that is a good question. Might have some challenges here today. We'll see. I wonder if I can, hold on, I'm checking something real quick here. Okay. Interesting. Google Cloud is being interesting with me today. That's what we're probably going to use for infrastructure. Anyway, I will go ahead and share my screen, I suppose. Lovely. Which might be a bit confusing for a minute, because I only have one screen for the machine that I'm sharing my screen from today. I made, I made Kazzlin break her regular setup. Because I'm forcing her to play a video game with me and she didn't have a machine ready. I didn't have a machine ready. So it's entirely my fault. Yeah, which is fine. So here we've got a Windows machine that I spun up just for this. I happen to have a little Intel NUC sitting around that has Windows pre-installed on it. You keep doing this. So I went ahead and spun that up yesterday. And this is literally brand new Windows machine that I installed the game that we're going to play on, which I guess I'll bring up now. So we're going to be working with super tux cart. Do you like to tell us about this? Super tux cart is a super cute little open source game. You can play it. You can play it. What's the word I'm looking for? You can play it single player. It's like if you ever played Mario Kart, very much a clone of Mario Kart, but with like Linux characters. And what we're going to do here is we're going to set up a super tux cart instance. We have a dedicated game server and we'll talk a little bit about what dedicated game servers are in a bit and how they work. We'll get some pieces working on that. So we're going to set up, get that running on Agones. And then apparently Kazzan and I are going to brace each other. Okay. Kazzan was aware. I don't know if Kazzan was aware that was what's going to happen, but that was what's going to happen. We're going to have a race. Okay then. Yeah. Also, I'm going to switch my headphones real quick to my other machine because that machine seems to be a little challenging. So I think you were going to, I assume we're running everything in like Cloud Shell and with the Google Cloud Doohickey and the web browser theme above technical terms. I'm here to bring the series energy. Go through those pieces again. I said I assume we're doing everything through Google Cloud Shell in a browser and stuff today. Yes, if possible. Perfect. We can absolutely do that. Okay. Why don't we start? Yeah, we don't need SuperTuxCart yet. We're okay. When we start, let's... I just wanted to show off that that is what we're doing. That makes sense. It's a real game. It's real. Not a fake game. It's not imaginary. I promise. Cool. So one thing I was going to suggest is what we can do is, well, yeah, why don't you go to agones.dev. Let's start with that and bring up a Cloud Shell. I'm going to point you with some docs as well that we have. And reminder for anyone who has joined us. I do not know things about running game servers, so I am learning today. Excellent. So my theory is I'm going to point you at the commands to start the cluster in the particular way that agones is going to kind of need it. And while that's spinning up because it'll take a couple of minutes, we'll talk through some of the theory about game servers and why it's set up in certain ways and some of the challenges and that kind of stuff. Does that sound cool? Yeah. Sounds good. Rock in. So if you pop into documentation. Documentation. Top right. Perfect. And you'll see on the left it says intran, create cluster, and then there's Google Cloud. Sort of very close at the top. Perfect. Yep. Scroll down, creating a cluster. That command right there. That's the one. So this is going to look very similar. There is the thing there where it says tags. It's going to become important to us. And I would probably, I'm Pacific side. Everyone that is. Are you on the same coast as me? I can't remember. Yes, I am. I'm in the Seattle area. Excellent. So if we put this somewhere on the, we're on the west coast, right? I can never remember. Somewhere on the west coast. That would probably be ideal for us because that'll be close to us. Good point. I usually do demos where the latency isn't really important. So. But in this case, it is. In this case, it actually is. It actually matters. That's exciting. So. So let's get into the cloud console. Yeah, let's do it. Let's do it. You can call that cluster whenever you like. Cool. A little cloud console. And. I have another account that I usually use for my demos. Maybe I'll stop sharing for a second while I set that up. Well, you sort that out. Yeah. Well, I sort that out. I have it up, but then it does this anyway. Okay. Stop sharing for a second while I fix that. Problems of having only one monitor. To get to quick breather. Pull my ears off for a sec. So while you're doing that, and I'll let you, I'll let you put on that. I'll tell people some things because it's fun. So yeah, I showed people before agonist.dev as well. So if people want to learn more about this or they're checking it out or they don't know anything about dedicated game servers or they're coming from a gaming background and they're like, I want to learn about the Kubernetes stuff. We actually have a whole section called prerequisite knowledge on the website there that takes you through sort of the levels of knowledge that you'd need for each of the things like, because we build on top of like four different foundations of stuff. Cause like there's doctors and containerization and there's Kubernetes and there's dedicated game servers, multiplayer games. And there's game engines. And so if you don't know about like a particular part or you're like, how much of each thing do I need to learn? Make sure to check that out. It's like the second one from the top on the agonist docs. We pointed some like free and interactive courses for both Docker and Kubernetes. Some stuff about like some articles around dedicated game servers explaining them, some articles around game engines, that kind of fun stuff too. So just letting people know that stuff's there. All right. How are we doing? Doing well. We've got the Google Cloud platform up now. All right. Let's get a cloud shell go in and we'll create a cluster. Cool. It'll take a couple of minutes in the background. We need like little theme music. Yeah, we totally do. So if you paste that command in there and replace that, what was that cluster name or something like with a name, if you want to call it a conez or Willy Wonka, really, whatever you want is fine. Sounds good. Oh no. What? I'm used to using this keyboard with my math. Oh, now it's on a Windows. Oh no. I don't know how Mac machines work. Yeah, there we go. We'll just right click on everything. Yes. If you replace that cluster name with something, we might also need to specify our zone. Let me bring up a notepad. You should be able to go just like up to the spot or this works too. Oh, can I like change it in the documentation? Not in the documentation. I thought you would be able to do it in the shell. But you know what? You do what you feel is right. It's like whatever, whatever's the easy path. Yeah. Cool. And let's let's give it a zone. Like, I don't know. U.S. 1B or something. Sure. So we need to add a dash dash zone. Yeah. And a slash at the end of that line too to make sure it drops the next one. Yeah. I think zone equals U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. U.S. The Cloud Shell, you can specify how big you want the text size to be. Oh, where is that? Settings, the sprocket thingy. Oh, settings. Terminal settings, terminal preferences, text size. Good to know. It tends to be good to zoom in the whole thing. I don't know the thing, that works too. Cool, let's get that running. Yes, so this is the right one, fields tested, got the tag game server. Yep, got no enable auto upgrade as well, that's also important. No, no enable auto upgrade, interesting. Interesting. And what is the scope GKD? That specifies, what that actually does is like authorization scopes. So basically, what can the nodes access? This is what we're writing here is saying exactly the same is what if you created the cluster inside the standard Kubernetes, like the GKE console, that's just like a GKE specific thing. So we're just using the default scopes, it's the default access scopes that you would otherwise have. Okay, cool. And then giving it four nodes, specifying a machine type. And so, of course I have to authorize it. Please let me do that. Yeah. And also just want to be super clear as well, like we're doing this on GKE, but like you can run on any Kubernetes clusters. There's nothing Google Cloud or GKE specific here. We're gonna have to do, if you're running this on either a different cloud provider or bare metal, you have to do very similar things. So I'll just kind of talk through them. All right, so that can run in the background. So let's talk some, I'm rolling up my onesie sleeves here. Let's talk some. Yeah, get warm. Let's talk some. I might need to take it off at some point. We'll talk some theory about while that's spinning up. So, let's talk about, the phrases it usually uses like dedicated game server. So what is that? What do I mean by that? And what does that look like? So, okay, so we're talking about this game super tuxcap where like you and I would be racing against each other. And there's a few ways in which multiplayer games essentially need to share state between players so that when you do something, I see that you do it. And when I do something is you see that I do it, right? Like backwards and forwards, backwards and forwards. Cool, cool, cool. That's like a whole other hour thing. So one of the ways that's like hugely prevalent for doing this is what's commonly, I've heard them call the dedicated game servers, authoritative servers, just game servers as like a very overloaded term, right? So I tend to use the phrase dedicated game server because I feel like that's a good, like phrase that's not used as much. But basically what that means is like somewhere on the internet, there is a process that is running the entire simulation of what's going on inside the game. So if you and I are playing this game racing game, like we've both connected to this dedicated game server, I'm pressing forward and saying like, hey, I'm going forward, dedicated game server gets that command is like, oh, cool, Mark's going forward, that looks good. I'm gonna send that to Kazzling, send that to Mark or send the information. I get the same thing from Kazzling, it's sending the information back and it can tell where we are in the game. If I hit something or I hit you, we can have that sort of interactive experience and it can do the job of basically making sure everything that's happening in the game makes sense and like can be the authority of what's happening inside the game. And there's a couple of very good reasons for doing that. One of which is latency. So we're both playing like this fast paced, like competitive thing. And so we wanna be able to send data and receive data to this game server as fast as we possibly can or at least usually within some kind of limit or something like that. Often 50 milliseconds would be nice. It's usually a good sweet spot depends on the game. So where that game server lives geographically around the world, we have a cluster, where that lives around the world matters. So like we're talking here, right? Let's put it close to us, like let's put it on the West Coast because we're both in the same side of the US and so that we can send data to it as quickly as possible. And by geographically placing dedicated game servers around, you can measure the latency. So you actually have control over the latency experience that each player is gonna have. The other side of it is, it gives you a lot of more control over actually what's happening inside your game because people cheat and it sucks. So if I'm connected directly to you, Kazzlin, and we're playing a game and maybe like we're in some sort of competitive tournament where like rankings matter and there's money on the line. If I have a copy of the client, I can fucks with it. And I can do horrible things and that's no fun for anybody. And it just makes it harder, right? It makes it harder. Now, sometimes that works great for particular types of games, that's fine. But it does, it makes things, it makes things tricky. So that's why we put it close to us and that's why we run dedicated game servers. Now there's a couple of fun things and we're gonna do an extra fun thing before we move on in there too. So there's two things that we're growing on there. So one, we turned on no enable auto upgrade on the cluster. Game servers by their very definition do everything in memory and they're entirely memory persistent as long as people are playing on them, which means that when you and I are playing we usually connect to the same process and it's doing all it's in memory processing and it's sending all it's data to us. With auto upgrades turned on, GKE will just be like this node, I think I'm gonna upgrade it now, which is kind of bad for a gameplay experience because it could just decide to shut down your game at any point in time, which we don't want, that would be unfortunate. It tends to make people post nasty things on Reddit and such. So we don't want that. So we turn that off. The other thing you notice, we added that tags thing we had up there previously. So traditional Kubernetes apps, you have like a service, you probably put a load balancer in front of it, you're doing some sort of HTTP connection, something like that. Perfectly normal grade. Unfortunately, none of that works for game servers. Sorry. Yeah, certain things just go right out the door. So there's two things that happen. One of which is traditionally for a lot of games, we do UDP connections for all communications. We don't use TCP connections. That's basically because by the time if a TCP connection needed to do a retry you actually don't care about the data anyway because it's old in the game and who cares if somebody did something two seconds ago. So there's just no point in taking that retry hit. But also secondly, if you and I are playing on a game server we're connecting to that process directly. So we want to connect to that process directly. Going through a load balancer, then we have to do some routing, there's some extra latency. It's just not necessary and we don't need it. So we put tags on the nodes so we can do our next step which is we actually open up firewall rules to make it possible for us to connect directly to the nodes that are running inside the Kubernetes cluster. So how about we do that? So if you're running anywhere, we'll do it for Google Clouds. If you want to go back to the documentation, again, we're doing this for Google Cloud. It's the same on like any other platform. I think on the right-hand side there's a thing that says set firewall rules, create the firewall, that's what it's called. On the right-hand side, you'll see a little subheading. Oh, right side, got it. Right side, create the firewall, creating the firewall. There it is, beautiful. So that'll give you... So what that's gonna do, I'm gonna just by default. Don't have to change anything. You can just click the copy button. One of our wonderful teammates just put that in there. It's beautiful. Very helpful. Very helpful. Used to being on when it was up here. Okay. It just went, it had a... Oh, there you go. It even had the enter at the bottom. Okay. Apparently. Yeah. So Agones does a lot of the port management for you that like Kubernetes doesn't do out of the box. And one of the configuration options is a port range. And so by default, traffic is UDP. We allocate ports in the range from 7,000 to 8,000. So hence we have a firewall rule that targets all the nodes that have that target that we saw before. You see it says target tags game server. We put that on the cluster. So that's how we route crowd out traffic all the way through. Cool. So far, so good. So far, so good. So far, so good. All right. Oh yeah, suppose we should install Agones. That makes sense, right? That might be important. Yes. That might be important. So Agones is what we would probably call a like... What are we calling those these days? I want to say controller or like operator. That's the word I'm looking for. So Agones installs some custom resource definitions as well as a controller binary that looks for those changes and the stuff. So I will send you back to the documentation, please. Yeah, and maybe we should explain a little bit about why operators are awesome. Yeah, that sounds like a fun thing to do. So operators are just straight awesome as a thing. They just are. So yeah, they just are. So Kubernetes is like straight awesome in its extensibility and the way it allows you to do stuff. So if anyone here has played with Kubernetes, you've probably seen stuff like pods and deployments and services and that kind of stuff. Kubernetes is awesome in that, like I refer to those as kind of like, they're called resources, but they're like kind of these nouns, right? Like there's a thing, I have a deployment. What allows you to do what's commonly referred to as like custom resource definitions is basically allows you to specify like, hey, I want to write some software that has its own nouns. So these own YAML or config definitions that I can add to the system. And what's awesome about that is, not only does it like add them to Kubernetes, but it adds it to your Kube CTL commands. It adds it to the Kubernetes API itself. So everything there like just gets extended natively and we'll see some of that in a bit actually and I think that's sweet. And then you can add these things commonly referred to as controllers that are basically like, hey, I'm just going to go keep an eye on these new nouns that you created and I'm going to do stuff. And really, whatever it is you want to do is kind of up to you, but you can do all kinds of stuff and it's pretty neat. Yeah, I basically think about it as teaching Kubernetes to take care of the kinds of things that you care about. Your specific application. And instead of thinking of it in like standard Kubernetes terms, you can teach Kubernetes to think about it in the terms that make sense for your application. Absolutely, no. And that's a great way of putting it, I think. Because really what this is doing is Agones teaches Kubernetes how to understand game servers and the life cycles they have and some of the problems they have of the way they work, which is slightly different. We can dig into those too. Awesome. So next steps, continue to install Agones. Yeah, install Agones. Do you want to install via YAML or would you like to install via Helm? That's a good question. I haven't used Helm in a while. You know what, let's do YAML then because it's the easy option. Let's do YAML. You can see the commands there. Okay. So it creates a namespace for the Agones system. You don't need to worry about that, that's fine. That's basically that command there. So create namespace and then apply this YAML. Yeah, just install random YAML from the internet, it'll be fine. That sounds good. Yeah, yeah. Also, if you could just curl bash some stuff while we're at it, that'd be great, thanks. Maybe not. So we've created our namespace and it's now applying many, many things. All kinds of fun stuff. Nice. So actually, oh, do you want to dig into some of the stuff that got installed? Is that fun? Sure. Okay, so if you just have a look at, let's have a look at the CRDs that are now in the system. Okay. Let's see if you can get CRDs. CRD, I assume we will. Yeah, you might want to reset that back to the top of it. Oh no, there we go. So you can see, actually there's some at the top there. So you can see there's game servers.agones.dev. So now it understands about game server CRDs. We have this thing called fleets, which are big groups of game servers. We'll talk about that. There's, we have some fleet autoscalers. So we have some autoscaling capabilities and some other stuff as well. So you can see it all under the agones.dev sort of domain there. We have some, we have some new stuff. So what this means is you can type kubectl get game servers. It's not going to return anything because it doesn't exist, but it will understand what it means. Yeah. Like if I was using any other Kubernetes cluster where I had not installed agones, it would not know what I was talking about. Exactly. But now it knows. But now it's out? That's magic. And just for funsies as well, you can also do like, if you want to do like get pods inside the agones system namespace, you'll see the other things that are in there too. Yeah, gtl getpo-n. We can do that, right? Yeah. And agones namespace. You don't need to. Agones. That works. It's agones-system. You might have tab completion in Cloud Shell. I can never remember if it installs it or not. It doesn't look like it. There we go. There we go. So you'll see a few different things in here. So the agones controller is the controller we're talking about. We also install a few other things like the ping service is, we're talking about latency. So we have like a little service in there for, like it's an echo service. So you can see how far away the cluster is. So you can measure that latency if you're running multiple clusters, which you probably would do in production. The, I thought. Sorry. I'm so sorry. I'm so used to this. That's okay. If you want to scroll up a little and let people see a little bit higher and just the thing overlays. I don't know if you want to get rid of that. Join us at kube.com.na at the bottom. That's a good point. I should do that. That would probably make that a little bit clearer. But anyway, but we have some other things. The allocator is another service for doing allocations. We're going to talk about that in a minute too. Well, my name's still there. That's okay. So all right. So we have everything installed. Everything's running. Good. Demogods are with us. All right. So I want to talk a little bit about a couple of other things. Actually, you've got the example files. Handy, I believe. Yes. On this machine though, in Cloud Shell, that might be problematic. Yes. We will need them. Yes, please. That would be great. There's a, yeah, if you go to GitHub, you can, there's a GitHub link. It works. So we'll grab some, we'll grab some examples. Cloud Shell, that was so convenient. It is. Sorry. Just the way it works for me. Git clone. And then I'll give it, I will use just paste there. That works. Okay. And yeah, main branch will be fine. I'll add down three examples. Do, do, do, do, do, do, do. Okay. So I should now have that. Give you a bonus. Yes, please. Any examples? Examples. Yep. And there should be a super tux guide in there. Super tux guide. Yeah. We have a bunch of examples in there. Uh-huh. I actually control feed correctly. Yeah, excellent. You know what, it might be fun. Actually, if you want to open the editor and we can actually have a look at the, the, the examples that are in there. We might have a peek at some of the files. I can talk to you about how some of that works. I would do that. I haven't done that one. Big button that says open editor. All right. It has the actual words there. Who does that? I'm here for you. I'm here for you. Yep. And we go into it. Gones. Examples. Super tux guide. Might control minus here a little bit. Maybe a little. Maybe just a touch. Yeah. Clutch on full view. That looks pretty good. Clutch on full view. Okay. So which example? Here we go. Super tux guide. Yeah, it's open up. Oh yeah, we can do that. That also is maybe interesting too. Sorry about the docking problem. Yeah, sure. Why not? So there's a, there's a couple of interesting things in here. So what was I going to say? So when you integrate with a Gones game servers, their lifecycle is a little bit different than what, like a traditional web servers or even maybe even a database to a degree in that sometimes they're kind of big and sometimes they take a while to spin up. The super tux cut Docker image, I think it's about a gig in size. So usually what we do is we need to be kind of aware of their lifecycle and usually they're kind of self directing, like a game server knows a lot about itself and how it works. So we have a, what we have is an SDK that we integrate with our game servers to enable you to do things like a game server might spin up, but it turns around and says, hey, I'm ready, which means that I'm like ready to be able to be, have players on me. It also does stuff like pass into the game servers configuration information. I can actually do stuff like change labels and annotations on myself, things like that. And so what we need to do here is take the super tux cut example and integrate our SDK into the system basically so that we can say, oh, it's ready. Like it's, it's booted up. It takes about 10 seconds, 20 seconds or something to come up. So we do a little bit of hackery here and we write a little bit of go code that will actually fires, it fires up the super tux cut example and it looks at the logs and looks at it for a specific line in the logs. And there's like, oh, you're ready now. Cool. I can mark you as ready. So you can see here where like, there's a go lang go builder. Like we build this wrapper first and then we do all the stuff to actually compile super tux cut and install it and make it go because yeah, for various reasons we had to actually compile this one. I had to compile up a fork on mine. We need to upgrade the super tux cut but this is probably a terrible, terrible example of a Docker file for this. Usually your Docker file is gonna look very much like it would do normally but here we have to do a little bit of hackery to get stuff to work. But here we're compiling from source. We compile SDK, yay, and like pull that in and then we do all that. So we're using that, that builder pattern inside Docker and then finally, I think we just boop, boop, boop. Yeah, then we have like, we bring in all the SDK, super tux cut stuff. We have the wrapper and then we have just an entry point as age that starts everything up and takes it from there. So this is essentially gonna run our super tux cart server side. Yep. Part of the game. Yeah, so it's gonna run the whole dedicated game server. Dedicated game server. As we talked about earlier. Yeah, and we were talking a bit about how like kind of these are a bit slow. So if you want to open up fleet.yaml, what you, yeah. So what you normally do is game servers is you usually just kind of run a bunch of them, kind of just leave them warm, lying around to sort of respond to that. There we go. We leave a few lying around warm so that when players are actually ready to play a game, they're ready and just kind of sitting there. So we have a concept of fleets, which are basically just groups of game servers, a certain number of game server. So here is a fleet where we're saying, hey, let's have two of them please. And then if you scroll down like, yes, we have two game servers run of those. We can do auto scaling. We're not gonna do that today. We have some health checking details in there too. But basically then we're just like, hey, here's the details of the container we want you to run. And if you're super familiar with Kubernetes, you actually have full access to like a pod spec. So if you wanna do volumes or config maps or any of that kind of stuff, multiple pods. Like if you wanna do a full like side cars and all that kind of stuff. But it does, Agones will do the job for you of like, it runs a side car that the SDA connects to, it spins it up, manages the pod lifecycle, all that kind of fun stuff to make sure that it's up and running. So we can create this fleet if we want. If you wanna go back to a shell, we're gonna open your terminal again, we can have a look at that. If anyone has questions about any of this stuff, please also drop that in chat. Yeah, please do. This certainly sounds like something that Kubernetes would be good at running. Yeah, so if you wanna like, Kube CTL apply that fleet. Get that going. Fly to something. Got YAML because I'm already within Agones examples. Super tech stuff. Yeah, so yeah, so just dash F it and... Dash F. So this is like exactly what you would normally do inside Kubernetes. You could do all this stuff in through the API too. I can't see anything about what it just said. Oh, yeah, because it's tiny now. Well, now actually it's just because it's at the bottom. If you wanna reset your terminal and check it back up at the top, that would be the happy noise. Yay. So yeah, you can get your fleet. So you can see that there's currently two, two are currently desired. They're not ready yet. If you do a Kube CTL get game servers, it actually shows you a little bit of a nicer. There's no like alias for that. Oh, GS, GS works. GS is, yeah, GS is game servers. Awesome. There you go. Give it a short hand. I guess Kubernetes is easy. Yeah. So they're currently in scheduled state. So they're kind of big. So if you actually, you can Kube CTL get pods and see the pods that are happening behind them. But Agones is doing some of that work there. All in default name space. Yeah, we're all in the same name space. Yeah. Yeah, it all goes around in the same space. So if you just get pods. It's like getting pods. Yeah. So, oh, they're up and running. So if we get game servers again, they should be ready. Beautiful. So they're in state ready. They've come up, the SDKs worked. You can see it, they have an address that's actually looked up the port, the IP address of where the node is. They've been allocated a port and the right routing. It happens for you as well in there. But we need to do one extra thing. So the special thing about game servers that are kind of different about, about like say web apps or even a databases is they do this kind of fun thing, which is like right now, we have no players on these games, right? So if you went and deleted one of these game servers, nobody cares. Because they're essentially stateless, right? Like there's nothing on them. It's running, it's fine. As soon as we have players playing on that game though, we have in memory state that we need to make sure that we keep around. Because if you delete them, then bad things happen. Games get interrupted and no one's a happy camper. So we have this, how are we doing that? Yes. So we have this concept called allocation in Agones and we kind of deviate from like the declarative like Kubernetes model and port of more of an, in imperative, we basically hack it a little bit and do an imperative thing. If, how much time we got? Yeah, we can fit this in. So if you want to pop back over to the editor, I'm going to show it to you in YAML. You could do this in like a Kubernetes to the API. There's a game server allocation. It's the one just below that. Okay. And we have a bunch of selectors for here but basically here, what we're doing is we're saying please give me a game server. In this case, the label is matching to the SuperTuxCut fleet that we just created. Like, please give me one that's ready right now and do it for me atomically. And so that means that I can point this at say a fleet or any other sets of game servers that have labels and I can safely just retrieve a game server out of a set. It will get marked as allocated which is like our special state for like, hey, we have players on this, don't touch it. But it means then also I can do things like edit my fleets and do rolling updates on my fleets for the game servers I have while doing allocations and know that that is safe because that's what the system does. It's kind of one of the special sources of Agonis. Huh, cool. So I'll get you to type something kind of fancy. We'll go back into the terminal. We're going to make this allocation happen and we'll create an allocated game server and then we'll play a game. So we'll go QCTL create but you can only create these resources actually. Yeah, since it's not declarative. Yeah, and we actually don't store it at all. If you want to go down that rabbit hole of how that works, it's kind of fun. So if you can go dash F. Create dash F. You can do more about that later. Yes, that's a fun one. So dash F and then it's game server allocation. So it's that game server allocation file, allocation. And then I'll get you to go dash O YAML. So it'll create it but it'll also give us back the YAML output. Now you usually do this through an API but we can do it here which is super nice. So okay, perfect. So if you want to hit enter a few times just to make that come up a little bit we can see some details. Thanks. Perfect. I'm here for you. We get it working. So here we can see we get back allocation worked down the bottom in the status there. You can see we have the game server that got allocated what node it was on. It's ports, details, the IP and address. If we can actually just do like Qubectl game servers go up again. You can see one of those is allocated now and the other one is ready. Yeah. Sweet. So that's the special one. Let's play a game first but the thing we can do now and we can maybe do this a little bit later is we can do stuff like scale this down up and down. We can even scale it to zero. That allocated game server would stay there. So it stays safe until it specifically is like, hey, I'm done. Well finished. In which case then you can actually like do it. So the thing it's really doing is going like, okay, I have in memory eight. I need to stay alive. Please keep me alive until someone like very specifically says that we shouldn't play this game anymore. Are you ready? We used an operator that changes the state of its items. We do some fun stuff but the most important question is, are you ready to play a game? I hope so. All right. A little worried now. Okay. Right. All right. So how do we do this? So I actually, I can start mine up too. So let me. So we're both going to connect to this game server. Yes. On this IP or how do we connect to this? With that IP and the port that is seven, two, five, one. So you can actually take the whole thing. It'll copy pasting quite nicely. If you just grab all that stuff and all. And then you can start. Let's try it. You can start super tux cut. Oh, actually I should probably copy that myself before you switch. Or actually we can do it at the same time. When you bring up super tux cut, I can copy your details. That's a good point. I can do that. Okay. So I'm bringing that up. I've never played this game before. So. It's very, it's very silly. Like the controls are just the keyboard. Space is to fire the stuff you find. And I think the V is to jump off the top of my head. So if you go to. Oh, you have to create a user, really? Apparently. Oh, that's just, that's just silly. What happens if you just go offline account? Why don't you do that? Offline account. Yeah, just local name, Kasselin. That should be fine. I think that'll be fine. Let's try it. Yeah. Then go into online. Online. And there should be enter server address. There we go. Enter server address. Okay. There we go. So if you paste that in there, let's see if that works. Perfect. You want to put a colon in the middle? Yeah, exactly. Yeah. 230.20.155. Let me get this right. 175. If more folks join us, if they're watching on the stream it can happen to have super tux cut. So if you click okay. Okay. Perfect. Boom. All right. So you can see we're both in there. Are you? We have a question in the chat. So game server is an actual Kubernetes object. Sorry I joined late. Looks like I missed the cool part. Yes. Yes. Once you install a Ghana's game server is a Kubernetes object. And you can use all the Kubernetes tools to look at it. We can actually describe it. We can even play with some of that stuff later if you want to. You can see all the details that come through. You can look at the YAML, all that stuff for sure. Yeah, we talked earlier about how Ghana is basically functions as a Kubernetes operator and teaches Kubernetes how to run game servers. It's a custom resource definition. Gonna click start race. Oh. I choose a cart. Which cart do you like? I'm partial to tux myself. Oh, I like this blue and pink thing with the little hat, because we've got our little hats. There we go. Gonna put the head back on for the race. Oh, for the race? No, that's very important. I agree. I agree. I'm gonna choose that. I'm choosing, I'm selecting this track. By the way, you just asked earlier that his Kegurumi actually makes sense because it's for an open source project. Mine doesn't. But oh gosh, we're doing it now. We're ready to go. You ready? Here we go, up. Oh, I'm doing it. Yay. By the way, I played Mario Kart for the first time, like, not that long ago. No, I'm doing terribly. What is happening? I am going the wrong way. What happens if I go the wrong way? Well, I win. Bad things, I guess. Oh. I want good things to happen if I go the wrong way. So we are playing right now on a dedicated game server that's hosted on a Kubernetes cluster that's running in our US West data center. Yeah, and he just lapped me real quick. Not fully lapped me, but. Where did you go? Go on, go on. Here you go. You let me catch up. I'm that bad. It's good for the stream. It's good for the stream. Do I pick up the banana peels or do they banana peel me? I think the banana is a bad. Okay, that's what I thought. We want to pick up. Oh, and how do I throw things again? Spacebar? Spacebar. Oh, well, I missed you. Oh, what was that? Was it a giant bowling ball? Oh, no. It's a giant bowling ball. No. Oh, it came back for me. This is the important part of the stream, though. Yeah, so everyone just tuning in. This is really the important part. This is the important part of my stuff we did today. That was an acorn. I may have played this a couple of times before. Yeah, I have not. I won't tell you that. I don't know what these canisters are. Oh, can you like boost? Turbo boost somehow? Can you? I'm like way behind now. Oh, no, what have I done? Ha-ha, I won the race. Are we only doing one lap? Yeah, I just said what? I figured it was a quick game. We play a quick game. Test game. Test game. Okay, I'm going to shut that down. I am now the owner of the server. I was already the owner of the server. Oh, because I left. I left. I just connected, so now you own it for if you want to play again. I can play again against myself. Exactly. That's okay. I think I won't do that. Anyway. So if you actually, if you close that, actually I'll show you something cool as well. Okay. So close super tux card? So close super tux card. I can't speak today. Words are hard. Say that 10 times fast. Exactly. So if you have a look at the game servers we have available now, you might see something interesting. Okay. Ptl get game servers. So this is the game servers that we were just on. Oh, it hasn't happened yet. So usually super tux once everyone disconnected and it may take a second. After we've played a game, we'll actually shut down. See if it's done it yet. Nope. It's fine. Usually it does. Maybe because you hung out for a little while. Maybe. Sometimes I use AI agents and it may do it. But what I was trying to say was, actually we can do that. We can do this instead. If you want to QPCTL delete that top game server, you might want to scroll up a little as well. Oh yeah. Thank you. That's all right. Yeah. Okay. And then I'm going to QPCTL delete this. That's fine. Yeah. See me it's still there. Control V. You'll need to put. You'll need to put. This is not my usual setup. You'll need to put GS before that word or game server. Oh, right. So it knows which resources to get rid of. But pretty much the same. I'm just a similar thing that I want to sort of point out here. Like the same ways you would have with a deployment, a fleet make sure that it has the right number that you've specified of game servers running at any given point in time. Right. So if we have a. Control C out of this. Yeah. Cause it'll take it a minute otherwise. Shouldn't take two. Oh, there it goes. There it goes. CTL. It means those. Yeah. And so you can see now we have two, like we specified in our fleet that we have two. Now we are back to having two. One of them is only nine seconds old cause it just took a little second to come up. And they're both ready. And they're both ready. They're not allocated. They're not allocated. We could then reallocate. There's other fun stuff we could do here. Same way as you like normally would QTTL scale. You can do that with a fleet as well. So we're going to scale it up or scale it down. We can do fun stuff like if you wanted to like allocate one game server and then scale it down, we could do that too and see like there's some. Like you can see that the allocated ones stay there so that the in memory things that people are playing games on don't go away unless they're explicitly gotten rid of. We do all kinds of fun stuff there. So there's, that's the quick run through of Agones and playing a game. What questions can I answer? What fun stuff can I tell you? What else can we talk about? All kinds of fun stuff. I totally want to try this out with some friends later, just run my own server just like we did here and then try it out with them. What are some cool things that I could maybe do to mess with that setup or explore some new things? Something fun you could do. We do have a fleet autoscaler set up. So right now we have a static set of like the static set of numbers. So like here we said we want two, we have two fleets but like if you have more than two games going on then suddenly you don't have any game servers left. So within a single cluster at least if you want to scale your fleet autoscaler fleet up you can install a fleet autoscaler. It has a few different options there. We have like a simple buffer which is like, hey, keep like 10% or five new game servers always ready and available above what you currently have. We also have a web hook option. So if you want to do your own custom autoscaling you can. What's also cool though is we integrate with the Kubernetes cluster autoscaler. So we integrate with that so that the autoscaler can't get rid of running game servers and we manage that for you when we do a bunch of work in that. That's a whole other fun thing about how we do that. But that means then that you can scale your fleet up and if you go over how big your cluster is it will increase in size. And then we do a lot of magic and tricks to pack everything together in the cloud so that when we scale a fleet back down we leave behind empty nodes and then the autoscaler can clean and then right back up again. Interesting. So that would work really well on Google Cloud because it has cluster autoscaler capabilities included but other cloud providers it works a little bit differently. Yeah, but it's the standard Kubernetes autoscaler. Like we all use that open source one that's like the common one. So and that has, we adhere to all the specific rules about how that works. So it works across cloud providers, it works everywhere. As long as you have the standard Kubernetes cluster autoscaler, it all works. So I need to have a really big super text cart party. Yes, yes you do. Absolutely. Absolutely, excellent. Absolutely. And I wanted to learn a little bit more if I could about how it stores state and how that can work in different environments. What kinds of storage do you use with this? Do you use like separated cloud storage? Could you talk a little bit more about that? So when you talk about state are you talking about like we were talking a little bit about like how the different states for game server resources, or are you talking about if my game server itself has data about players or like things that are inside the game? That's more what I'm thinking about. Though you can tell me if that's the wrong kind of state to think about. No, no, they're both interesting state. So game servers often have a bunch of data that come with them and I've seen like the, it's a fun problem of like really big Docker images. And I've seen a few different patterns. It's been kind of interesting. So some people ship just really big images like one gig, two gig, five gig, I've seen 30 gig images, like they get really large because they have that kind of stuff. A lot of people will offload a lot of that data to say like a volume map or something similar like that to like a persistent disk of some kind that's like locked into the machine or locked onto the host. I've even seen tricks where people will take that that data and even the binary and store it in a memory mapped file on the host and then volume map that into the container and run it that way. It does kind of break the ceiling or break the glass a little in some of that isolation that you'd get inside a container. But when dealing with some stuff at really like that big level, sometimes that's just necessary. As well as that usually, yeah, you'll connect to a database of some kind or some sort of backend service that you probably have that says like, hey, what players, like give me the player information or like, hey, this happened inside a game. I need to tell you that this person now has this particular loot or they won this achievement or all that kind of stuff. So there's all that kind of stuff that usually happens. Looks very similar, traditional, like either microservices or monolith kind of application where you're sending data, HTTP, JSON, like, or GRPC or anything other similar in that kind of way. It looks like that. Some of the peaks and troughs on load look a little different, but otherwise the backend architecture can look quite similar. Interesting. So there's a few different ways to approach it. Sounds like. Yeah, there definitely are. I've even seen people, like if people are doing like lots of iteration loops, building their own sort of chunking mechanisms for shifting data like in and out. So I want to like a volume map or something so that they're only pushing the changes rather than like the entire 30 gigabytes every single time. So it just depends on what your iterative cycle looks like, how big your game is, how many assets you have, that kind of fun stuff. It's an interesting problem though. Yeah. I mean, that's one of my favorite areas to talk about within Kubernetes is what happens when you have an application that needs to store some kind of state and what kind of storage do you use with that? How do you connect it into the application? Where is it located? All of those problems are really interesting. Yeah. And it becomes fun in games because you're usually dealing with this in memory monolith and like how do you deal with redundancy? Usually it's about sort of snapshotting important moments in the game, like making sure that if the thing crashes, do you still have that loot that you got given before? Okay, you do. So I lost, you know, some time in game, but I still have my, I didn't lose too much, but yeah, redundancy and sort of in memory state is a fun problem. Games are such an interesting use case. There's so much that goes on with them, especially this latency thing, like we were talking about earlier. Most of my use cases don't really have any latency needs. Most of them are demos. So there's that. But when you're talking about games, latency is super important, so. Absolutely. Yeah, yeah. But yeah, game servers for sure, for other parts of games less miller and less and more, but like, yeah, it's all depends. So it's fun. Yeah. Cool. So we're at two, I don't wanna keep people for too long. So I'm gonna go ahead and stop sharing. All right. So thank you everyone for joining us today. Let's see, there's some other shows going on on CNCF TV, cloud native TV, whatever we're calling this, this week. We've got two more tomorrow, I think, which I have notes on somewhere. Say those real quick. Just wanna list them all. Oh, just one more tomorrow. We have LGTM featuring OPA with raw code. So that should be really interesting. I know I need to learn more about OPA. More stuff about operators too. That should be very interesting. Thank you so much for joining me, Mark. I learned so much. Thank you for having me. It was a pleasure. It was an absolute pleasure. Thank you very much. Awesome. And Field Sesa will be on again in two weeks. Should be. I'll see you all then. Bye.