Part of the advantage of container based applications is the ability to break them up and connect them as services. Another is to keep development, staging, and production as similar as possible, so you can migrate between them with little or no change. For this Kubernetes adds tools called deployments and replica sets that allow you to separate and manage your build and run environments and scale them as needed. With these tools you can easily roll out common deployment such as rolling updates, canaries, and blue greens. Now, let's take a look at what you can do. >> Let's keep on talking about Deploying Kubernetes. Deploying Kubernetes and rolling updates. One of the really, really awesome parts about Kubernetes is that, okay? So let's talk a little bit about it, okay? Deployments really rely on ReplicaSets to manage and run the pod. Deployments allow you to basically name a set of pods to ensure that the number and the state of the pods run and in an equal manner and desired number of states of pods that you have indicated within your YAML file or your configuration itself, okay? Behind the scene, what happens is the deployment relies on these ReplicaSets to manage and run any given number of pods at any given time. In this example that you see right here, there's a deployment that says, hello. When you create the deployment, it's going to create a ReplicaSet, equal size 3. When you add the label selector on there, app equals hello, it'll say inside the pod, you have a single image and you call it hello1, simple example. As the deployment is monitored, the cluster, you'll see whether anything is going on, whether it's different and how it's defined. And if there's anything that's different, the deployment tries to rectify it. In this example on the left-hand side, you'll see that it says ReplicaSet, 4 replicas, selector, and the application again, hello. For the example, it creates a deployment with replicas of 4, like it says there on the left hand side. Only three replicas will be running. The deployment objects and the differences between them will be defined in the API. And what's running in the cluster will be defined and rectified if it needs to by running another pod somewhere else in the same cluster. If you have three pods and one of them goes down or for some reason something happens, remember we talked about being unhealthy, okay? Then the node went down, and there was a problem with the node. It upgrades it, and takes it down by the system. And then finally, another pod will be generated and rebuilt somewhere else with the original state, the original segment. So it will keep three pods running, or three replicas, better yet, running at all times as you can see. Again, rolling updates is one of the really, really awesome things, and developers love this, okay? Rolling updates, well, they allow you to granularly update and gradually update one image version to another image of the version without any disruption to production. Deployment really rolls out and triggers only if it meets the deployment and it meets the pod template. And then yes, it changes the version. For example, if you have labels or containers images, templates and updates, the update will roll over and scale the deployment. And you don't need to trigger any roll out, it'll do it basically on its own. So we're going to use kubectl itself to command and apply these changes to the pods. And you're going to give the pod two versions to the images, so the pods as you could see, you have one ReplicaSet on one side. They're both, one left hand side is hello1, right hand side is hello2. And then the deployment is going to create a second ReplicaSet, like I said, hello2, and then create the pods and the second ReplicaSet. As it shuts down the pods in the old ReplicaSet, it'll keep on doing the same thing to the new ReplicaSet. And now we have a completely new version of an application rolled out, it did this during production. All the APIs were requested and changed, and the deployment now is sitting on version two instead of version one, and no service interruption again. Nobody knew about it. It really happens under the covers, very well done.
