 All right, I have one o'clock, so I'm gonna get started and try not to go too loud. So this is gonna be containing chaos with Kubernetes. My name's Terry Ryan, I'm a developer advocate for Google. That means I spend half my time working on top of Google Cloud Platform and then the other half of the time going out and talking to people about Google Cloud Platform. I'm not gonna be talking about GCP a lot today, I'm gonna be talking about actually an open source project named Kubernetes. But before I get into it, I kinda like to know who you guys are. So who here spends most of the time doing development? Who here spends most of the time doing systems or ops work? Who here's what had their hands up both times? Okay, is that because you like DevOps or because your bosses hate you? Which, yeah, okay. Anybody here, before I make more boss jokes, anybody here actually a manager and tells people what to do instead of doing it? Okay, all right, I'll keep that in mind. Anybody that didn't cover any front-end devs wandering here? No, okay. And who here has played around with Docker? Awesome, okay, good. So I can skip the container justification part of this. Who here has played around with Kubernetes? Okay, all right, cool. All right, so I can skip the pre-intro and I'll go straight to the interaction. All right, so why Kubernetes? What problem are we trying to solve? So imagine we have an application that we've brought over to containers, right? And it's a simple app. I've got a front-end and services running on a Nginx PHP box and I have a back-end that's running in MySQL. And my app looks something like this. If I get more requests or if I get more demand for my service, I can up the number of containers that are running and this is pretty simple, easy to manage. Now, someone comes around and points out to me, hey, this isn't good container hygiene for lack of a better term. Containers should do one thing and do one thing only. This is doing two things. It's running services using PHP and serving up HTML, JavaScript, CSS. So these are two separate tasks. It'd be good if I separate. So cool, I can just change this to be just services and I can change this to be just Nginx. So just serving up HTML, JavaScript, CSS. And so now my environment looks a little bit more like this. Great, someone also will point out that containers are supposed to be ephemeral. And when you think databases, ephemeral is the word that comes to mind, right? So this is suboptimal to undersell that. So what we do is we add some sort of persistent storage that lives outside the container architecture so that even if my SQL box goes up and down, the actual data stays intact. So now my environment looks a little bit like this that if I need to scale out on the front end, I can do that. If I need to make replicas on the back end, I can do that. But this is a lie, right? Because this is an abstraction. It's an abstraction, not a lie, right? This is still all running on a single machine with single processor and whenever you see single, well, maybe not single processor, but single set of processing, single set of memory and disk space. So if something were to go wrong, this whole system would come tumbling down. So we start splitting it up and now we've got multiple Docker hosts or multiple container hosts. And if one of them goes down, I have to figure out what to do with those container hosts and move them over. And so, wow, that's a lot to manage, right? I've added a lot of complexity in my environment, but I haven't necessarily gotten a lot of advantage out of that complexity. I'm still, basically, I'm managing a layer of VMs that run a layer of cluster services or some sort of container services like Docker, and then I'm running all these containers on top of it. So I've added extra layer of management and I didn't get a lot to show for it. So Kubernetes is, we think, an answer to that problem. Kubernetes takes a little bit different approach. You basically give it resources. You say, these are nodes that you can use. And then you say, here are my containers. I'd like to run four of them, three of these, two of these, and just keep them running. And Kubernetes will manage splitting them up on different nodes. It'll handle if one of the nodes goes down, migrating all the pods to all of the containers to a different machine. It'll handle all of that. So we call this a container orchestration system. So that is what Kubernetes is. It is open source. It was started by Google. So about 10 years ago, we started an internal project to move all of our stuff to containers. And that, if you ever read any papers about Google, about internal infrastructure, it's a project called Borg. Now Borg is a really good project, but it runs on our custom hardware. We have hardware that's built just for us to run all this stuff. And so it doesn't make sense as an open source project. So the team behind Borg wanted to do something greenfield, like let's learn from our 10 years of mistakes doing this. Let's kind of start with 10 years of knowledge. And then let's do it on commodity. Let's not worry about the hardware. Let's worry about the hardware instead of just, it's one set of hardware that's all we have to worry about. We have contributions from a lot of others. The big ones are Red Hat, CoreOS, IBM, and even Docker. So we have ongoing contributions from other people. And so now to get started, you really need to get into the concepts of what moving containers is about, especially when you start managing large amounts of containers. So has anybody heard this metaphor before, cattle-nut pets? OK, so when you talk about cattle-nut pets in terms of containers, what you're saying is a pet has a name. And it's unique or rare. You give it personal attention. And if it gets ill, you stay up all night to make it better. And we can see this directly in servers. We all gave our servers, like, I might need 12 of them some day. So I'll name the first one Aries. And then I'll expand out. Like, we all did that with names. I see people laughing, so yes, you did. So this is one way of managing servers. The other way is cattle, right? Cattle has a number. One is pretty much like any other one. If you lose one, you just replace it with another one. You run them as a group. You're not really concerned about any individual one at any one given time. And if it gets ill, you make hamburgers. I realize close to the UK, and we've learned, do not make hamburgers from sick cows, right? So make a leather coat. But the idea here is like, if something goes wrong, you don't care. Now, this requires a little bit of a change of architecture. You need to do things like move state out of the individual server. So you manage state via some sort of shared system. But pretty much once you move over to this, this is pretty self-explanatory, right? If you've got a system that can heal itself, that can deal with outages, it's really a lot easier to manage, especially when you have a large number of them. The other concept is desired state. Now, desired state is something that we talk about in contrast to we call it imperative style. And imperative style is just like a fancy word for scripting. So in normal scenario, you've got to build script, and you create a whole bunch of Docker images. And then after those images are created, you're going to start up the front ends. And after you start up the front ends, you start on the back ends, the services layer. And then after that, you start up the back end layer. Probably want to do this in reverse, because a lot of times this will throw errors if this isn't up. But you get the order right. And then if something goes wrong, if one of these machines was to explode, if I don't do anything, nothing happens. Someone or something has to come in and take over that process and start up a new box. Desired state looks at it a different way. It says, I want three front ends, two services, and one back ends make it happen. And then it just happens. They all just start up. And again, you have to change the way you do things. And so this guy might start up before this guy. And that's fine, because you write your code here to do progressive connections to the database so that if the database is down, but it's going to be up in the future, your app can handle it. And then if one of the machines goes down, without doing anything, the system will bring it back to life. So this is desired state. And what I liken this to for a metaphor like Cat on a Pets is employees not children. So if you have employees, you know that you have a tough day at work. It could be an employee, it could be a coworker. And you say, hey, a tough day. Go home. Get some sleep. That's all you have to do. Your coworker, your employee will just go and do that. They might not go right to sleep. They might do some other things. But the idea is the next day they're going to come back and be rested and be ready for work. Children, on the other hand, those of you that have children, know that this is more of an imperative process. So you say, go upstairs. Get undressed. Put on your pajamas. Brush your teeth. Pick out two stories. Those of you without children might be wondering, are these steps really necessary? And I'll tell you, look at these steps. If you don't tell them to go upstairs, you're going to end up with a naked child in your living room. And much like a script failing, you're going to see things that you don't want to see. For some reason, children love naked gymnastics. And yes, you can't unsee those things. So that's desired state. OK. So now I'm going to go through this. There are a lot of pieces to Kubernetes. There's a lot of names and a lot of entities and structures. So I need to go through and define them. So I'm going to try to get through this. At the end of this, I'll have a demo showing Kubernetes actually running. And that'll be good. But I'm going to get through a little bit of like, this is this thing. This is this thing. This is this. So we start with containers. We think of containers as being subatomic particles of Kubernetes, in that you don't have anything that's actually just a container. Containers are part of a bigger organizing structure. These are Docker files, just like you're used to. And in fact, when I develop apps to push onto Kubernetes, I develop locally on Docker, get my Docker files all good. And then I just have to write additional configuration to get them around on Kubernetes. But I can switch back and forth between Docker and Kubernetes with the same Docker files. So the first what we call the atomic particle is pods. We have a pod can be one or more containers in the same pod. And they'll share IP address, namespace, and disk. So it's important to note that all the documentation will say one or more containers, one or more containers, one or more containers. But the truth of it is that a lot of my projects are just one pod per container. Couple examples of this, like why you would do this. The canonical example is what we call sidecar, where again with good container hygiene, you're going to separate out something like web serving from file syncing. So if you have a web server that's serving up HTML, JavaScript, CSS content, but it gets regularly updated from somewhere, you're going to write the web server to just be a web server and then write a separate Docker file to be just the file sync. Put them in the same pod, and then they'll use this shared disk space to transfer the files between the two. There are a couple other patterns here. Like let's say you've got a monitor or a logging system that requires the logs in one format, but you have an app that only spits them out in another format. You would use it instead of rewriting the Docker container, you would just create one that changes the logs and sends them on instead of having to rewrite the initial system. And the last use case for this I like is say converting it all in one box. So not any of you guys, right? But we all have a friend who spun up a lamp box at some point for an experiment. And that experiment became mission critical like a year later. And now you've got a lamp box that you absolutely have to keep running, but it's a mess because everything's pointing to local host, but it's like a house of cards. Again, no one in this room. We know people that have done this. So what you can do is keep all the code the same, keep it all pointing to local host, but separate it out into different Docker files, merge them into one pod, and then you have your system kind of maintained. And then as you go, you can start slowly ripping these pieces apart in a controlled manner. So that's another good use case for pods. So here's what a pod looks like. I'm going to use YAML because I feel like the PHP community is pretty good with YAML. If there's any hidden node people here, you can also use JSON, because sure. But I feel like YAML's a little bit more readable. This is what a pod looks like in configuration. A couple of key things to point out here. It is a type pod. We give it some names. We set ports on it. And then we point it to an image. Now, this is pointing to a custom image. But I can easily just point it to Docker. If I don't have a URL here, I just put the string for the Docker repository. It'll work just like the from at the top of the Docker file. So now, no one ever spins up pods. You don't pods. Everything else creates pods. But for the most part, you don't create just a pod. And it's because a pod has no concept of desired state. A pod doesn't know how many of it should have to run, any of that sort of thing. You need another control structure on top of that. We call them controllers. And the only one there is is replication controllers. Now replication controllers do three things. They observe. How many of these pods do I have? Does it diff? How many am I supposed to have? And if there's any difference, it's going to act. It's either going to spin up pods to meet a deficit or tear down pods to meet an overage. Like if one of the nodes lost network connectivity and then rejoined, you'd have extra pods. So you take them down. Here's what a replication controller looks like. You'll notice everything on the left is pretty much the replication controller configuration. And over here is a pod configuration. So it's embedded right in your replication controller. So it's exactly the same. Set up a couple of things, give it a name, give it some label so it can find the pods that it needs to. I'll explain those in a second. And that's pretty much it. Now, there's also this other thing called a replica set that are exactly like replication controllers. They have a slight little difference. Replication sets can do a little bit more. It's a recent change, and the reason why I point this out is because a lot of the documentation is going to say replication controller, replication controller, if I can say it three times fast, I can't. But replication replica sets are probably what you want to use going forward. So anywhere in the documentation you see replication controller, you can just sub in replica set and use that. But no one spins up a replication set. You spin up deployments. So deployments are a control structure on top of replication sets. And here is one for basically a basic replica set. You see, from a definition standpoint, it's a lot shorter and a lot more succinct. And that's why I like them. So here's my pod specification, a lot thinner than it was before. And the rest of it is just, again, a lot easier. So talk about containers. And containers are ephemeral. But in host names and end points should probably not be ephemeral. So how do we connect those two things? We connect them using services. So services are something I define. It's a number of pods that are going to work together. It's the same thing. And it gets a virtual IP address. Now this virtual IP address can be public or it can be private. So my MySQL server, I want to be private. My web front-end API URLs, I want them to be public. And then you can use these to expose the application, to expose the components to other parts of the application. So my PHP code is going to reference the service for MySQL. And that's how I'm going to connect them all up. So here's what the service looks like, pretty easy. And from this, because it's type load balancer, it's going to try to get a load balancer. And it's going to try to get, if you're running on a cloud provider, if you're running on AWS or GCP or I don't know about Azure, it's going to get the load balancer that's available from the platform. If you're not, if you're running on-prem, you have to set up a little bit more information. You have to point it to an IP address to get that load balancer. So throughout this, you've seen labels in my different definitions. Labels are arbitrary pieces of semantics that you can put in. For here, I have app, tier, and environment. But you can set these to anything. And they're basically just key value. And what they allow you to do is they allow you to select things into services. So let's say in app to do front-end prod, I've got three pods. So what I would target is for a service, I would say serve up everything that is to do front-end pod off of this service. And then if you want to go broader than that and target individuals or whole stacks or whole levels of your app, you can do that. You can isolate by prod, or you can isolate by tier. Last bit of just me talking about definitions and stuff is networking. So pod IPs are all routable, meaning that any pod can talk to any other pod over the internal network. This is in contrast to Docker, where you have to go up to the Docker host and get a connection between the two pods. You don't have to do that. If you have the actual IP address, you can just talk directly. You usually don't usually talk to a service, but there are cases where you'd want to do that talking directly. And this communication can happen even across nodes. So they don't have to be on the same physical hardware to be able to talk to one another. OK, so I went through a lot of definitions. So let me sum it up real quick. We start out with containers, but you don't ever actually spin up a container because you have to use pod. But no one ever actually spins up a pod because pods don't have desired states. So you do something called a replication controller, but no one does replication controllers anymore. You do this thing called a replic set. But you don't spin up a replic set directly. You do it through this thing called deployments, and you serve this all up through services. Simple, right? Easy? Straight forward? So I actually showed the slide later, too. There's a reason for all this. I understand it's complicated, but there are a lot of moving parts to this. This is a very complicated thing that we're trying to do. So there are a lot of pieces to it. So one part of the why is that it is very complicated. The other part is this. This is the contribution logs for June 1st to 2014 to 2016. This is a very active project, and it's still very much in motion. We try very hard not to deprecate things, but we're moving fast. Just to give you an example of how fast that is, a couple months back I did a hackathon trying to get first time contributors into Kubernetes. It's something that you guys probably have experienced here at DrupalCon. And so you sit people down and try to get them to do a pull request. And the goal is to get pull requests. And so afterwards, I was kind of like, how did we do? And I went to try to count up how many, and I figured it was easy, right? Count the number of pull requests on that day. Look at other days and see how different it is. And I figured like, one, two, or three a day. And then we see 10 a day, and we know that's the outlier. The average day of pull requests on Kubernetes is, it averages 30, with a low to high of 20 to 40. So I couldn't actually report how well we did. I had to go back and actually talk to people instead of looking at data, which you know how much that bothers us technical people. So yeah, so that's why this is this way. So now I'm going to do a demo of Kubernetes in action, keeping in mind that this is a live demo using cloud services, and that's like acting with children or animals, right? Like it's prone to problems. Before the demo in my hotel room, I set up a Kubernetes cluster. And then I set up a persistent disk for MySQL. And then it created multiple Docker images, and then pushed those Docker images up to a Docker repository. The reason I'm not doing this live is that on a best case network, it takes two minutes. And most of that time is here, pushing Docker images up to the repository. And hotel Wi-Fi or conference Wi-Fi, like 10 minutes. And as much as I'm sure you would love a 10 minute of just files pushing up, I feel like it's not that entertaining and I could skip it. So we'll start with a cluster already built. We have a simple app. I have not split into three tiers. It's just two tier, PHP, front end, with an API. It might equal back end. And I know this is going to shock you, because you've never seen this before, but it is a to-do app sample with Bootstrap, right? Like no one's ever done this before. But it's a simple app, and it helps kind of show off how this works. All right, so let's demo it. So let's clear all that. Oh, I don't want to clear that. There we go. That's clear. All right, so here I have a visualizer. And what's going to happen is as pieces of the environment come online, they're going to appear up on the screen. So we can kind of track what's happening. I have a simple make file that I'm going to use instead of typing all the commands by hand, because this is how I type. That's not really good. And we're going to see it should have been up two front ends and one MySQL back end, and a service for each of them. And so I'll explain as we go through some of the make, deploy. And we'll see those commands are firing off. And we should see these pieces start coming up here. So green is a service. The yellow is a pod that's not up yet. MySQL takes a little bit longer than PHP. And you'll see I've got two services here. I've got this light green one, which is private. I've got this dark green one, which is public. It will get a public IP address, but that takes a couple seconds on top of this whole process. So now we're up and running. What's that? I can't see them yet, because they're not on the public network. I can use kubectl get pods to look at my list of pods. So I have a bunch of pods running. They're all running. Now while I'm waiting for the public IP address, I said that we don't like pods. And if they go away, that's totally fine with us. So what I'm going to do is I'm going to kill one of the pods. It helps if you spell the commands right. There we go. You should see in the interface, one was deleted. And you'll see that it went red, disappeared, and then another one came back. Why did one replace it? Why did I killed it? Why did it come back? Exactly. Someone was listening, all right. So that's a really quick example of showing how desired state works. I'll actually show the front of the app to show that it's not only is it live, but I have preserved data in it. You'll see that I've done this in a couple different places. Let's add Dublin to the list here. There we go. There are, right there, hello, Dublin. All right, so I have my app, but let's start fooling around with some stuff. So the first thing I want to do is let's say I'm getting more load, and I need to change the number of pods. So I'm going to have it. There we go, yes. I'm going to edit the front end deployment. So I can just go right in. I don't have to do this all through shell scripting. I can change the configuration, change it live. Yep, I'm going to go back here. I added a third replica, and a third replica comes up. So I've got my app, I've got it running, but now what happens, right? Code changes, right? Because no app ever stays. So how do I do updates? Well, normally you rig up some sort of rolling update system, maybe some A-B testing, and you can do all that through Kubernetes. I'll just do a rolling update. So let's talk about a code change. Someone came through and said, hey, bootstrap is dead. This whole light interface is lame. We'll go with the dark interface, and I'll completely revolutionize the app. All right. So I made a code change, and that code is all CSS. I created a different, I changed my Dockerfile. I uploaded it to the repository. That's what I did in my hotel room. And so now I'm going to push to that new image. I'm going to make update, and let's see it run. So what's going to happen is it's going to pop open. You'll see it's taking some down and loading some new ones up. The dark front ends are loading, and there we go. We just switched over, and we now have the new system live. And if I go to this, we'll say, there we go. Cool, everyone now will use my to-do app because it's dark and hip. All right, so that is kind of a quick overview. Oh, and if I need to roll back, whoo, sorry. If I need to roll back, I can just reissue the original deployment, and it'll roll back. And so in a second, there we go. And boom, back to the new one. Now I can change the timing of this. I can set different thresholds for how much overlap there can be, but being a live demo in front of people, I want it to be fast. So that is Kubernetes. Now I had a slight moral quandary. And that is, is it pandering to do a Drupal on Kubernetes demo, or would that be cool? What's that? Yes. OK, he says yes, but do it anyway, which is exactly what I thought the answer would be. So I'm going to panda away. So I'm not going to. Yeah, what's that? OK, so I'm going to launch Drupal, but I'm going to launch a couple other things, too, at the same time. And I'll explain what I'm launching here. So I have a version of Drupal. I have Drupal 8, but I realize that a lot of people are going to want to run legacy versions of their apps. So it would be nice if I could also run Drupal 7. So I have a Drupal 8 instance. I have a Drupal 7 instance. I also have a node instance. And I have a, what's that really ugly thing you guys all don't like? WordPress. I have WordPress in there, too. Sorry, I was, again, I'm pandering, right? So I'm trying to really drive that wedge. So I have all these, so basically in the same environment, I'm able to host all of these different apps that are set up. And when I get the public IP address, I'll show you what they are. Now, how do I do the Drupal install? Basically what I did is I pulled down Drupal, the live, like the Docker image for Drupal, pulled it down onto a Docker host on my own machine, ran through a setup, and then froze the settings, pulled them out, and made them part of a Docker file, and then also pulled out my SQL and made that part of a Docker file. So I could push not just a Drupal instance, but a Drupal instance that I had set up and had the way I wanted. So let's see here. We'll start with this Drupal instance. What's that? It's 8. This one is 8, yeah. And then 7 is still waiting. 5 demo with network attached. Any questions about this why I wait for these to spin up? Just to clarify in the picture you're showing now, the gray boxes are containers. The green ones are services. And what are the six layers in between those you were talking about? The six layers in between the pods. OK, so each one of these is a pod. I have a replication controller. I'm sorry, I have a deployment with a replica set that's starting up the number of pods. And then those pods are served up by the services. The replication control, there's no real like the replica set. There's no real visualization for it. It just happened to know that it's running. Does that make sense? Kind of. OK. Where am I losing you? So you withlisted container pod controller replica set deployment service? Yes. The layers of abstraction. So we got services, we got pods. You would use either a replication set or a replication controller. I'm not using a replication controller. Replicasets are defined by deployments. And so I'm using a deployment with a replica set to maintain the number of pods. And in this case you have a single container inside each pod? Correct. I only have one container per pod. OK. Under what circumstances would you want to do otherwise? I listed a whole bunch in the beginning. It was, there are a couple of patterns. Sidecar is the main one I went with, which is you've got your container split up. You've got a container that's just doing one thing, serving web. But you need to do something with sync the files. So you put two containers in the same pod so they can share the disk space. So the sinker would pull in the files and put on the file system. But it's only doing one thing. And then the web server is only doing one thing. So each pod gets a disk? Yes. OK, that's the disk. OK, that's the part. All right. OK. Thanks. All right. So now we have IP addresses. I'm hoping that stuff. OK, Kubernetes came up. And you'll see here that I have my Kubernetes demo that I already put content into, all ready to go. Here's Drupal 7. I didn't put any content in it, but I did start it up. There's Drupal 7. Here's my simple node app, which is a fight among a bunch of coworkers on trying to tell people about their relative creepiness and what they're doing. So we start out with the lowest level, which is Christopher Walken, which seems like it might be creepy, but you're probably OK. Then Gary Busey, creepy laughing bear, right. And then the final level is Ewok Stroking a Child, please see HR. Tell them what you said or what to do and have a good life. And then the last one is the simple WordPress one. So the same sort of deal. I had to freeze the data and the settings configuration out of my Docker file and upload them. So there you go, running five different environments, along with my original app, all ready to go. So I'm going to clean. And we'll go back to presenting. All right, there's Drupal Menors. Yes. OK, I'll repeat the question. How does Drupal know where its database is under all this setup? And that is, in my code, I write it to point to the service name that I'm going to give MySQL. So MySQL has a, the service name I gave it was MySQL-Drupal. And so in my Drupal code for host name in the settings, I put MySQL-Drupal, and that was all I needed to do. And then the network, basically, Kubernetes runs a DNS server on the inside. You make a request for that host name, and it translates it and sends it on. I'll take one last question, and then I'm going to move on. No, no, I'll take one last. The question is, can multiple pods talk to the same service? If that service is something that can handle multiple requests, right, like a MySQL server, absolutely. We talk about files, it's a little bit more complicated. There are ways of doing it, but services, there's not the way to do that particularly. So, question I get, is this the right way to set up a database, where we're running a database on containers and Kubernetes? I feel responsible that I have to like, not really. The way I have this setup, remember this whole thing, just this, which is only part of the Kubernetes setup is confusing, but there are other pieces to it. And one of those pieces, I'll explain here, so here's how I have my service setup. I have a replica set, I have the replica set to one, because MySQL is greedy, it won't share the same disk space, so you have to have, they each have to have their own disk, so I only want one MySQL server, and I have a service point up to it. The correct, er, way of doing it, is to do something called a Petset. Now Petset can only have one pod per set. There are a couple other features to it, that, like in this case, it's sort of a one-to-one, one's just as good as the other one, but if you're running something like Mongo, where you have multiple pieces that have the exact same configuration, but have different stat eye, like you've got a master and a replica, you can set them up within a Petset with an identity, master, replica one, replica two, and Petset will manage all of that for you. And that, that makes it a little bit more clear that it's a pet. Why is mine not using a Petset? For a couple reasons, one, I have doubts. If I today was setting up a Kubernetes app, I don't know that I'd run MySQL on Kubernetes itself, it makes a great demo and helps explain all the concepts, but MySQL is a pet, right? Like it's not something that we can just blow away and everything's okay. The other part of that is that Petsets are not available on the version of Kubernetes I'm running, because it's running on a production version that doesn't support alpha. Petset was an alpha until Monday, so I didn't have a chance to update everything with Petsets yet. So Petsets, yeah. So how would I do this today? Today I would probably run all my front end on Kubernetes and my back end on me being a Google Partisan. I would probably use Google Cloud SQL to run that. Would I someday move to that? Move to doing it this way? Sure. Would it be through Petsets? Probably. Am I gonna ask myself a series of questions and then answer them to look smart? Absolutely. So that's just a little bit about the database there. There's a couple other things we talked about. We talked about rolling updates, we talked about persistent volumes. There are a couple other things. Whoa. That we should get to one of secrets. Secrets are cool. They, you basically can configure a secret, something like a username and password. These are base 64 encoded. If anyone can crack these in here, you are terrified. Just do it with your eyes. So you set these up and they're so they're obscured, but you still don't wanna put them in a repository or anything. But then you can push these pieces of data directly to the environment variables of your containers. You can also do them as a file system. They'll be available in the file system, but I prefer environment variables. That's how you reference them. There's also this thing called a horizontal auto scaler, which is kinda cool. Up until now, I've been saying, make there be three, make there be four, and I have to manage when that changes, which is not very employees versus children. So, we have this thing called a horizontal auto scaler and what that allows you to do is it will monitor processor utilization and as your processor utilization gets too high, it will spin up more pods to handle the load. Now, it's important to note that this will do pods, but not nodes. So what's the difference? Pods are inside Kubernetes and nodes are what Kubernetes runs on. So Kubernetes can't make itself grow, it can just make its pods grow. So let's say you get enough resources and you keep getting pods, eventually you'll hit a limit to the amount that your hardware can handle and it'll just stop spinning up new ones. This is what these look like, they're pretty basic. I set a target percentage utilization, I can set min, I can set max, I don't have to set a max. I don't know if you have, I'm gonna get away with, I think it defaults to one anyway. If you don't set that, you don't set min. And then it's gonna say, it's gonna try to keep your processor utilization on your pods at 80%. So if you aren't running very high, you have no usage, it's gonna drop it down to one and then as you get usage, it's gonna ramp up until it meets that target. Okay, there's a lot more to Kubernetes, but as you can see, just the simple explanation is pretty complicated, so I left out a bunch of things. There is certainly logging and monitoring, you can plug in certain applications. There are some kind of suggested things that we recommend in that space. There's an event interface, there's a web interface, so you wanna manage it, not be a command line, you can do that. It's a thing called config maps, which are like secrets, but they're not secret, so they don't have to be obscured jobs. So you have not a long-running process, but just work that you wanna spin up some containers to take care of and then spin down when they're done. You can do that with jobs. And then my favorite, ubernetis. This is actually now, it's got a boring name of Kubernetes Federated Cluster, but I think ubernetis is cooler, so I'm just gonna keep using that. And if you talk to anybody in the Kubernetes community, they'll understand what you mean when you say ubernetis, ubernetis. So right now, you have a cluster and the pods can only talk on that cluster. With ubernetis, you can connect multiple clusters to each other so they can talk to each other and share resources and share pods across that. So let's say I have a data center here in the UK, sorry, sorry, sorry, here in Dublin. I forgot where I was for a second. You have one here and you have one in the US. You can split them across those two and have them talk, but let's say you have some of your work on prem and some of your work on AWS or GCP. You can actually split across those cloud providers. So you can basically move, distribute your load in such a way that you can get really good uptime on all of your services. So this comes up comparisons. How does Kubernetes compare to all of these different technologies that are also in the space? So let's start with Docker. Docker has this thing called Docker Compose, which allows you to put multiple containers on the same local host. Also, I'll point out here that I am reasonably proficient with Kubernetes, but I am by no means an expert with Docker. So if I say something wrong here or out of date, I'm wrong or out of date, I'm not lying. But feel free to challenge me on it. Docker Swarm is a cluster of container hosts that do replication, orchestration, and scheduling, but as of the last major release of Docker, this is now part of the Docker runtime. Docker also has Docker Machine, which allows you to manage remote container hosts but also launch container hosts in several clouds. So Docker takes a very unix-y approach, like individual apps that do one thing really well that you chain together. Kubernetes is a super set of these abilities with not being able to launch container hosts in several clouds. Actually, you don't launch them, but you can have them in several clouds. But also as a routable network, scheduled jobs, petsets, auto-scaling, secrets, and config maps to this whole scenario. Also, I really have to point out, and really have to call this out, Docker's logos are much cooler than ours, and I'm a little bit jealous, a lot jealous. And then the next thing is Mezos, is the other thing that I get asked about most, which is a machine, a multi-machine kernel allows you to turn a data center into a giant logical single system. It can do containers, but that was not its primary purpose to begin with. It can do a lot of other different things. So in comparison, Kubernetes is strictly for containers. You can't do the super set of what Mezos can do. It also has strong opinions on surface discovery and logging and other pieces. And it's important to note that you can run on top of Mezos. And in fact, up until a little while ago, the only way to get auto-scaling of nodes, so you can pod auto-scaling, but you couldn't auto-scale the hardware, Mezos can actually give you that ability if you run Kubernetes on top of Mezos. So the other way to get this, that auto-scaling is container engine. So up until now, I've been talking about developing on top of Kubernetes. So what's it like to run on a fully functioning Kubernetes system that's already in place? Let's talk about getting started with Kubernetes itself. So you set up a cluster, right? Now you choose an infrastructure, you can choose Google Cloud Platform or AWS or Azure or Mac space on premises. I certainly have my opinions about which one you should choose, but you can choose whatever you want. Then you have to choose an OS. We go with Debian, but you can use any one of these other ones. CoreOS is another great one. And then you have the provision machine. You have to install boot VMs, install all the cube components, get them all ready, and then you have to set up IP dress ranges and services and SDN, and then, God. You've got to do DNS logging and monitoring instead of all that stuff. And then you've got to still manage the hardware after that and like deal with hardware failures and OS updates, or you go to Google Cloud Platform, there's this little button right here that does all of that fully, right? So, there's certainly reasons to run Kubernetes on-prem or set up your own environment someplace, and I'm not knocking that. But when you're trying to evaluate whether or not this works for you, that's a big hurdle to overcome. So do this to evaluate whether or not it works for you and then decide whether or not you want to go on-prem or AWS somewhere else. So Container Engine is hosted Kubernetes. It's got a few smart defaults that like you don't have to worry about DNS or you don't have to set up any of that. And it's great for dipping your feet into. Also allows for node auto-scaling. So you can set up a completely auto-scaling as usage goes up, pods will increase until it hits the limits, and then your nodes will expand, and then as load goes down, it'll shrink, it's looking for the right word. We also have this thing called Container Registry, which is a hosted Docker repository. What's great about this is you can make it private. So you've got IP that you're wrapping into your Dockerfiles and you don't want to share them with the world. You can put it on this, it's private. And you don't have to use it with Google Container Engine. You can, but if you use Container Engine, you need to use it, but if you want to use it to secure your Dockerfiles, you can. So I'm at the conclusions part of this. So let's bring it to a close. First off, Kubernetes is open source. I know that you've been deluged with, you know, contribute to Drupal, so I won't bang this drum too loudly, because you guys may be at the saturation, but we'd love to get involved. Kubernetes.io is the website. There's the GitHub repository, and then IRC channels and Twitter. Roadmap. So I was showing Kubernetes 1.3, which came out in June. Actually, it came out in July. That target was soft. That's when we released Kubernetes, Petsets, and Alpha, and this thing called MiniCube, which we'll talk about in a second. We released Kubernetes 1.4, it was targeted in September. Came out September 26th or Monday, so I have to point out that they actually hit the target that time. They're really actually really good at hitting the target. They're usually within a month of what they say, and they do that four months out, so it's pretty good. There's a whole bunch of Kubernetes polish, makes federated clusters a little bit more usable. Improvements to Kubernetes install process. So I may have been exaggerating, well, no, I wasn't exaggerating that. It just, that step where you install Kubernetes is less painful than it was. I did not make it as painful as it used to be. Improvements to documentation, scheduled jobs, which we added this time around, and a whole bunch of security, not issues, but improvements. Basically some security settings that you can set on pods to make them a little bit more secure. 1.5 is the next target to release December 2016. It's still forming, because we released 1.4 on Wednesday, so it takes a little bit of time to figure out what the target will be. More AWS support is on the docket, so you can run Kubernetes on AWS just as easily as you can run it on prem. But AWS has some features that actually would improve the process, and we can take advantage of that on the Google side, because we control the whole thing. But with AWS, we're adding those features as we go. So things like making it easier to pull down load balancers, making it easier to use several of the distributed disk systems. So basically making it less, or making it more automatic on AWS, so to make that experience more like it would be on Google Cloud, as opposed to on prem. Moving alphas to beta, moving betas to GA, bugs will be fixed, right? So okay, so now if you like Kubernetes, but you're like, what the hell am I getting into? This is a lot to do. I really recommend Container Engine. Google Cloud Platform has a free trial, it's $300 for two months. I am not a salesman, I would like you to use it, I don't care if you pay for it. My bosses sometimes have a problem with that, but that's the role that's been set up for me, and so I'm going with it. So use the free trial, test it out. Set up Container Engine and use it on the free trial, and what's great about the free trial is that when you hit your limit or you hit the end of the two months, we don't automatically flip to charging you. There's a little button that says, hey, you're out, do you want to continue, but you'll be charged for it now. So we really like that. So please, feel free, try it out on that. There's another option is Minicube, which will set up a small Kubernetes cluster for you on VirtualBox. So I'll finish with this, that Google has been developing and using Containers for the last 10 years. We had to deal with ridiculous amounts of growth. We grew 10 times in the first six months. Think about that, six months, you just started a company and you now need 10 times the infrastructure you needed when you started. We have had that growth curve, not quite that severe, but for a long time, and so we have looked at Containers to eke out every single cycle from every single processor we have, and that's what it's done for us. It's really allowed us to scale. Everything at Google runs on Containers. Gmail, web search, MapReduce, even Google Cloud Platform VMs are actually running on Containers. Nah, containers tell them what to do. Actually, no, I've been proven wrong about this. VMs technically run on Borg, so they are running on Containers, so it's turtles all the way down, right? You're running Kubernetes cluster on a VM that's running on Borg, so it's all the way down as Containers. We launch two billion Containers a week, so we've done this and we believe in it and it has had results for us, but so I wanna make it clear that we think Containers are the way to manage scale. It's also the way to manage quick deploys and better isolation, and there's all these reasons to use it, but we highly recommend it for scale. I think you should carefully consider whether it actually, running everything on Containers is right for you. There are a lot of use cases where it doesn't work. If you've got a single VPS and you're not growing, you've got like just apps that are just sort of there, do you need to move over? I don't know. So I want you to carefully consider, is Containers the correct solution for you? Are you dealing with problems of scale? Does it solve deployment issues for it? Does it do isolation for you? Don't take away that the Google guy said you should run everything on Containers, right? You should carefully consider whether running Containers is right for you. That I'll say thank you, and if you want to get the copy of the prezzo, it's there at that bit.ly link, and I'll say thank you very much. I've got a few minutes for questions, so I will take some questions. Oh, I got one right away, all right. Actually, I'm trying to make two out of it. First one is performance. So if I run locally, it's like the Docker Container itself don't need that much performance while I'm not using them. So if I have like three to 14 in Drupal instances, and the second one is also related to maybe having an application or a website locally. So developing locally has a slightly different, okay, now lights off. All right. Slightly different configuration than on production. So can you imagine some kind of test dev production as well as local stage stuff? Okay, so the first question is how is performance? Performance on Kubernetes is going to be comparable to Docker performance with the caveat that you, well not the caveat, but the stipulation that you can add as many processors as you want. You can add as many nodes. You can make the nodes as big as you want. So performance, I haven't seen performance on Kubernetes being a problem for people that are moving apps like this over. At the very large end, we have some very large customers that yeah, they've run into performance issues every once in a while, but we're working with them and for the most part they're manageable. And it's a case by case basis. Second question is how do you deal with different environments? Well, there's two approaches. You could do what I do and do Docker images locally and never change Docker images between Docker and Kubernetes. And I highly recommend doing that so that you can pull down a test very facially. But you wanna do a testing rig, you wanna do a QA rig, how do you handle that? One would be Minicube, which would definitely work for you. The other thing is with labels, you can create within your actual cluster a dev and production environment or a staging environment. So you could dev and do, I wouldn't dev on Kubernetes just because dev remotely is a pain, but you can do staging and QA on the actual cluster itself. And the only difference you would have is individual environmental things that you can do through, you can eject through configuration. All right, any other questions? Yeah, step up for me. I haven't used Kubernetes, but I played around a little bit with Docker Sword mode in the month well. And there is a small problem with external volumes. How is this handled? For example, your MySQL container. How is this handled? So on premises, there are a couple different drivers that you use to connect to local large storage collections. On a cloud provider, we have connectors that will connect to whatever storage mechanism that cloud provider uses. So for example, on Google Cloud Platform, which I know about, we use just Google Compute Engine disks that you spin off just like you normally would a disk, you give it a size and just point to it. On AWS, there's a comparable thing and we do it, but I don't know a lot about it because it's on AWS and I don't know how to play around with it. But it's a pretty, it's just an easy configuration. And in fact, I'll just show it off real quick. So here at the bottom, oh, sorry. I know it's dark, so I apologize. But basically I set up a volume and say MySQL persistent storage, the PD name, the disk is MySQL disk. And then up here, I have a name to MySQL persistent storage that I'm mounting to this path and that handles the mount for it. Does that make sense? This is the equivalent of the Docker Compose YAML file. Maybe. Here's where I point out that I'm not an expert Docker. I just know this. Okay. But feel free to reach the, stop me afterwards if you have a card and you can ask the question. Like if you email to me, I can research an actual answer to you. All right, well with that, I think I'm gonna end and say thank you guys very much. I'll be around. Some of you saw me out smoking. I will probably be out there again. Thank you guys very much.