1 00:00:02,680 --> 00:00:04,989 ‫If you didn't come directly from the last lecture on this 2 00:00:04,990 --> 00:00:07,832 ‫one, go back to the previous lecture to make sure that you 3 00:00:08,050 --> 00:00:10,794 ‫have the proper Deployment running so that you will have 4 00:00:11,140 --> 00:00:12,910 ‫the logs that we're going to see here in a second. 5 00:00:13,180 --> 00:00:16,119 ‫Snce we have that Apache Deployment running in the 6 00:00:16,120 --> 00:00:19,239 ‫background, and it has two pods because we scaled 7 00:00:19,240 --> 00:00:21,965 ‫the replicas to two. We should be able to do a kubectl 8 00:00:22,360 --> 00:00:24,190 ‫get pods and see the results. 9 00:00:26,440 --> 00:00:28,980 ‫Of course, your pod names will be slightly different than 10 00:00:28,990 --> 00:00:31,989 ‫mine because they'll have the numbers and random characters 11 00:00:31,990 --> 00:00:34,293 ‫on the end there. Whenever I am typing it, just 12 00:00:34,990 --> 00:00:37,239 ‫realize the last two blocks you will be typing something 13 00:00:37,240 --> 00:00:39,999 ‫different based on what your Deployment is showing. 14 00:00:40,720 --> 00:00:43,479 ‫There's a few commands, just like with Swarm and with 15 00:00:43,480 --> 00:00:46,659 ‫Docker itself. In this case, they're different commands 16 00:00:47,200 --> 00:00:49,993 ‫for understanding what's going on in a container and what 17 00:00:50,380 --> 00:00:52,179 ‫the orchestrator is doing with containers. 18 00:00:52,600 --> 00:00:54,130 ‫The first one is logs. 19 00:00:54,190 --> 00:00:55,869 ‫The second one is describe. 20 00:00:56,290 --> 00:00:59,045 ‫We don't technically have an inspect command in Kubernetes, 21 00:00:59,620 --> 00:01:01,390 ‫but describe does much more than that. 22 00:01:01,780 --> 00:01:04,030 ‫First, let's try a logs command. 23 00:01:10,460 --> 00:01:12,650 ‫Your output might be slightly different than mine. 24 00:01:13,250 --> 00:01:16,219 ‫You'll notice that the first line after we typed in 25 00:01:16,580 --> 00:01:18,070 ‫the logs deployment /my-apache. 26 00:01:19,460 --> 00:01:22,069 ‫It says found two pods and using 27 00:01:22,490 --> 00:01:24,829 ‫a pod name, it gave a specific pod name there. 28 00:01:25,250 --> 00:01:27,455 ‫That is because the default log command won't 29 00:01:28,280 --> 00:01:30,191 ‫pull all the different pods and combine 30 00:01:31,490 --> 00:01:33,400 ‫them together like you would with the Docker or Swarm 31 00:01:33,620 --> 00:01:36,709 ‫commands. It's only by default going to pull one of those. 32 00:01:37,160 --> 00:01:39,515 ‫Lke other log commands you've been used to in this course, 33 00:01:39,516 --> 00:01:42,340 ‫there are lots of options including --follow, 34 00:01:43,820 --> 00:01:44,820 ‫--tail. 35 00:01:45,680 --> 00:01:48,559 ‫Those are common things for logging commands in any Linux 36 00:01:48,560 --> 00:01:49,560 ‫system. 37 00:01:49,820 --> 00:01:52,790 ‫If we did that same command with -- just follow, 38 00:01:53,360 --> 00:01:56,153 ‫it will then wait for anything new to show up in the logs 39 00:01:56,330 --> 00:01:57,915 ‫of that pod. Then --tail, 1 40 00:02:00,530 --> 00:02:03,269 ‫just means return the last line only. 41 00:02:03,460 --> 00:02:05,930 ‫That way you don't get a huge dump of the logs. 42 00:02:07,070 --> 00:02:08,900 ‫You can control C out of that. 43 00:02:09,830 --> 00:02:12,199 ‫What if you wanted to see the logs combined for multiple 44 00:02:12,200 --> 00:02:13,039 ‫pods? 45 00:02:13,040 --> 00:02:15,769 ‫You can certainly do that. That's just not the default logs 46 00:02:15,770 --> 00:02:18,259 ‫command. In this case, we're going to have to use something 47 00:02:18,260 --> 00:02:21,439 ‫called a Selector in Kubernetes, which is a technique 48 00:02:21,500 --> 00:02:23,362 ‫to grab multiple pods based on a label 49 00:02:24,770 --> 00:02:25,770 ‫that they all share. 50 00:02:26,240 --> 00:02:28,429 ‫The nice thing here is when you use the kubectl run 51 00:02:28,430 --> 00:02:31,309 ‫command, it automatically added a label 52 00:02:31,610 --> 00:02:34,599 ‫of the name of the Deployment to all these pods. 53 00:02:34,700 --> 00:02:38,269 ‫So, we can use that same Deployment name my Apache 54 00:02:38,690 --> 00:02:41,479 ‫for selecting all the pods with that label. 55 00:02:41,750 --> 00:02:43,955 ‫Note that this is just a simple matching of a 56 00:02:44,720 --> 00:02:47,389 ‫label here. So, if you had other Deployments or pods that 57 00:02:47,390 --> 00:02:50,029 ‫happen to have this label, they would also be caught up in 58 00:02:50,030 --> 00:02:52,819 ‫this too. So, you have to be careful with your labeling and 59 00:02:52,820 --> 00:02:53,820 ‫your naming. 60 00:03:04,680 --> 00:03:05,856 ‫We're using a -l here to 61 00:03:07,710 --> 00:03:10,111 ‫specify the label, and we're specifying the label 62 00:03:10,800 --> 00:03:12,612 ‫that the run command applied, 63 00:03:13,870 --> 00:03:14,870 ‫which was my Apache. 64 00:03:15,520 --> 00:03:18,489 ‫Just like Swarm and Docker itself, these log 65 00:03:18,490 --> 00:03:21,629 ‫commands can be very handy for quick troubleshooting 66 00:03:21,650 --> 00:03:24,090 ‫but are not the replacement for a full log system. 67 00:03:24,140 --> 00:03:26,394 ‫In Kubernetes, by default, it can only pull up 68 00:03:27,840 --> 00:03:29,751 ‫to five pods at a time when it uses the 69 00:03:31,110 --> 00:03:33,321 ‫selector type of pulling in the logs. 70 00:03:33,470 --> 00:03:36,289 ‫You can always increase that, but the reality is it's 71 00:03:36,300 --> 00:03:38,970 ‫taxing on the system to pull from all the different nodes 72 00:03:39,120 --> 00:03:40,340 ‫these log files. 73 00:03:40,920 --> 00:03:43,713 ‫In production, you're going to want a third-party logging 74 00:03:43,950 --> 00:03:46,200 ‫system that would collect all these logs and store them 75 00:03:46,201 --> 00:03:47,720 ‫over time for quicker retrieval. 76 00:03:48,520 --> 00:03:51,200 ‫That's true of really any container orchestration system, 77 00:03:51,370 --> 00:03:53,715 ‫whether it's Docker, Swarm or Kubernetes. 78 00:03:55,450 --> 00:03:57,740 ‫The next command here would be to describe command. 79 00:03:58,190 --> 00:04:01,069 ‫The describe command, in this case, is where we want to 80 00:04:01,460 --> 00:04:03,319 ‫specify the pod itself. 81 00:04:03,350 --> 00:04:05,599 ‫We want to get a very specific pod, but then we need to 82 00:04:05,600 --> 00:04:07,069 ‫know the names of those pods first. 83 00:04:07,080 --> 00:04:08,770 ‫So, let's get pods first. 84 00:04:12,430 --> 00:04:15,669 ‫Then we can copy and paste one of those names into 85 00:04:15,670 --> 00:04:16,670 ‫a describe command. 86 00:04:22,760 --> 00:04:24,540 ‫Type pod first. 87 00:04:25,730 --> 00:04:27,072 ‫I'll get back that pod. 88 00:04:27,340 --> 00:04:29,641 ‫I don't necessarily have to specify that one pod. 89 00:04:29,870 --> 00:04:32,479 ‫I could say pods and it would show all pods, which could be 90 00:04:32,480 --> 00:04:34,399 ‫a little dangerous if you have lots of pods. 91 00:04:34,850 --> 00:04:37,910 ‫You can certainly describe other resources and get back 92 00:04:38,330 --> 00:04:40,639 ‫various types of results based on the object. 93 00:04:41,060 --> 00:04:43,559 ‫What I wanted to highlight here was that this would 94 00:04:44,060 --> 00:04:47,149 ‫be similar to the inspect command in Swarm, or in Docker 95 00:04:47,150 --> 00:04:50,509 ‫itself. But, it gives it a little bit nicer display 96 00:04:50,510 --> 00:04:51,910 ‫on the screen rather than in JSON. 97 00:04:53,030 --> 00:04:56,179 ‫As you scroll down the results, you'll notice that it's not 98 00:04:56,180 --> 00:04:59,329 ‫just a description about the different object, 99 00:04:59,540 --> 00:05:01,451 ‫but also pulls up things like events at 100 00:05:02,570 --> 00:05:05,870 ‫the bottom, which is a great way to get quick status 101 00:05:05,900 --> 00:05:08,989 ‫on the current reality of that object. 102 00:05:09,050 --> 00:05:11,549 ‫So, in case you were having a problem, maybe with a 103 00:05:12,050 --> 00:05:14,304 ‫pod pulling an image, you would see that event 104 00:05:15,290 --> 00:05:17,300 ‫here where it would say unable to pull image. 105 00:05:17,600 --> 00:05:20,779 ‫That's a common one for when you're accidentally 106 00:05:20,780 --> 00:05:22,858 ‫mistyping an image name or something like that. 107 00:05:22,859 --> 00:05:26,240 ‫This can be pretty handy for a quick troubleshooting 108 00:05:26,540 --> 00:05:28,990 ‫technique without having to go turn on some events 109 00:05:29,600 --> 00:05:30,600 ‫or debugging logs. 110 00:05:31,340 --> 00:05:33,199 ‫All right. For this last little bit, I'm going to show you 111 00:05:33,200 --> 00:05:36,350 ‫how Kubernetes is resilient similar to 112 00:05:36,530 --> 00:05:39,709 ‫Swarm where if you delete one of the lower 113 00:05:39,710 --> 00:05:42,529 ‫levels of abstraction, in this case if you delete a pod, 114 00:05:43,100 --> 00:05:45,350 ‫the higher level abstraction, the Deployment and the 115 00:05:45,740 --> 00:05:47,848 ‫ReplicaSet, will make sure that that pod is recreated. 116 00:05:48,410 --> 00:05:51,191 ‫That's similar to the way a container or task in Swarm, 117 00:05:52,130 --> 00:05:54,739 ‫if you delete it, would be recreated by the service. 118 00:05:55,010 --> 00:05:57,019 ‫We're going to do this in two different windows. 119 00:05:57,380 --> 00:06:00,160 ‫In the first window, we're going to use a get with a -w. 120 00:06:01,610 --> 00:06:04,639 ‫That is going to give us a similar experience 121 00:06:04,640 --> 00:06:07,699 ‫to the watch command. If you've ever seen me use the watch 122 00:06:07,700 --> 00:06:10,639 ‫command in this course to watch any Linux 123 00:06:10,850 --> 00:06:13,489 ‫command, which essentially means to run that thing in the 124 00:06:13,490 --> 00:06:15,529 ‫background and you could do that in Linux. 125 00:06:15,560 --> 00:06:18,319 ‫But, that watch command is not always available on all 126 00:06:18,320 --> 00:06:21,290 ‫OS's. Here, we can do a 127 00:06:21,650 --> 00:06:24,470 ‫kubectl get pods 128 00:06:25,519 --> 00:06:27,185 ‫but add a -w which will let it sit 129 00:06:28,520 --> 00:06:30,829 ‫there and refresh every few seconds. 130 00:06:31,310 --> 00:06:34,040 ‫Now, we can go to a different 131 00:06:34,400 --> 00:06:37,819 ‫terminal. We're going to delete one of those pods. 132 00:06:37,910 --> 00:06:40,322 ‫First. we'll need to copy the name and 133 00:06:42,180 --> 00:06:43,180 ‫use a kubectl 134 00:06:48,019 --> 00:06:49,429 ‫pod /the name of the pod. 135 00:06:50,382 --> 00:06:52,370 ‫You'll notice that it's deleting it. 136 00:06:52,520 --> 00:06:55,519 ‫We'll then get this running log up 137 00:06:55,520 --> 00:06:57,023 ‫top of the things that are changing. 138 00:06:57,450 --> 00:06:59,220 ‫I also like this a little bit better than the watch command 139 00:06:59,250 --> 00:07:01,950 ‫because the watch command refreshes the screen, where this 140 00:07:01,951 --> 00:07:02,991 ‫shows an ongoing iteration 141 00:07:05,160 --> 00:07:06,780 ‫of the changes, which is pretty neat. Down at the bottom, 142 00:07:06,781 --> 00:07:09,990 ‫if we did another kubectl get pods, 143 00:07:10,050 --> 00:07:11,362 ‫you'll see that we're back to two. 144 00:07:12,020 --> 00:07:14,568 ‫Again, this is sort of the self healing aspect of an 145 00:07:14,883 --> 00:07:16,861 ‫orchestrator. That's one of the main goals of having one. 146 00:07:17,630 --> 00:07:19,340 ‫Lastly, I want to point out something here where you 147 00:07:20,910 --> 00:07:23,461 ‫might have been protected in the past from doing certain 148 00:07:23,462 --> 00:07:26,206 ‫damaging things in Docker a Swarm, where if you tried to 149 00:07:26,221 --> 00:07:27,749 ‫change something or delete something that you shouldn't, it 150 00:07:27,750 --> 00:07:29,243 ‫might warn you ahead of time. 151 00:07:29,910 --> 00:07:33,149 ‫Kubernetes tends to fall on the other side where it's 152 00:07:33,150 --> 00:07:35,149 ‫a little less opinionated about how you use it. 153 00:07:35,150 --> 00:07:36,963 ‫Which means that you can sometimes do 154 00:07:38,550 --> 00:07:40,799 ‫things that you shouldn't, such as my example earlier of 155 00:07:40,800 --> 00:07:43,103 ‫modifying a ReplicaSet instead of modifying the 156 00:07:44,250 --> 00:07:45,250 ‫Deployment above it. 157 00:07:45,600 --> 00:07:49,799 ‫The same could be true of changing a pod when you 158 00:07:49,800 --> 00:07:51,270 ‫really shouldn't be doing that. You should change the object above it. 159 00:07:51,330 --> 00:07:53,910 ‫That just stresses that you need to understand the 160 00:07:55,740 --> 00:07:57,149 ‫specifics of what you're doing so that you don't accidentally 161 00:07:57,150 --> 00:07:59,747 ‫delete, change or modify the wrong thing in the wrong 162 00:07:59,942 --> 00:08:00,755 ‫order. 163 00:08:00,756 --> 00:08:03,713 ‫Remember to do a kubectl delete deployment my-apache 164 00:08:05,840 --> 00:08:08,151 ‫to clean up from this lecture.