1 00:00:01,450 --> 00:00:02,450 ‫I'll be honest. 2 00:00:03,400 --> 00:00:06,630 ‫Back when I first saw Kubernetes YAML, I 3 00:00:06,640 --> 00:00:07,800 ‫was really intimidated. 4 00:00:08,390 --> 00:00:11,220 ‫It seemed way more complex than Compose format. 5 00:00:11,470 --> 00:00:13,560 ‫That's for good reason. 6 00:00:13,650 --> 00:00:15,267 ‫It adds tons of flexibility, tons 7 00:00:16,960 --> 00:00:19,083 ‫more things you can do with it. But, that comes at a price. 8 00:00:20,240 --> 00:00:22,984 ‫That is getting over the hump of learning the basics and 9 00:00:24,460 --> 00:00:25,991 ‫how to make these files. When you first started looking at 10 00:00:25,992 --> 00:00:28,249 ‫these files, there's so much to it that I wasn't even sure 11 00:00:28,250 --> 00:00:30,190 ‫what was going on when I first held these files. 12 00:00:30,191 --> 00:00:32,070 ‫Totally understand 13 00:00:33,540 --> 00:00:35,800 ‫if you are feeling a little bit confused about this as we 14 00:00:35,801 --> 00:00:38,692 ‫go through it, just try to rewatch these videos because I'm 15 00:00:38,741 --> 00:00:41,485 ‫going to try to break this down in a way that I think is 16 00:00:41,502 --> 00:00:42,896 ‫best for learning Kubernetes YAML. 17 00:00:43,230 --> 00:00:45,337 ‫First up is we could write this technically 18 00:00:46,240 --> 00:00:48,270 ‫in JSON, but YAML tends 19 00:00:50,320 --> 00:00:52,009 ‫to be easier for humans to manipulate and read, and JSON's 20 00:00:52,010 --> 00:00:53,461 ‫better for computers. 21 00:00:53,800 --> 00:00:56,446 ‫What's happening in the background is the standard for 22 00:00:57,100 --> 00:00:59,259 ‫us humans is to write the YAML and then it's going to 23 00:00:59,260 --> 00:01:01,509 ‫convert that into JSON. You technically could write the 24 00:01:01,510 --> 00:01:03,170 ‫JSON, but the standard with Kubernetes for 25 00:01:04,569 --> 00:01:05,569 ‫humans to write is YAML. 26 00:01:06,140 --> 00:01:09,579 ‫Like I said before, you can mix or match these 27 00:01:09,580 --> 00:01:13,569 ‫files. You can have many different resources in 28 00:01:13,570 --> 00:01:15,546 ‫a single file and then do the opposite of that where 29 00:01:17,170 --> 00:01:18,390 ‫you have a single file per resource. 30 00:01:18,890 --> 00:01:20,519 ‫Doesn't really matter. It's up to you. 31 00:01:20,520 --> 00:01:22,022 ‫The commands work the same way. 32 00:01:22,650 --> 00:01:24,432 ‫We're calling these manifests. 33 00:01:24,800 --> 00:01:26,613 ‫The full description of a resource is 34 00:01:28,030 --> 00:01:30,121 ‫a manifest, and that manifest has requirements. 35 00:01:30,260 --> 00:01:33,729 ‫You'll see those requirements as for root keys 36 00:01:33,750 --> 00:01:34,900 ‫inside the YAML file. 37 00:01:35,170 --> 00:01:37,655 ‫Root meaning they're at the very beginning of the line. 38 00:01:37,730 --> 00:01:40,689 ‫That starts with API 39 00:01:40,690 --> 00:01:42,040 ‫version. There's kind. 40 00:01:42,080 --> 00:01:44,530 ‫There's metadata. And there's spec. 41 00:01:44,580 --> 00:01:46,981 ‫So, you have to see those in every file for these 42 00:01:48,790 --> 00:01:51,194 ‫resources to work. And Let's just look at some quick 43 00:01:51,195 --> 00:01:52,195 ‫examples from the command line. 44 00:01:52,980 --> 00:01:55,577 ‫If you're in your Docker Mastery repo, you will see a 45 00:01:56,350 --> 00:01:57,967 ‫k8s-yaml directory where I've put 46 00:01:59,291 --> 00:02:00,390 ‫some of these examples in here. 47 00:02:00,950 --> 00:02:04,089 ‫If you don't see that directory, then you 48 00:02:04,090 --> 00:02:06,736 ‫may need to do a git-pull to get the latest updates to 49 00:02:07,120 --> 00:02:09,909 ‫the repo. If you've made some changes in the repo from 50 00:02:09,919 --> 00:02:11,100 ‫taking this course, that's fine. 51 00:02:11,440 --> 00:02:14,199 ‫You can either use a git-stash to stash those changes away 52 00:02:14,200 --> 00:02:15,589 ‫temporarily and then do the git-pull. 53 00:02:16,600 --> 00:02:18,266 ‫Or, you can just copy it down into 54 00:02:20,230 --> 00:02:21,911 ‫a different directory. Just clone it in a different 55 00:02:21,912 --> 00:02:24,040 ‫location for this part of the course, because this 56 00:02:24,400 --> 00:02:26,432 ‫Kubernetes stuff is newer than the original stuff. 57 00:02:26,620 --> 00:02:29,950 ‫So, some of you may be coming back at this later 58 00:02:29,980 --> 00:02:32,043 ‫and don't have the latest updates. 59 00:02:33,250 --> 00:02:34,844 ‫The first example here is just a simple pod. 60 00:02:36,950 --> 00:02:38,671 ‫This is probably the simplest YAML we can create. 61 00:02:39,190 --> 00:02:41,885 ‫Like I said earlier in this course, you won't be making 62 00:02:42,013 --> 00:02:44,365 ‫that many pods because that's just creating like 63 00:02:45,010 --> 00:02:46,010 ‫a docker run. 64 00:02:46,650 --> 00:02:48,313 ‫That's not really something you're going to want to do. 65 00:02:48,314 --> 00:02:49,872 ‫It doesn't have rolling updates. It's not a deployment, 66 00:02:49,873 --> 00:02:52,361 ‫right. If you ever need to troubleshoot, or you just need 67 00:02:52,362 --> 00:02:54,559 ‫to run something simple locally, you could do this. 68 00:02:54,560 --> 00:02:57,150 ‫You'll notice it has the same four requirements. 69 00:02:57,330 --> 00:02:58,800 ‫The API version, the kind, the 70 00:03:00,550 --> 00:03:01,550 ‫metadata, and the spec. 71 00:03:01,900 --> 00:03:03,788 ‫We'll talk about what those are in the next lecture. 72 00:03:03,789 --> 00:03:04,800 ‫For now, I 73 00:03:06,760 --> 00:03:08,619 ‫just want you to see how this kind is pod. Then metadata 74 00:03:08,620 --> 00:03:10,121 ‫has the name attribute. 75 00:03:10,230 --> 00:03:13,089 ‫That key is the required key of all 76 00:03:13,450 --> 00:03:14,470 ‫YAML objects. 77 00:03:15,510 --> 00:03:17,919 ‫They all have to have that name, just like docker run has 78 00:03:17,920 --> 00:03:19,351 ‫to have a name. All Docker objects have to have a name. 79 00:03:20,010 --> 00:03:21,901 ‫Same with Kubernetes. The spec here is the meat. 80 00:03:22,040 --> 00:03:24,931 ‫We'll get to that in a moment. Let's take another look at a 81 00:03:25,510 --> 00:03:26,510 ‫deployment. 82 00:03:28,010 --> 00:03:29,010 ‫Here is a single deployment with two 83 00:03:31,150 --> 00:03:33,492 ‫replicas of that same container. It's probably twice the 84 00:03:33,493 --> 00:03:34,740 ‫size but for good reason. 85 00:03:35,040 --> 00:03:36,969 ‫Because if you think about it, you're creating that 86 00:03:36,970 --> 00:03:39,249 ‫deployment resource, and then that is creating the 87 00:03:39,250 --> 00:03:41,253 ‫ReplicaSet. Then that's creating the pods. 88 00:03:41,530 --> 00:03:42,530 ‫The spec area gets a 89 00:03:44,740 --> 00:03:46,543 ‫little bit more complex because it's doing more things that 90 00:03:46,544 --> 00:03:49,060 ‫we have to define. You'll notice also that our API version 91 00:03:49,061 --> 00:03:50,280 ‫is slightly different because 92 00:03:52,090 --> 00:03:54,339 ‫that's related to the kind, and the kind in this case is a 93 00:03:54,350 --> 00:03:56,130 ‫deployment. It's kind of such that means resource. 94 00:03:56,360 --> 00:03:58,621 ‫And the API version is the version 95 00:04:00,220 --> 00:04:03,309 ‫of the API for that kind. The rest here makes hopefully 96 00:04:03,310 --> 00:04:04,352 ‫a little sense to you. 97 00:04:04,750 --> 00:04:07,210 ‫It looks a little bit similar to Compose files but 98 00:04:07,220 --> 00:04:08,870 ‫obviously the format is different. 99 00:04:08,940 --> 00:04:11,621 ‫So, I understand it can be confusing, especially if you're 100 00:04:11,622 --> 00:04:14,099 ‫working back and forth between Compose and Kubernetes. 101 00:04:14,750 --> 00:04:16,514 ‫In this example, I have combined the 102 00:04:17,800 --> 00:04:18,900 ‫service and the deployment, for 103 00:04:20,829 --> 00:04:22,741 ‫that same type of deployment, into a single file. 104 00:04:22,980 --> 00:04:25,629 ‫This is how you would have multiple manifests in a single 105 00:04:25,630 --> 00:04:26,630 ‫file as you use the 106 00:04:28,630 --> 00:04:30,251 ‫three dashes to break those two apart. That is sort of a 107 00:04:30,252 --> 00:04:33,309 ‫YAML thing that will tell Kubernetes hey, this 108 00:04:33,310 --> 00:04:35,221 ‫object is unique. Then the next part is 109 00:04:36,610 --> 00:04:38,950 ‫a new object. You can have as many as you want in here 110 00:04:38,980 --> 00:04:41,871 ‫until it gets so unruly that you just have to break it out. 111 00:04:41,930 --> 00:04:44,282 ‫You'll see with this first part, the API version 112 00:04:44,920 --> 00:04:46,635 ‫is V1 of the service resource kind. 113 00:04:48,260 --> 00:04:51,213 ‫The word kind here probably could just be resource, 114 00:04:51,450 --> 00:04:52,970 ‫but they've called it kind. 115 00:04:53,310 --> 00:04:55,382 ‫Metadata here again. Got to have a name. 116 00:04:55,400 --> 00:04:58,380 ‫The spec and that's going to be totally different 117 00:04:58,420 --> 00:05:00,380 ‫based on which resource you're creating. 118 00:05:01,061 --> 00:05:04,269 ‫Then a similar deployment to what we had earlier, which 119 00:05:04,320 --> 00:05:07,269 ‫this case I have three replicas and it's 120 00:05:07,270 --> 00:05:09,423 ‫got a slightly different name, but other than that, it's 121 00:05:10,240 --> 00:05:11,240 ‫the same Nginx. 122 00:05:12,400 --> 00:05:14,590 ‫Just by looking at that, you're thinking, wow. I must need 123 00:05:14,600 --> 00:05:17,344 ‫templates that I'm going to store so I know how to start 124 00:05:17,780 --> 00:05:19,261 ‫because this seems quite complex. 125 00:05:19,760 --> 00:05:22,161 ‫There is no single docs page that spells all this 126 00:05:22,870 --> 00:05:25,543 ‫out for all the different dozens and dozens of resource 127 00:05:25,544 --> 00:05:28,189 ‫types, and how each one needs to be set up. 128 00:05:28,620 --> 00:05:30,879 ‫That's unfortunately something that we got with Compose 129 00:05:30,880 --> 00:05:32,938 ‫where it was a nice single, although long. 130 00:05:33,450 --> 00:05:35,900 ‫web page on the Docker docs for the entire Compose 131 00:05:37,330 --> 00:05:39,816 ‫format. In this case, we don't get that with Kubernetes 132 00:05:40,450 --> 00:05:42,810 ‫simply because there's too much complexity, and it's not 133 00:05:42,811 --> 00:05:44,521 ‫all in one place. 134 00:05:45,820 --> 00:05:48,613 ‫It's not even one app. You can actually add more resource 135 00:05:48,970 --> 00:05:51,390 ‫types by adding more things called CRDs 136 00:05:52,220 --> 00:05:53,491 ‫that we'll talk about later. 137 00:05:53,960 --> 00:05:56,730 ‫We can get into that. That basically means you can extend 138 00:05:56,920 --> 00:05:58,509 ‫Kubernetes with more resource types. 139 00:05:58,510 --> 00:06:01,303 ‫More third party stuff, which would even add more options 140 00:06:01,395 --> 00:06:03,966 ‫to this YAML. That's unique to Kubernetes. 141 00:06:04,470 --> 00:06:06,402 ‫Swarm and Docker doesn't allow for that. 142 00:06:06,403 --> 00:06:08,167 ‫Their format is set where this one's 143 00:06:09,590 --> 00:06:11,620 ‫quite extensible, depending on what's installed in your 144 00:06:11,621 --> 00:06:11,789 ‫cluster.