Orchestrating real-world workloads with deployments and StatefulSets - Kubernetes Tutorial

- [Instructor] So far in this course, we've run pods, essentially containers, one at a time. A blue pod here, a green pod there. Kubernetes has done a lot for us but this is nothing we couldn't have done ourselves with Docker and some Ansible. In this video, I'm going to start showing you the real power of Kubernetes and its ability to operate software in a way fitting real life production workloads. When I say operating, I mean taking away from us, the humans, a lot of the administrative tasks that come with high scale critical infrastructure and just being faster, smarter and more precise at those tasks than we could ever be. Consider our engine X-based web pod, sitting on a node, serving users. What if it crashes and has to restart? Now, Kubernetes will do that automatically for us but during that restart process, no one can visit our site. So what we need is redundancy. We need another copy running back in takeover. What about if we're in the lucky position that we just have too many users and these two pods can't handle all of that load? We'd need even more scale. In both of these cases, what we want is several identical copies of the same pod. Now, to get more copies of the pod, we could just copy the file that describes it. For each one and we just changed the name so it doesn't clash and then we deploy it. Problem with that is every time we wanted more or fewer, we'd have to do some more of this copy and paste. This is tedious and it's slow and it's error prone. And it's actually not just annoying, it's irresponsible to manage your production systems like this. Luckily, Kubernetes to the rescue. It has first-class support for this kind of replication. What do I mean by first class? Well, I mean that we don't have to piece what we want together from other bits. We don't need 10 separate pod objects and then some other kind of resource and some other. Kubernetes has one resource type that's designed for this and will do exactly what we want. And this resource is called the deployment. A deployment takes a definition of a pod and makes us a bunch of copies of it. Like any other kind of resource, we're going to want a file to declaratively, describe our deployment and then we'll apply that to the cluster. If we go across to the terminal, what I'm actually going to do is I'm going to build one of these up from the definition of the pod so we can see kind of how it's thinking, how it's working. So let's take our green pod from before. So this is called blue-green, but it's running. Okay, it's actually the blue one, it's running our blue pod. And we're going to take this definition of a single pod and turn it into a definition of a deployment. The deployment object is in the API group called V1/apps. The deployment object is in the API group called V1/apps. So pod before was just in V1 and that's actually shorthand for V1/core, which means it's the very core set of features that Kubernetes sort of relies on. But in the apps API group, we have a kind of thing that I've said is called a deployment. It's going to take some metadata, let's give it a name. So this is the blue green deployment. And it has a spec. Now it's spec says how many identical copies of this pod we want, so replicas. Let's just stick with one for now, so it produces the same thing as before. And like a service, if you've seen that video, it takes a selector and this selector matches labels. And we're going to use our standard app, blue-green label. What this selector tells the deployment is which pods it's managing. So when it comes to scale down, it knows which ones it can remove from the pool. So now we've got a selector for the positive being managed and a replica count. All we need is a definition of the pod itself or the pods that we're going to make, the many copies. So we give that a template and here we basically just reuse our pod definition. We don't need the API version all kind because this is not a stand-alone object, it's just a sort of template for making those pods. And actually this thing can't have a name because we couldn't have more than one pod with the same name, they clash. So we leave the name out but it still has its metadata, it still has the label that we want on the actual pod. And this is going to match the selector up here. And it still has that specification of the containers that we want to run. So let me just indent that to make it a child and show that this is the template for the pod in this deployment. So if I've got my YAML right, if I've earned my badge is a senior YAML engineer today, this will be a correct definition of a deployment. So let's try to apply it. I did not get it right. What did I do wrong? Ah, it's probably just a typo. Yes, it's apps version one or version one apps. There we go. Okay, so deliberate mistake aside, what we've got is a deployment called blue-green. And you can say here, it says ready one of one. That means one of the replicas, one of the pods that it's going to make is ready out of one. We can take a look at the pods direct and there is one blue-green pod and it's actually got a random suffix on it to avoid name clashes with the other hundred or thousand or however many we want to make eventually. So we can do the standard declarative kind of workflow in Kubernetes. Let's say we do want little more scale or a little more redundancy. We can go back into this definition of the pod and let's change that replica count to three. And we can keep CTL, apply that file again. And again, configured rather than created. So this specification has been updated in place and now, three pods all with the different random suffix so they don't clash. And you can see these two are new, they're newer than this one. So the deployment has gone and made those extra pods. It saw that we already had one so it didn't need to make three, it only needed to make two. And it's gone and made two extra pods, so now we have the three that we asked for. So this has really taken that sort of tedious and error prone work of copying and pasting and naming away from us so we don't have to do it. To get a better idea of what's going on here, I did say I'm a big CLI fan and there is a cool kubectl plugin we can use to visualize this relationship between the deployment and the pods. Now I really don't have a lot of time in this video to go into kubectl and its plugins so I'd encourage you to read around that. But essentially, kubectl has a plugin manager called krew. So krew is like a package manager like apt or RPM. And we can say, kubectl krew install tree because tree is the plugin itself. This will take a little while on my network, and there we go. So this is a warning. This is downloaded from the internet. I can now say kubectl tree. And we want to look at the deployment and the deployment is called blue-green. And sure enough, here is a tree representation of what's going on. There's the deployment resource. It's made a thing called a replica set, which we don't need to worry about, we'll cover that later. And the replica set has made the three pods that we want and they're all ready. Now deployments are great for services like web servers, where if you have too much load you can just add more copies of your pod. These kinds of services are known as horizontally scalable or stateless applications. Now, not all services work like this, though. Think of a database. You can't just add a new instance of that, it wouldn't have any well, data. You have to coordinate this new member with the other instances to replicate and rebalance the data, tell them which is the leader and which are followers, all that kind of stuff. This is also understood and catered for by Kubernetes through another type of resource called the stateful set. As the name implies, rather than stateless services like a web server that we can just make more copies of, this is for stateful ones. So it too makes pods for you but the pods are all treated individually and they can have different configuration, which is exactly what you need for running services that form clusters or groups and all coordinate together. So they have to be able to tell each other apart, tell leaders from followers from replicas. Now I started off showing you the pod so that we could see the nuts and bolts of the Kubernetes system, but really you should actually never make them directly. Deployment and stateful set are examples of higher level objects, which address real-world scenarios. And you should always use one of these objects in order to run workloads and they will make and manage pods for you. As I pointed out in the resource files that we saw earlier, the API version for pod was V1, which means core V1. Deployments on the other hand, were in apps V1 because they're in a group of resources that help you run real world applications. And stateful sets are now in V1 as well. Now, what we can do is we can ask the Kubernetes server, all the different types of resource that it knows about. So there is a command, kubectl API resources. Now there's quite a big list here. So let's narrow that down to just the types that are concerned with apps. Let's make that a little bit more clear. Ah that's route, sadly. That's really hard to read. Okay, if I come over here, it's a little bit more obvious. So we can see the deployment that we've talked about. The stateful set that we've talked about, that middle replica set object that we don't need to concern ourselves with yet. And there's one more type in here, controller revisions a bit weird but there's one more type in here, which is the daemon set. What the daemon set does, again, it takes a pod specification, a pod template and it runs precisely one copy on every worker node. Now this is a little bit weird. It kind of breaks the abstraction that Kubernetes is trying to offer. It kind of looks through the mirror but it's really useful if you've got something like a cache and you want to make sure that every pod has one copy of this cache close to it. So whichever worker node a pod ends up running on, there's going to be a copy of the cache on that node, which will obviously be much faster and much higher bandwidth than talking to a cache instance that's ended up on another node. So that's what Daemon sets for and that rounds off the set of things that are concerned with apps in Kubernetes.