1 00:00:00,790 --> 00:00:04,260 In the last section we spoke about how we're going to update an existing object. 2 00:00:04,400 --> 00:00:06,230 We're going to take that existing conflict file. 3 00:00:06,230 --> 00:00:11,540 Leave the name and kind the same and we can make any other change we want to to the file and throw that 4 00:00:11,540 --> 00:00:12,660 back in the cubes DTL. 5 00:00:12,680 --> 00:00:18,530 And our expectation is that we are going to update an existing object as opposed to creating a new one. 6 00:00:18,530 --> 00:00:22,360 So let's flip on over to our config file. 7 00:00:22,400 --> 00:00:28,370 Remember our goal right now is to update the existing pod to use the multi worker image instead of the 8 00:00:28,370 --> 00:00:29,510 multi client. 9 00:00:29,540 --> 00:00:30,710 Now a quick note here. 10 00:00:30,710 --> 00:00:37,580 Remember that the multi worker image really expects to have a copy of red S available and so it's entirely 11 00:00:37,580 --> 00:00:40,850 possible that when we do this update something is going to crash. 12 00:00:40,870 --> 00:00:47,000 Or I should say the container that gets created might crash because there is no copy of read is available. 13 00:00:47,000 --> 00:00:52,160 Nonetheless I just want to make sure that we have the ability to update the image that is being used. 14 00:00:52,190 --> 00:00:54,970 I'm not really concerned about getting a pod successfully running. 15 00:00:54,980 --> 00:00:56,620 I just want to update the image right now. 16 00:00:56,660 --> 00:00:58,150 That's all. 17 00:00:58,150 --> 00:01:01,310 All right so we're going to open up our code editor. 18 00:01:01,450 --> 00:01:04,050 We're going to fund the client pod File. 19 00:01:04,090 --> 00:01:08,590 We're going to leave the kind of the same and the name identical as well. 20 00:01:08,620 --> 00:01:12,530 The only thing we're going to update inside of here is the image that we are using. 21 00:01:12,550 --> 00:01:19,120 So instead of using multi client I'm going to use multi worker instead we'll leave everything else inside 22 00:01:19,120 --> 00:01:20,080 of your identical. 23 00:01:20,080 --> 00:01:24,410 I'm not going to change the port even though multi worker doesn't really expose anything on port three 24 00:01:24,410 --> 00:01:26,370 thousand or anything like that. 25 00:01:26,470 --> 00:01:32,110 Again I just want to update the image and make sure that we are updating a pod in place and not creating 26 00:01:32,140 --> 00:01:33,470 a new separate pot. 27 00:01:34,360 --> 00:01:34,570 All right. 28 00:01:34,580 --> 00:01:37,070 So I made the change to multi worker. 29 00:01:37,180 --> 00:01:42,430 I'm going to save the file I'm going to flip back over to my terminal going to make sure I'm it's still 30 00:01:42,430 --> 00:01:48,270 inside my simple Cade's directory and then I'm going to feed this updated configuration file back in 31 00:01:48,270 --> 00:01:53,870 the cube Seitel by using that apply command remember apply is the magic command. 32 00:01:53,890 --> 00:01:59,850 It's how we make any changes to our kin to the configuration of our Cabinet these cluster cells say 33 00:01:59,890 --> 00:02:04,110 cube Seitel apply dush f Wyant dash pod. 34 00:02:04,160 --> 00:02:10,160 YAML and now you'll notice that when we hit enter and we submit that command we do not see something 35 00:02:10,160 --> 00:02:14,180 that says like oh I'm going to update or I'm going to see man going to create a new pod or anything 36 00:02:14,180 --> 00:02:14,810 like that. 37 00:02:14,810 --> 00:02:18,960 Instead it says very specifically client pod has been configured. 38 00:02:19,160 --> 00:02:24,740 When you see the message configured it means that we've updated the configuration that is applied to 39 00:02:24,770 --> 00:02:26,290 client Dasch pot. 40 00:02:26,660 --> 00:02:33,560 So we should now be able to run that get Pod's command and verify that there is still one pod that exists 41 00:02:33,650 --> 00:02:35,910 inside of our entire cluster. 42 00:02:35,990 --> 00:02:43,820 So I'll do cube see T.L. get pods and you'll notice that we now have still just one pod that's the name 43 00:02:43,820 --> 00:02:44,590 of client pod. 44 00:02:44,600 --> 00:02:46,430 There's one copy it's running. 45 00:02:46,430 --> 00:02:51,560 There's two restarts currently because we just caused this thing to be restarted when we updated the 46 00:02:51,560 --> 00:02:53,400 image that it's running now. 47 00:02:53,420 --> 00:02:59,510 The only thing that's kind of awkward right now is that we can't really inspect this pod and verify 48 00:02:59,510 --> 00:03:03,020 that it is in fact running the updated image. 49 00:03:03,050 --> 00:03:07,820 So I want to figure out some way that we can actually look at this very specific POD right here and 50 00:03:07,820 --> 00:03:12,230 look at the different containers that are running inside there and verify that 100 percent. 51 00:03:12,230 --> 00:03:13,320 No two ways about it. 52 00:03:13,430 --> 00:03:16,200 Yes we are running the multi worker image. 53 00:03:16,490 --> 00:03:22,250 So in order to inspect this very particular pod right here we're going to learn a new command on Kube 54 00:03:22,250 --> 00:03:25,410 CTO Ir's the new command. 55 00:03:25,650 --> 00:03:28,850 Not there not there are to go here you go. 56 00:03:29,300 --> 00:03:34,940 So to get detailed information about an object inside of our cluster we're going to use the cube seat 57 00:03:35,180 --> 00:03:37,230 T.L. describe command. 58 00:03:37,520 --> 00:03:42,640 Describe this use to print out a ton of information about a very particular object. 59 00:03:42,800 --> 00:03:45,110 So we'll say cube Seitel describe. 60 00:03:45,230 --> 00:03:51,810 Then pass in an object type and then the name of the particular object that we want to investigate. 61 00:03:52,010 --> 00:03:55,100 Now just as a quick curiosity here or something that's kind of interesting. 62 00:03:55,160 --> 00:03:58,030 You can actually omit the object name if you want to. 63 00:03:58,190 --> 00:04:03,830 If you do that you'll get detailed information about every different object type of the specify or seeing 64 00:04:03,830 --> 00:04:06,740 every different object with the specified object type. 65 00:04:07,000 --> 00:04:08,330 But it's a ton of information. 66 00:04:08,360 --> 00:04:13,760 So in general we usually use the full command which has cubes detail describe the type and the name 67 00:04:13,790 --> 00:04:17,220 to just get information about that one particular object. 68 00:04:17,240 --> 00:04:19,040 So let's try that out right now. 69 00:04:19,040 --> 00:04:23,780 Again we're going to run this command to verify that the client pod is in fact running that updated 70 00:04:23,810 --> 00:04:25,130 image. 71 00:04:25,130 --> 00:04:32,540 So I'll do cube Seitel describe our object type is Pod's so we could simply say pod either one is fine 72 00:04:32,570 --> 00:04:41,260 pods or pod and it'll put in the name of that very particular object which is client dash pod. 73 00:04:41,340 --> 00:04:48,300 So it's going to print out a ton of very detailed information about that very particular part down at 74 00:04:48,300 --> 00:04:51,780 the very bottom you're going to see a series of events right here very frequently. 75 00:04:51,780 --> 00:04:56,300 This is going to be some of the most interesting information this is going to be events that are not 76 00:04:56,310 --> 00:05:01,610 logs coming out of the containers but events that have occurred over the life cycle of the pot. 77 00:05:01,770 --> 00:05:07,740 So you'll see messages about things that have crashed or pulling new images or changing images or stuff 78 00:05:07,740 --> 00:05:08,930 like that. 79 00:05:08,940 --> 00:05:13,980 Now if we scroll up a little bit higher there is a ton of information in here that's kind of outside 80 00:05:13,980 --> 00:05:16,300 the scope of what we want to talk about right now. 81 00:05:16,680 --> 00:05:20,730 But if you scroll up scroll up scroll up you will see containers. 82 00:05:20,790 --> 00:05:27,180 We have a container with a name of clients recall that client name right there was provided inside of 83 00:05:27,180 --> 00:05:28,440 our configuration file. 84 00:05:28,440 --> 00:05:35,160 So there is name client right there and then we're told that the client container member that's the 85 00:05:35,160 --> 00:05:35,790 name of the container. 86 00:05:35,790 --> 00:05:40,190 This is kind of misleading because we have this these kind of conflicting names all over the place. 87 00:05:40,320 --> 00:05:44,990 But essentially the image is the multi worker image. 88 00:05:45,000 --> 00:05:48,270 That's exactly what we just updated our configuration file to use. 89 00:05:48,270 --> 00:05:56,990 So without a doubt updating that configuration file and leaving the name and the kind identical found 90 00:05:57,050 --> 00:06:02,720 an existing object that was already running inside of our cluster and it updated it in place as opposed 91 00:06:02,720 --> 00:06:05,900 to trying to create a completely separate pod. 92 00:06:05,900 --> 00:06:06,560 All right so that's it. 93 00:06:06,560 --> 00:06:14,290 That's a quick example of this entire idea of declarative vs. imperative deployments. 94 00:06:14,540 --> 00:06:17,020 So we like to use declarative as much as possible. 95 00:06:17,090 --> 00:06:23,000 And the formula formula for doing a declarative update is always going to be the same thing over and 96 00:06:23,000 --> 00:06:23,580 over. 97 00:06:23,720 --> 00:06:25,920 We're going to go find our original config file. 98 00:06:25,940 --> 00:06:32,090 We're going to make a change to it leaving the type or kind and the name the same what date some configuration 99 00:06:32,090 --> 00:06:36,560 side the file and then we're going to throw it back into cube CTO and our master is just going to kind 100 00:06:36,560 --> 00:06:42,110 of make the change for us and we don't have to worry about manually printing out a list of running pods 101 00:06:42,170 --> 00:06:46,970 and issuing a command to update a very specific POD or anything like that. 102 00:06:47,030 --> 00:06:51,110 We're going to see this declarative approach throughout this entire course just nonstop. 103 00:06:51,110 --> 00:06:53,490 It's going to be all we're doing throughout the entire course. 104 00:06:53,510 --> 00:06:54,890 Update the config file. 105 00:06:55,010 --> 00:06:59,360 Throw it in the queue DTL verify that in fact everything works correctly. 106 00:06:59,600 --> 00:07:00,970 OK so that's a good example. 107 00:07:01,010 --> 00:07:03,590 Take a quick pause right here and we'll continue in the next section.