Welcome to our next lecture. In this lecture, we are going to be talking about the strategies for updating of our applications. Once we have deployed our applications, our workloads to our Kubernetes cluster, updating them becomes a huge part of management of our applications. Kubernetes offers us a number of ways of simplifying this process. Within Kubernetes, these are actually two main ways of how we can implement strategies for updating our applications. The first way is actually using our manager. If we have managed pods, we can use, for example, the deployment. If we are using the deployment as the manager of our pods, the deployment itself offers us a number of strategies to help us with deployment of our pods. Then we can actually use the Kubernetes router or some routing strategies to manage rollout of our applications. Let's take a look at the deployment strategies first and then we'll take a look at some advanced routing strategies later. Within our manager of our pods, there are two main strategies that we can use. We have the rolling strategy and the recreate strategy. Essentially, let's take a look at how that would go within our Kubernetes cluster. We have a very simple image. Let's imagine that we have a deployment over here which manages an application, which has three replicas. Right now the state is over here. This is our three replica application, which uses the Version 1 of our application. Essentially, what we want to do is have zero pods here and all of the pods here. What do we want to do is move all of the pods from Version 1 to Version 2. Let's clean that up for a little bit. Again, all of these pods are managed by our deployment. We have two deployment strategies; we have our rolling strategy and our recreate strategy. Let's take a look at our rolling strategy first. When we have a rolling strategy, what happens is that let's assume that we have updated our deployment. For example, we have issued Cube CTL edit of our deployment and it's changed the image of our container from the Version 1 to Version 2. What happens is that Kubernetes is aware of this change and tries to reconcile this change. If we have the rolling strategy, essentially we take a look at pod number 1. Pod number 1 gets rolled to Version 2. At this point, despite the deployment being set to three replicas, there is a search of one additional pod. This pod, pod number 1 in the version 2 is spawning, is getting created in our Kubernetes cluster. Then once it's created, depending on the configuration of our deployment, maybe we have some probes. Kubernetes determines whether the pod is ready to serve or not and if the pod is ready to receive requests. Once the pod is ready to receive requests, then the original pod from the version 1 gets scaled down and we destroy it. At this point we have two pods of version 1 and one pod of version 2. Then Kubernetes takes a look at a second part of the version 1 and does the same, scales a new pod or creates a new pod from version 2, and this new pod again is getting created. Again, checks are being run whether the new path is ready to receive a request. If the new pod is ready to receive requests, then the original pod is scaled down. In that case, there is only one pod remaining from our version 1, and there are now two pods from our version 2 deployment. Finally, we only have the last pod from version 1. Again, the same thing happens, pod number 3 spawns. Again, at this point we have four pods. We have 1, 2, 3, and 4 pods at this time. Then checks are run. If pod number 3 is ready to receive requests, for example, all of the probes pass then the pod is marked as ready to receive requests, and the original pod gets destroyed. At this point, the version 1 of the application is actually scaled down to zero. The whole replica set of the deployment is scaled down to zero, and we have our version 2, which is scaled up to three pods. This is our rolling release of our deployment. Let's jump at the beginning of our image. What we have just seen was the rolling release strategy employed by our deployment. What happens when we employ the recreate strategy for the deployment? Well, when we have our recreate strategy, what happens is that essentially we modify the deployment. Let's say that we switch from version 1 to version 2, and at this moment, the deployment immediately kills or destroys all of the replicas all at once and starts spawning all of the new replicas in the Kubernetes cluster. What happens is that there is some time within the Kubernetes cluster where all of the original pods with the version 1 are at zero, are not ready to receive requests because there are in determinating state and none of the version 2 replicas are ready to receive requests. With the recreate, there is a time when the deployment is not ready to serve any requests. These are our two main strategies. When do we use each of these? Well, the rolling strategy is the default strategy. Why is that? Well, number 1, when an issue happens, we still have our original pods. When an issue happens with the version 2 pods, version 1 pods do not get destroyed. Because remember that the version 1 pods do not terminate until version 2 pods are ready to serve requests. There's also zero downtime during an update. Because we progressively spawn new application pods, there is simply no downtime because there's always some part that is ready to receive requests. However, the application must support running an older version and a newer version at the same time. The application must be able to support two versions at the same time. This can get difficult when, for example, the application shares some persistent volume or the application has some stateful logic that was prevented from having multiple versions at the same time. Whereas the recreate strategy simply destroys all of the pods, and recreates them. This is useful when the application does not support running multiple different versions at the same time or there is some persistent volume that does not allow multiple pods from accessing it or simply when we just want to have a new version of our application as soon as possible, and we don't care about the downtime. How do we set our strategy? Well, we are talking about the deployment strategy. This is within our manager object for our pods, and we have the strategy field. Remember that this is right after our spec. We are in the first spec, but we are above the template property. We have the strategy where we have our type. Type is rolling update. If we choose the rolling update, we can actually configure or tweak the property where we can tweak the search and unavailable properties where the search essentially says how many more pods can we spawn then we want replicas. If we have for example, four replicas and maxSurge is 50 percent. Then we can spawn two new pods, and maxUnavailable is how many pods we can destroy right away. How many of the old versions of pods we can destroy? Depending on your use case, you can actually tweak the parameters of the strategy. Of course, you can use the describe command on some deployment. For example, deployment with the name hello, and you can take a look at the strategy type. You can see what is the strategy type, and you can see the parameters of that strategy.
