1 1 00:00:02,740 --> 00:00:05,200 Let's talk about why you might need Kubernetes. 2 2 00:00:06,100 --> 00:00:08,256 Now as a review, check back with the earlier 3 3 00:00:09,070 --> 00:00:12,760 sections. The first section for Swarm and there's a lecture 4 4 00:00:13,180 --> 00:00:16,269 titled Swarm Mode Built-in Orchestration. 5 5 00:00:16,660 --> 00:00:19,690 That gives you some basics around the problems that 6 6 00:00:19,720 --> 00:00:22,809 orchestration solves and why you might 7 7 00:00:22,810 --> 00:00:25,719 need it. I will stress that that at first, 8 8 00:00:25,960 --> 00:00:28,029 it's definitely important that you understand what 9 9 00:00:28,030 --> 00:00:30,940 orchestration benefits you will need 10 10 00:00:31,240 --> 00:00:33,459 in order to deploy your applications, and whether or not 11 11 00:00:33,460 --> 00:00:35,409 you even need orchestration to begin with. 12 12 00:00:35,950 --> 00:00:38,614 Orchestration is definitely increasing in popularity, but 13 13 00:00:39,250 --> 00:00:41,469 it's not the only way to run containers. 14 14 00:00:41,500 --> 00:00:43,479 We've talked about using Docker runs here. 15 15 00:00:43,690 --> 00:00:45,189 We've talked about Docker Compose. 16 16 00:00:45,460 --> 00:00:49,000 We've talked about other platform offerings and services. 17 17 00:00:49,600 --> 00:00:51,805 I have customers that still run containers on 18 18 00:00:52,630 --> 00:00:55,599 single nodes in AWS without 19 19 00:00:55,600 --> 00:00:57,756 orchestration. They use the features of that 20 20 00:00:58,780 --> 00:01:01,899 platform to create a similar like abstraction 21 21 00:01:01,900 --> 00:01:04,840 as orchestration, where they maybe use auto scaling groups, 22 22 00:01:05,080 --> 00:01:07,539 Elastic Load Balancing, and a lot of other things that 23 23 00:01:07,540 --> 00:01:09,598 we've all used for over a decade to manage 24 24 00:01:10,930 --> 00:01:12,159 our application deployments. 25 25 00:01:12,430 --> 00:01:15,129 They have such a refined system that they just don't see a 26 26 00:01:15,130 --> 00:01:17,790 lot of benefits out of completely changing all that to 27 27 00:01:17,800 --> 00:01:18,800 orchestration. 28 28 00:01:19,120 --> 00:01:21,325 Now, most of us will eventually use some form 29 29 00:01:22,150 --> 00:01:25,269 of container orchestration because that's really the way 30 30 00:01:25,270 --> 00:01:28,029 I think the industry is going, and these are all going to 31 31 00:01:28,030 --> 00:01:30,752 be these extra layers running on top of Docker, or 32 32 00:01:31,330 --> 00:01:33,879 some other runtime, which is what you've learned throughout 33 33 00:01:33,880 --> 00:01:34,880 this course. 34 34 00:01:35,290 --> 00:01:38,079 One of the simple formulas I use for whether or not to use 35 35 00:01:38,080 --> 00:01:39,844 orchestration, are taking the number 36 36 00:01:41,080 --> 00:01:43,299 of servers that I'm going to need for particular 37 37 00:01:43,300 --> 00:01:46,269 environment, and then the change rate 38 38 00:01:46,360 --> 00:01:49,239 of my applications, or the environment itself, 39 39 00:01:49,840 --> 00:01:53,019 and the multiplication of those two really 40 40 00:01:53,080 --> 00:01:54,910 equals the benefit of orchestration. 41 41 00:01:55,200 --> 00:01:58,209 What I mean by that is that orchestration is designed to 42 42 00:01:58,270 --> 00:01:59,593 automate change and monitor 43 43 00:02:01,660 --> 00:02:04,449 the state of things and ensure everything is the state you 44 44 00:02:04,450 --> 00:02:05,450 expect it to be. 45 45 00:02:05,560 --> 00:02:07,840 For instance, apps running in a healthy state. 46 46 00:02:08,620 --> 00:02:10,482 When you're starting out, you may only 47 47 00:02:11,590 --> 00:02:13,942 need a single server, or just a few servers, and 48 48 00:02:14,590 --> 00:02:17,349 if you're not changing your applications very often, let's 49 49 00:02:17,350 --> 00:02:20,530 say you're only changing them once a month or less, then 50 50 00:02:20,590 --> 00:02:23,530 orchestration, and the effort involved in deploying it, 51 51 00:02:23,560 --> 00:02:25,716 managing it, securing it, may be unnecessary 52 52 00:02:27,070 --> 00:02:29,889 at your state. Especially if you're a solo developer 53 53 00:02:30,160 --> 00:02:31,720 or just a very small team. 54 54 00:02:32,020 --> 00:02:35,139 That's where things like Elastic Beanstalk, or 55 55 00:02:35,140 --> 00:02:38,169 Heroku, the application deployment platform, that's where 56 56 00:02:38,170 --> 00:02:41,169 a lot of those start to shine as alternatives 57 57 00:02:41,350 --> 00:02:43,330 to doing your own orchestration. 58 58 00:02:43,690 --> 00:02:45,944 Of course, the most common question that I get 59 59 00:02:46,840 --> 00:02:49,389 from people once they've figured out that they need 60 60 00:02:49,390 --> 00:02:52,330 orchestration, is to decide which one they want. 61 61 00:02:52,930 --> 00:02:54,841 Really at this point in 2019, there are 62 62 00:02:56,110 --> 00:02:59,110 at least two or three major platforms. 63 63 00:02:59,440 --> 00:03:02,439 If you include the Cloud solutions, there might be four 64 64 00:03:02,440 --> 00:03:04,021 or five major platforms there. 65 65 00:03:04,540 --> 00:03:07,029 The ones I talk about in this course are the top two that 66 66 00:03:07,030 --> 00:03:09,429 work everywhere. That's Swarm and Kubernetes. 67 67 00:03:10,030 --> 00:03:12,459 Then you have other ones that are specific to Cloud 68 68 00:03:12,460 --> 00:03:14,273 platforms, like ECS, which is only on 69 69 00:03:15,424 --> 00:03:18,729 AWS, and more traditional offerings 70 70 00:03:18,730 --> 00:03:21,219 that have been around a little bit longer like Cloud 71 71 00:03:21,220 --> 00:03:24,550 Foundry, or Mesos and Marathon. 72 72 00:03:24,880 --> 00:03:27,460 But I think if you're someone who's concerned about running 73 73 00:03:27,610 --> 00:03:30,729 containers on premise, and in the Cloud, 74 74 00:03:30,760 --> 00:03:33,789 or potentially multicloud, you may not want to go with 75 75 00:03:33,790 --> 00:03:36,506 those Cloud specific offerings like ECS 76 76 00:03:37,120 --> 00:03:39,909 because those were around before Kubernetes was. 77 77 00:03:39,930 --> 00:03:42,380 So, that was sort of a legacy solution that Amazon 78 78 00:03:43,090 --> 00:03:45,834 still supports and it's still a neat option, but only if 79 79 00:03:45,880 --> 00:03:48,429 you're specific to AWS and that's the only place you ever 80 80 00:03:48,430 --> 00:03:49,749 plan to deploy containers. 81 81 00:03:50,288 --> 00:03:53,199 For a lot of my customers, and for a lot of my students, 82 82 00:03:53,440 --> 00:03:56,619 the choices are usually, I need something that's hybrid. 83 83 00:03:56,680 --> 00:03:59,081 Meaning that I can run it in my data center or in 84 84 00:03:59,290 --> 00:04:02,409 multicloud. It can't just run in one location 85 85 00:04:02,440 --> 00:04:05,680 only. That comes down to usually 86 86 00:04:05,740 --> 00:04:08,386 Swarm or Kubernetes as their big choices because those 87 87 00:04:08,800 --> 00:04:10,907 are two solutions that are the most popular 88 88 00:04:11,860 --> 00:04:13,030 container orchestrators. 89 89 00:04:13,390 --> 00:04:16,509 They run on every cloud, and in data centers, 90 90 00:04:16,750 --> 00:04:19,004 and even small environments possibly like IoT. 91 91 00:04:19,037 --> 00:04:21,999 If you decide on Kubernetes as 92 92 00:04:22,000 --> 00:04:25,209 your orchestrator, the next big decision is which 93 93 00:04:25,210 --> 00:04:26,829 distribution you're going to use. 94 94 00:04:27,340 --> 00:04:30,159 The first part of that is to figure out if you want a Cloud 95 95 00:04:30,160 --> 00:04:32,365 managed solution, or if you want to roll your 96 96 00:04:33,250 --> 00:04:36,249 own solution with a vendor's product 97 97 00:04:36,490 --> 00:04:39,189 that you would install on the servers yourself. 98 98 00:04:39,700 --> 00:04:42,542 Common distributions that are vendor supported that you've 99 99 00:04:42,790 --> 00:04:45,338 heard me talk about, including Docker Enterprise and 100 100 00:04:45,640 --> 00:04:48,041 there's other ones such as Rancher OpenShift from 101 101 00:04:48,730 --> 00:04:50,837 Red Hat. Canonical, the Ubuntu company, has 102 102 00:04:51,700 --> 00:04:52,700 their own version. 103 103 00:04:53,140 --> 00:04:55,029 VMware has their own version. 104 104 00:04:55,210 --> 00:04:56,499 PKS as well. 105 105 00:04:57,570 --> 00:05:00,269 In fact, there are so many infrastructure and software 106 106 00:05:00,270 --> 00:05:03,209 company vendor solutions for Kubernetes now 107 107 00:05:03,600 --> 00:05:05,519 that it's a little bit overwhelming. 108 108 00:05:05,860 --> 00:05:08,910 I'll give you a link in the resources to a list of the 109 109 00:05:09,630 --> 00:05:11,345 Kubernetes certified distributions. 110 110 00:05:12,000 --> 00:05:15,059 You want to use one of these because they guarantee that 111 111 00:05:15,060 --> 00:05:18,599 the API from Kubernetes is used directly, 112 112 00:05:18,630 --> 00:05:19,949 and that it's fully supported. 113 113 00:05:20,250 --> 00:05:23,249 So that the ideal case is that you can take 114 114 00:05:23,250 --> 00:05:26,639 your workloads and your YAML files that design 115 115 00:05:26,730 --> 00:05:29,219 your infrastructure, and you can move those from one 116 116 00:05:29,220 --> 00:05:31,889 Kubernetes vendor to another and they should work 117 117 00:05:32,160 --> 00:05:33,329 out-of-the-box for most things. 118 118 00:05:33,960 --> 00:05:36,839 Now there's another option I'll just mentioned here which 119 119 00:05:36,840 --> 00:05:39,809 is to use the raw GitHub upstream version 120 120 00:05:39,810 --> 00:05:40,810 of Kubernetes. 121 121 00:05:41,190 --> 00:05:43,770 That is what all the distributions are based on. 122 122 00:05:43,800 --> 00:05:46,860 For example, if you look upstream and you see 123 123 00:05:47,240 --> 00:05:49,290 Kubernetes 1.14 release. 124 124 00:05:49,590 --> 00:05:51,569 Then, when you look at a vendor product, you'd be 125 125 00:05:51,570 --> 00:05:54,420 interested in which Kubernetes versions they support. 126 126 00:05:54,570 --> 00:05:57,750 Usually, vendor products are a few versions behind, 127 127 00:05:57,780 --> 00:05:59,936 but nowadays, the race is that they all just 128 128 00:06:00,750 --> 00:06:02,189 stay up to date as much as possible. 129 129 00:06:02,210 --> 00:06:05,369 So, I tend to see them only one version out of date 130 130 00:06:05,460 --> 00:06:06,460 at most times. 131 131 00:06:07,050 --> 00:06:09,149 Now, the thing that you get out of vendor solutions, 132 132 00:06:09,150 --> 00:06:11,849 besides just that vendor's support options, 133 133 00:06:12,150 --> 00:06:14,790 is also bundling other tools with it. 134 134 00:06:15,000 --> 00:06:16,919 One of the things about Kubernetes that's a little 135 135 00:06:16,920 --> 00:06:19,174 different from Swarm is that it needs a lot of 136 136 00:06:19,890 --> 00:06:22,769 things added to it to really make it easy to use 137 137 00:06:23,070 --> 00:06:25,199 out-of-the-box. So, you probably, when you get a vendor 138 138 00:06:25,200 --> 00:06:27,870 solution, are going to see things like custom 139 139 00:06:27,900 --> 00:06:31,050 authentication solutions, custom Web administration, 140 140 00:06:31,470 --> 00:06:33,528 and custom networking, just to name a few. 141 141 00:06:33,980 --> 00:06:37,079 I will generally recommend to you, 142 142 00:06:37,560 --> 00:06:40,169 without knowing any of your requirements, that you probably 143 143 00:06:40,170 --> 00:06:43,350 don't need the pure upstream version 144 144 00:06:43,440 --> 00:06:45,540 of GitHub's Kubernetes. 145 145 00:06:45,720 --> 00:06:48,990 You don't need to clone the repo of Kubernetes 146 146 00:06:49,020 --> 00:06:50,100 and run just that. 147 147 00:06:50,330 --> 00:06:51,659 Now, it's great for learning. 148 148 00:06:51,660 --> 00:06:54,899 In fact, I recommend starting with that as the way to learn 149 149 00:06:55,230 --> 00:06:58,259 Kubernetes. But, once you get into vendor solutions, 150 150 00:06:58,530 --> 00:07:00,779 those are going to all be a little bit different with 151 151 00:07:00,930 --> 00:07:03,480 security, and networking, and other stuff. 152 152 00:07:03,810 --> 00:07:06,480 So, it's going to be hard for you to learn one and then 153 153 00:07:06,540 --> 00:07:08,700 just assume that the other one acts the same way. 154 154 00:07:09,300 --> 00:07:11,849 However, when you start talking about production, I would 155 155 00:07:11,850 --> 00:07:13,739 expect that you would try to use one of those vendor 156 156 00:07:13,740 --> 00:07:16,337 solutions first because they're going to be easier to 157 157 00:07:16,440 --> 00:07:18,720 manage. You're going to have better support options. 158 158 00:07:19,080 --> 00:07:22,319 Generally, things will just work better and faster 159 159 00:07:22,590 --> 00:07:22,905 out-of-the-box.