WEBVTT 00:00.710 --> 00:07.370 And now another benefit that we get from using a deployment object is the benefit of rolling updates. 00:07.370 --> 00:14.960 The rolling updates are really important because they eliminate downtime between application upgrades. 00:14.960 --> 00:19.100 So let's assume our applications are currently running version one. 00:19.100 --> 00:22.370 And we want to upgrade our applications to version two. 00:22.400 --> 00:25.070 Now what our deployment object. 00:25.070 --> 00:31.250 Simply eliminate all of the old pod replicas and then create new pod replicas. 00:31.310 --> 00:38.750 That wouldn't be very ideal, because after destroying all of the old pods, the time that elapses in 00:38.750 --> 00:46.520 which the new pods are still being created, our clients don't have access to any of our apps, so we 00:46.550 --> 00:48.110 call this downtime. 00:48.110 --> 00:55.550 And the purpose of rolling updates is to eliminate downtime, and it does that by gradually removing 00:55.550 --> 01:02.330 old pods and gradually adding new pods, ensuring that while the new pods are being created, the old 01:02.330 --> 01:04.700 pods are still ready to serve traffic. 01:04.700 --> 01:08.990 Um, this rolling update, we get that automatically. 01:09.020 --> 01:14.360 Okay, we get it out of the box with the deployment controller is going to do when we update the pod 01:14.390 --> 01:22.610 template is it's going to preserve the replica set where each pod is running version one of my app, 01:22.610 --> 01:29.600 and it's going to create a new replica set where the pods will be running version two of my app. 01:29.630 --> 01:36.920 It's going to gradually scale down the first replica set to zero pods, and gradually scale up the new 01:36.920 --> 01:38.900 replica set to three pods. 01:38.930 --> 01:46.010 The replica set controller will respond in kind by gradually removing old pods and gradually adding 01:46.010 --> 01:53.510 new ones, therefore eliminating downtime and ensuring that clients always have access to some version 01:53.510 --> 01:54.890 of my application. 01:54.950 --> 01:58.640 Now I want to show you the benefit of rolling updates. 01:58.640 --> 02:03.300 So let's go ahead and, um, can't duplicate. 02:03.330 --> 02:03.510 Huh? 02:03.540 --> 02:05.940 Oh, I can copy this folder and paste it. 02:06.360 --> 02:09.540 And I'm going to call it section five. 02:12.150 --> 02:13.020 All right. 02:13.020 --> 02:18.120 And now what I'm going to do is. 02:21.930 --> 02:25.380 So I've got two versions of the great submission API. 02:25.410 --> 02:28.860 The stateless version and the stateful version. 02:28.860 --> 02:36.210 And what I'm going to do is update my pods to run the stateful version of my great submission API application. 02:36.210 --> 02:44.940 And I'm going to show you how gradual this update is, how it essentially rolls the update from using 02:44.940 --> 02:49.050 old pods, from using old versions of my app to new ones. 02:49.140 --> 02:51.210 So I'm going to reapply. 02:52.050 --> 02:57.960 Well, we'll CD out of section four CD into section five. 02:58.650 --> 03:01.860 I'm going to say kubectl apply Life. 03:03.240 --> 03:09.030 I can reapply the grade submission API deployment dot YAML. 03:09.600 --> 03:14.610 Kubectl get pods dash n grade submission. 03:14.640 --> 03:16.020 I'm not fast enough. 03:18.480 --> 03:22.620 Uh, notice how it's creating a new pod? 03:23.490 --> 03:30.420 Terminating old pods, essentially gradually upgrading our application so it didn't just delete all 03:30.450 --> 03:31.320 of the old pods. 03:31.350 --> 03:36.630 It in this case, what it did is it created two new pods and then it deleted the old ones. 03:36.630 --> 03:43.110 This is actually ideal because it didn't remove any old pods in this case until it ensured that the 03:43.110 --> 03:45.210 new pods were running first. 03:45.210 --> 03:50.130 So the rolling update will always be different depending on the situation. 03:50.130 --> 03:53.700 But it's not just going to destroy old pods and then create new ones. 03:53.700 --> 03:58.680 You're always going to have some apps running ready to serve requests, okay? 03:59.820 --> 04:00.810 And we're good. 04:00.840 --> 04:06.570 Now we've got two pods running the stateful version of my application. 04:06.720 --> 04:13.230 And if I were to test this out, localhost 3200. 04:13.260 --> 04:14.880 Submit a grade for Harry. 04:14.910 --> 04:20.880 We'll give him a 99 and Quidditch submit that. 04:23.340 --> 04:27.030 And oh no, the new API isn't working. 04:27.060 --> 04:29.010 Ah, what are we going to do now? 04:29.040 --> 04:36.000 Well, thankfully, Kubernetes or the deployment controller, in this case, it doesn't just forget 04:36.000 --> 04:37.680 about the old set of pods. 04:37.680 --> 04:39.750 It keeps them all right. 04:39.750 --> 04:48.480 Because that way, if the new version of our application doesn't end up working, we can roll back to 04:48.510 --> 04:50.940 using the old version of our app. 04:51.300 --> 04:58.740 So if we want to roll back, a new replica set is created that runs the same version that the first 04:58.740 --> 05:00.780 replica set of pods had. 05:00.810 --> 05:07.570 It's going to be scaled up to three pods and the replica set of pods whose version didn't work. 05:07.570 --> 05:10.300 It's going to be scaled back down to zero pods. 05:10.300 --> 05:11.590 So essentially. 05:11.590 --> 05:14.320 So we essentially roll the update back. 05:14.350 --> 05:15.130 Okay. 05:15.670 --> 05:22.510 Um, so I can simply say cube CTL rollout undo deployment. 05:24.370 --> 05:30.850 And the deployment is called great submission API and great submission. 05:32.410 --> 05:34.390 And it's been rolled back. 05:34.390 --> 05:35.080 Beautiful. 05:35.110 --> 05:39.640 Kubectl get pods dash n great submission. 05:39.640 --> 05:42.160 Once again the update is going to be gradual. 05:42.160 --> 05:44.950 It's going to gradually run new ones. 05:44.980 --> 05:46.060 All right. 05:51.910 --> 05:56.230 Now let's try it out to make sure that we're using the old version of our app. 05:56.230 --> 05:57.970 Harry 99 potions. 05:57.970 --> 06:00.160 We are golden 06:02.860 --> 06:03.670 All right. 06:03.700 --> 06:04.180 All right. 06:04.210 --> 06:08.140 Now you can actually control the rolling update strategy. 06:08.170 --> 06:15.640 You can control how the update happens under spec where we specify the behavior of a deployment object. 06:15.640 --> 06:20.770 We can specify how the rolling strategy will happen. 06:20.770 --> 06:28.210 So the strategy we're going to modify is of type rolling update under rolling update, what I can do 06:28.240 --> 06:35.050 is specify the maximum number of pods that can be unavailable at a time and set that to 50%. 06:35.050 --> 06:41.260 So this basically means that the maximum number of pods that can be unavailable during the update is 06:41.260 --> 06:44.770 50% of our desired pod replica count. 06:44.920 --> 06:52.150 Okay, so we have to have at least one running pod throughout our update. 06:52.180 --> 06:55.510 Another thing we can modify is the max surge. 06:55.510 --> 06:58.240 We can set that to something like one. 06:58.300 --> 07:04.660 Max surge is the maximum number of pods that can be scheduled above the desired number of pods. 07:04.660 --> 07:11.320 So you'll remember before that, while the update was happening, it created two new pods running the 07:11.320 --> 07:14.020 updated version on top of the old pods. 07:14.020 --> 07:18.940 So essentially we had four pod replicas and then it started deleting the old pods. 07:18.970 --> 07:25.720 Okay, well this ensures that we only have one additional pod above the desired number of pods. 07:25.720 --> 07:35.050 So we essentially ensure that we do not have more than three pod replicas running at a time. 07:35.050 --> 07:42.880 In this case, the reason you'd want to set a max surge is just in case you don't have enough resources 07:42.880 --> 07:45.670 to have all the pods running at once. 07:45.670 --> 07:47.860 So you say, you know what? 07:47.890 --> 07:53.920 Once we reach three pods, start deleting old pods before adding new ones. 07:53.950 --> 07:54.760 Okay. 07:54.910 --> 07:59.770 And we I'm pretty sure we rolled back to using the stateless app. 07:59.770 --> 08:03.200 So if we reapply this deployment. 08:05.480 --> 08:08.930 We should get a rolling update. 08:09.020 --> 08:13.580 Kubectl get pods and great submission. 08:14.810 --> 08:20.180 And we don't really see anything interesting, but we're not really breaking any of the rules we specified 08:20.180 --> 08:22.130 in the rolling update strategy. 08:22.160 --> 08:26.750 All of the pods are 100% available, so we satisfy the following. 08:26.750 --> 08:31.370 And we don't have more than three pods running at a time. 08:31.370 --> 08:33.230 We've got the two pods running here. 08:33.230 --> 08:38.030 I'm guessing one of them was terminated while we were still writing this command, and now both of them 08:38.030 --> 08:39.320 are being terminated. 08:39.350 --> 08:47.750 Anyways, rolling updates simply ensure that there that downtime is eliminated between application upgrades. 08:47.750 --> 08:51.080 There's always one version of your app running at a time. 08:51.110 --> 08:58.040 Okay, now I want to mention that the default strategy, the default rolling update strategy for a deployment 08:58.040 --> 09:02.900 is fine, but I'll just leave it here for reference and I'll see you in the next section.