1 00:00:02,480 --> 00:00:03,610 ‫So, what's next for Kubernetes? 2 00:00:04,490 --> 00:00:06,559 ‫That's a question I think a lot of us have when we're 3 00:00:06,800 --> 00:00:09,829 ‫looking at how rapidly it has grown, and the entire 4 00:00:09,830 --> 00:00:12,280 ‫ecosystem around it, and how that is just too much 5 00:00:12,980 --> 00:00:14,359 ‫for any one person to handle. 6 00:00:14,660 --> 00:00:15,660 ‫What's the future? 7 00:00:16,219 --> 00:00:19,069 ‫Well, the good news is if I had to predict it, 8 00:00:19,250 --> 00:00:22,069 ‫I think that the future is that it needs to start getting 9 00:00:22,070 --> 00:00:24,618 ‫boring. You'll hear a lot of the founders talk about 10 00:00:25,100 --> 00:00:26,510 ‫this whenever you see them in public. 11 00:00:27,000 --> 00:00:30,019 ‫You know, they'll just talk about how we need to make 12 00:00:30,350 --> 00:00:33,079 ‫infrastructure boring as much as possible 13 00:00:33,410 --> 00:00:35,929 ‫so that we can rely more on the things we do on top of 14 00:00:35,930 --> 00:00:38,674 ‫that. Because really, all of this is here just so we can 15 00:00:38,840 --> 00:00:39,840 ‫get our apps out there, right. 16 00:00:40,510 --> 00:00:43,159 ‫The point of Kubernetes isn't to be Kubernetes itself. 17 00:00:43,580 --> 00:00:46,610 ‫It's to allow you to do the things you want to do faster. 18 00:00:47,090 --> 00:00:49,519 ‫I think for Kubernetes, if you looked at the last few 19 00:00:49,520 --> 00:00:52,369 ‫releases, it's really started to focus on 20 00:00:52,730 --> 00:00:55,549 ‫reliability, stability, security, 21 00:00:56,090 --> 00:00:59,329 ‫just basically getting so stable 22 00:00:59,600 --> 00:01:01,609 ‫that it's just there. 23 00:01:01,760 --> 00:01:03,529 ‫You don't have to worry about it so much. 24 00:01:03,530 --> 00:01:04,729 ‫You don't have to fix it so much. 25 00:01:05,209 --> 00:01:07,279 ‫They do have regular releases, so you definitely get to 26 00:01:07,280 --> 00:01:09,859 ‫check up on the release schedule, and the release notes, 27 00:01:09,890 --> 00:01:12,019 ‫which I've linked to in this video. 28 00:01:12,440 --> 00:01:15,409 ‫One thing that did happen this year, in 2019, 29 00:01:15,740 --> 00:01:17,945 ‫was a big security audit of a lot of the core 30 00:01:18,890 --> 00:01:20,654 ‫code which revealed a lot of things. 31 00:01:21,500 --> 00:01:24,229 ‫In fact, on their blog, they have a full, detailed 32 00:01:24,680 --> 00:01:26,030 ‫analysis of what happened. 33 00:01:26,060 --> 00:01:28,489 ‫I think that's really cool that an open source project as 34 00:01:28,490 --> 00:01:31,185 ‫important and as big as this, not only did the security 35 00:01:31,670 --> 00:01:34,819 ‫analysis from a third party, but revealed all the potential 36 00:01:34,820 --> 00:01:35,820 ‫problems and results. 37 00:01:36,110 --> 00:01:39,049 ‫I think it resulted in a lot of PRs that upfront were for 38 00:01:39,200 --> 00:01:42,139 ‫quick fix things, but also some stuff that 39 00:01:42,320 --> 00:01:44,090 ‫they will eventually fix over time. 40 00:01:44,100 --> 00:01:47,299 ‫It's not so much that it was necessarily vulnerability 41 00:01:47,300 --> 00:01:50,329 ‫based, but more of this area could be 42 00:01:50,330 --> 00:01:52,160 ‫improved so we're going to change it over time. 43 00:01:52,460 --> 00:01:55,253 ‫Another thing you'll see is some of these older concepts, 44 00:01:55,550 --> 00:01:58,519 ‫of when it was a simpler tool, will start to fade away as 45 00:01:58,520 --> 00:02:01,519 ‫they get removed. I think storage plugins that aren't 46 00:02:01,520 --> 00:02:04,609 ‫CSI will eventually get pulled out so that you'll have 47 00:02:04,610 --> 00:02:07,279 ‫to rely on CSI for your storage plugins 48 00:02:07,640 --> 00:02:09,020 ‫instead of the built in stuff. 49 00:02:09,380 --> 00:02:12,222 ‫You'll see different commands like the kubectl 50 00:02:12,590 --> 00:02:15,409 ‫run change and stop giving us warnings because it'll 51 00:02:15,680 --> 00:02:18,889 ‫default to being a simple pod runner rather than having 52 00:02:18,890 --> 00:02:20,427 ‫all the generators built out-of-the-box. 53 00:02:21,050 --> 00:02:23,379 ‫Then you'll see other stuff I mentioned here, like service 54 00:02:23,380 --> 00:02:26,569 ‫side dry run, get stable and more features 55 00:02:26,570 --> 00:02:29,509 ‫around it. Because I think there's a strong push for better 56 00:02:29,540 --> 00:02:31,745 ‫auditing, better understanding of change over 57 00:02:32,630 --> 00:02:35,420 ‫time. What is going to change before I do it, what 58 00:02:35,840 --> 00:02:38,045 ‫did change after I did it, and those sorts of 59 00:02:38,870 --> 00:02:40,189 ‫reporting metrics. 60 00:02:40,700 --> 00:02:43,189 ‫When it comes to third party, that's going to continue to 61 00:02:43,190 --> 00:02:45,836 ‫balloon and grow, and it's really more than any one of 62 00:02:46,220 --> 00:02:47,270 ‫us could possibly know. 63 00:02:47,750 --> 00:02:50,990 ‫Helm 3.0 is just about to be finished. 64 00:02:51,200 --> 00:02:54,530 ‫We're definitely going to have more operators that 65 00:02:54,590 --> 00:02:57,383 ‫will be for third-party tools to make it easier to deploy 66 00:02:57,680 --> 00:02:59,362 ‫those and manage them in Kubernetes. 67 00:03:00,050 --> 00:03:02,689 ‫This is really more of a hope, but I'm 68 00:03:03,110 --> 00:03:05,658 ‫thinking that we're going to get a lot more focus on 69 00:03:05,870 --> 00:03:07,279 ‫declarative workflows. 70 00:03:07,610 --> 00:03:10,969 ‫Because this new theme around DevOps, and more specifically 71 00:03:11,000 --> 00:03:12,211 ‫git-ops, that's git ops, 72 00:03:14,000 --> 00:03:15,649 ‫which I've talked about on my podcast. 73 00:03:16,040 --> 00:03:19,189 ‫The git-ops workflow is a relatively new concept, 74 00:03:19,490 --> 00:03:21,111 ‫but the idea that us operators, 75 00:03:22,610 --> 00:03:24,462 ‫and that's the people that are managing these Kubernetes 76 00:03:25,400 --> 00:03:27,529 ‫clusters, we're really acting as operators. 77 00:03:28,340 --> 00:03:30,790 ‫The operators are taking the advancements from the 78 00:03:31,370 --> 00:03:33,428 ‫software teams where they've had to manage 79 00:03:34,550 --> 00:03:37,489 ‫code, and code change over time, and releases, 80 00:03:37,910 --> 00:03:40,430 ‫which has given the rise of tools like GitHub, right, to 81 00:03:42,020 --> 00:03:45,409 ‫use those same tools for managing our infrastructure 82 00:03:45,410 --> 00:03:47,569 ‫in a declarative way. You've heard me talk about that. 83 00:03:47,990 --> 00:03:50,180 ‫I think that when you look at the feature set over time of 84 00:03:50,480 --> 00:03:52,489 ‫Kubernetes, you can see how it's becoming 85 00:03:53,540 --> 00:03:56,839 ‫more declarative in style, and the feature set and focus 86 00:03:57,200 --> 00:03:58,849 ‫is on that declarative workflow. 87 00:03:59,420 --> 00:04:01,849 ‫I'm hoping that we'll get better tooling and the ones we 88 00:04:01,850 --> 00:04:04,039 ‫have we'll get more features over time. 89 00:04:04,520 --> 00:04:06,799 ‫Another big thing here is Windows Server support. 90 00:04:06,800 --> 00:04:09,770 ‫2019 saw the 91 00:04:09,800 --> 00:04:12,889 ‫big announcement around Windows Server support for server 92 00:04:13,210 --> 00:04:16,009 ‫2019, and that's just in its infancy. 93 00:04:16,250 --> 00:04:19,249 ‫That is something that Swarm is technically ahead 94 00:04:19,250 --> 00:04:20,250 ‫of than Kubernetes. 95 00:04:20,690 --> 00:04:23,532 ‫Where Docker and Swarm have had Windows Server support for 96 00:04:23,570 --> 00:04:25,940 ‫years now, and it's definitely improved over time. 97 00:04:25,970 --> 00:04:28,970 ‫But, they started that with Server 2016 and have been 98 00:04:29,180 --> 00:04:30,649 ‫pushing that forward and making it better. 99 00:04:30,890 --> 00:04:33,669 ‫Whereas, Kubernetes just now in Windows Server 100 00:04:34,030 --> 00:04:37,129 ‫2019 is really saying that they have support. 101 00:04:37,610 --> 00:04:40,109 ‫From people that I've heard talking about Server in 102 00:04:40,730 --> 00:04:43,961 ‫production, Windows Server could still use a lot 103 00:04:44,600 --> 00:04:47,779 ‫more work in the Kubernetes world to be as equal to 104 00:04:47,780 --> 00:04:50,199 ‫Linux. So, I think that's going to be a big area of focus 105 00:04:50,200 --> 00:04:53,089 ‫as more Windows enterprises 106 00:04:53,180 --> 00:04:55,009 ‫adopt these container orchestrators. 107 00:04:55,280 --> 00:04:58,459 ‫A last few things here is definitely the Edge cases 108 00:04:58,460 --> 00:04:59,460 ‫will be worked on. 109 00:04:59,720 --> 00:05:01,220 ‫Things like machine learning. 110 00:05:01,250 --> 00:05:04,130 ‫Things like Edge and small infrastructure 111 00:05:04,380 --> 00:05:07,230 ‫that is going to all be focused because at the beginning of 112 00:05:07,231 --> 00:05:08,231 ‫Kubernetes, it 113 00:05:10,590 --> 00:05:12,213 ‫was very large and very cumbersome, but they're pulling a lot of it out 114 00:05:12,230 --> 00:05:14,104 ‫and making it easier to deploy. 115 00:05:14,580 --> 00:05:17,324 ‫That's why you're seeing tools like kubeadm come out and 116 00:05:18,030 --> 00:05:19,030 ‫be able to deploy HA clusters. 117 00:05:19,290 --> 00:05:21,720 ‫It's fully secure and if fault tolerant 118 00:05:22,650 --> 00:05:25,113 ‫out-of-the-box. Those are all things that are sort of 119 00:05:25,114 --> 00:05:26,190 ‫coming in to fruition now. 120 00:05:26,430 --> 00:05:30,269 ‫Part of that future is knowing about other 121 00:05:30,270 --> 00:05:31,312 ‫related projects. This is just really a 122 00:05:33,450 --> 00:05:34,899 ‫quick list of the things that I haven't mentioned in this course that 123 00:05:35,970 --> 00:05:38,549 ‫you might want to check out. Because Kubernetes itself has 124 00:05:38,550 --> 00:05:40,755 ‫become the platform that all other things are 125 00:05:41,850 --> 00:05:44,371 ‫starting to be built on. In fact, that was really the 126 00:05:44,372 --> 00:05:46,314 ‫original goals from the authors of the project. 127 00:05:46,520 --> 00:05:49,410 ‫They never really meant for us to use Kubernetes directly 128 00:05:49,480 --> 00:05:52,160 ‫in terms of the raw, open source 129 00:05:52,520 --> 00:05:53,520 ‫Kubernetes. 130 00:05:53,860 --> 00:05:56,819 ‫They really meant for other people to build abstractions on 131 00:05:56,820 --> 00:05:58,854 ‫top of it for us to run our workloads. 132 00:05:59,300 --> 00:06:01,771 ‫That's why you see distributions coming out, in a lot of 133 00:06:01,772 --> 00:06:05,189 ‫cases, because they're building another layer on top to 134 00:06:05,190 --> 00:06:07,011 ‫do that. In this case, we're seeing all 135 00:06:08,670 --> 00:06:11,161 ‫sorts of other infrastructure come out for doing other 136 00:06:11,162 --> 00:06:12,162 ‫things. First up, is Knative. 137 00:06:12,660 --> 00:06:15,208 ‫This is around the server lists, and it's definitely 138 00:06:15,601 --> 00:06:19,649 ‫an official CNCF project so it's tightly related 139 00:06:19,650 --> 00:06:20,790 ‫to the Kubernetes world. 140 00:06:21,450 --> 00:06:23,449 ‫If you're interested in server lists, it's definitely one 141 00:06:23,450 --> 00:06:24,779 ‫the projects you want to check out. 142 00:06:24,780 --> 00:06:27,945 ‫Next up, a couple of projects from Rancher are 143 00:06:27,970 --> 00:06:29,270 ‫K3s and K3os. 144 00:06:30,360 --> 00:06:31,536 ‫K3s is essentially their 145 00:06:33,330 --> 00:06:36,390 ‫team taking the complex deployment and management of 146 00:06:36,460 --> 00:06:38,665 ‫Kubernetes and simplifying it down, stripping 147 00:06:39,540 --> 00:06:41,603 ‫out all the unnecessary things that come with it. 148 00:06:42,600 --> 00:06:43,880 ‫Maybe some of the legacy commands and code. 149 00:06:44,070 --> 00:06:46,731 ‫Maybe some of the storage drivers that you no longer need 150 00:06:46,850 --> 00:06:47,879 ‫if you have CSI. 151 00:06:48,190 --> 00:06:50,939 ‫That sort of stuff. They just pull it all out, and they 152 00:06:50,940 --> 00:06:52,551 ‫give you a really easy database. 153 00:06:52,970 --> 00:06:53,970 ‫It doesn't even use etcd out-of-the-box. 154 00:06:54,820 --> 00:06:56,369 ‫It uses a simpler database. 155 00:06:56,490 --> 00:06:58,890 ‫It's really meant for things originally like IoT. 156 00:06:59,770 --> 00:07:02,822 ‫But now, with their goal of being make 157 00:07:03,250 --> 00:07:05,602 ‫Kubernetes as simple as Swarm, which it was said 158 00:07:06,480 --> 00:07:08,832 ‫by Darren Shepherd, their CTO and co-founder, at 159 00:07:09,960 --> 00:07:11,811 ‫DockerCon this year. It was a pretty interesting statement. 160 00:07:12,550 --> 00:07:15,392 ‫He was really saying that, you know, Swarm does so well in 161 00:07:15,810 --> 00:07:19,019 ‫the deployment, and ease of use, and the 162 00:07:19,020 --> 00:07:20,632 ‫minimal impact. It's a very small binary. 163 00:07:21,440 --> 00:07:22,740 ‫It has very little overhead in 164 00:07:24,690 --> 00:07:27,061 ‫terms of the infrastructure. Kubernetes is the total 165 00:07:27,062 --> 00:07:29,701 ‫opposite of that. They're trying to find the middle ground. 166 00:07:29,702 --> 00:07:32,005 ‫Is it possible if we strip out enough stuff and 167 00:07:33,210 --> 00:07:35,810 ‫still make it true Kubernetes, can we make it super 168 00:07:38,250 --> 00:07:39,660 ‫easy to deploy on small systems like ARM, Raspberry Pis, 169 00:07:39,940 --> 00:07:41,811 ‫stuff like that. So, that's a project to watch. 170 00:07:41,960 --> 00:07:45,149 ‫K3os is an operating 171 00:07:45,150 --> 00:07:47,422 ‫system with K3s on top of it. 172 00:07:47,450 --> 00:07:50,819 ‫It's a very minimal Linux install that's 173 00:07:50,820 --> 00:07:54,209 ‫designed to run K3s on 174 00:07:54,210 --> 00:07:57,299 ‫small appliances. That's a pretty new one but an 175 00:07:57,300 --> 00:08:00,191 ‫interesting project nonetheless. Another really big area of 176 00:08:00,211 --> 00:08:02,857 ‫focus, which you will hear me talk about a lot more on 177 00:08:03,210 --> 00:08:06,509 ‫my podcast, is service mesh, which is a new concept the 178 00:08:06,510 --> 00:08:08,482 ‫last couple of years, and really a new term. 179 00:08:08,720 --> 00:08:10,770 ‫We haven't really used that word in the industry before. 180 00:08:11,340 --> 00:08:12,340 ‫Service mesh is the 181 00:08:14,281 --> 00:08:16,951 ‫idea of this proxy layer throughout the entire cluster, 182 00:08:17,320 --> 00:08:20,460 ‫not just for incoming connections from the Internet, but 183 00:08:20,470 --> 00:08:22,824 ‫really for all the parts of your app. 184 00:08:24,030 --> 00:08:26,759 ‫It becomes a middleman to controlling, 185 00:08:27,580 --> 00:08:29,981 ‫in terms of security, in terms of monitoring, and 186 00:08:30,780 --> 00:08:32,544 ‫routing to the proper locations, all 187 00:08:34,120 --> 00:08:36,200 ‫the traffic for all the parts of your distributed app. 188 00:08:36,610 --> 00:08:38,020 ‫It's a series of projects that 189 00:08:40,500 --> 00:08:42,060 ‫came out of the problem of microservices. If you've ever 190 00:08:42,061 --> 00:08:45,331 ‫done any microservices, one of the real challenges is, is 191 00:08:45,340 --> 00:08:48,120 ‫what was in a single binary on a single server and 192 00:08:49,860 --> 00:08:52,261 ‫relatively easy to troubleshoot becomes dozens of 193 00:08:52,471 --> 00:08:54,022 ‫containers, over dozens of servers. 194 00:08:54,240 --> 00:08:56,690 ‫That becomes very difficult to troubleshoot unless 195 00:08:57,510 --> 00:08:59,030 ‫you have great networking tools. 196 00:08:59,110 --> 00:09:01,130 ‫So, service mesh is pointed 197 00:09:03,090 --> 00:09:05,687 ‫at that problem and trying to become a standard, with 198 00:09:06,570 --> 00:09:08,460 ‫standards behind it, around putting 199 00:09:10,080 --> 00:09:13,440 ‫a layer there to have increased visibility, monitoring, 200 00:09:13,450 --> 00:09:17,240 ‫troubleshooting and security around our 201 00:09:17,250 --> 00:09:18,525 ‫distributed apps and our microservices.