WEBVTT 00:00.020 --> 00:00.920 Welcome back everybody. 00:00.920 --> 00:05.030 By the end of this video we're going to set up a Kubernetes cluster on AWS. 00:05.030 --> 00:11.540 We're going to have worker nodes where each one is an actual virtual machine that's running our container 00:11.540 --> 00:13.040 workloads on the cloud. 00:13.040 --> 00:19.280 We're going to have master nodes that orchestrate how, where and when these containers run. 00:19.280 --> 00:21.620 We're going to have a load balancer. 00:21.620 --> 00:28.580 So remember that a load balancer is simply a server that receives traffic from the outside and distributes 00:28.580 --> 00:32.120 it, load balances it across our worker nodes. 00:32.120 --> 00:40.550 Remember that if I go back to a previous diagram, uh, the ingress controller, your ingress is the 00:40.550 --> 00:47.150 entry point of your cluster such that whenever you make requests to your load balancer, it eventually 00:47.150 --> 00:51.440 ends up going to the ingress controller, which decides where to forward that traffic. 00:51.440 --> 00:57.590 So the load balancer is what receives traffic from the outside, and the ingress is the entry point. 00:57.590 --> 00:59.960 But let's go back here and look at the big picture. 00:59.960 --> 01:01.680 We want to set up a Kubernetes cluster. 01:01.710 --> 01:01.920 Okay. 01:01.950 --> 01:05.940 We're tired of working on a single node cluster on our local machines. 01:05.940 --> 01:12.900 We want to scale up, and AWS makes it very easy to set up Kubernetes clusters using its Elastic Kubernetes 01:12.900 --> 01:13.800 service. 01:13.800 --> 01:20.100 So before we start using that service to set up our cluster, um, you should be able to write this 01:20.100 --> 01:27.750 command AWS Configure list, get a secret key, and get the access key for your IAM user that you've 01:27.750 --> 01:32.250 created, the IAM user that ideally you've given administrative privileges. 01:32.250 --> 01:39.450 That's really important, and you've set a region that is geographically close to wherever you are to 01:39.480 --> 01:43.410 minimize latency and improve network performance. 01:43.410 --> 01:46.110 So make sure that you've got all that set up. 01:46.110 --> 01:52.830 You've got the access key not for the root user, but for the IAM user with administrative privileges. 01:52.860 --> 01:53.070 Okay. 01:53.100 --> 01:56.550 It's really important that you use the IAM user, not the root user. 01:56.550 --> 01:59.490 If you haven't done that, please go back and follow the articles. 01:59.520 --> 01:59.880 Okay. 01:59.910 --> 02:04.230 If you've got all that set up, um, we're pretty much ready to set up our cluster. 02:04.230 --> 02:12.540 So another thing I would have expected you to do is set up the ECS command line utility. 02:12.540 --> 02:14.070 So we'll say CTL. 02:14.100 --> 02:18.120 If you execute this you should be able to get some output. 02:19.080 --> 02:19.680 All right. 02:19.680 --> 02:24.000 So you've got your AWS command line configured. 02:24.000 --> 02:27.570 You've got Eksctl set up. 02:28.140 --> 02:29.400 Let's have some fun. 02:29.400 --> 02:31.050 And we're going to create a cluster. 02:31.050 --> 02:37.050 And the command by the way at this point it doesn't matter which directory you're in. 02:37.080 --> 02:42.090 We're going to say eksctl create cluster. 02:42.120 --> 02:43.110 Go figure. 02:43.800 --> 02:44.520 All right. 02:44.520 --> 02:48.420 The cluster name you can call it whatever the heck you want. 02:48.450 --> 02:50.250 I'm just going to call it my cluster. 02:50.280 --> 02:56.910 If you are working for some organization that cluster would typically be your organization name dash 02:56.910 --> 03:02.290 region So my region is US East two. 03:02.320 --> 03:06.460 Please choose the region that is geographically closest to you. 03:06.490 --> 03:11.650 So if you go to AWS you can find the list of regions here. 03:11.680 --> 03:15.730 Choose the one that makes the most sense for your location. 03:15.760 --> 03:16.870 All right. 03:17.320 --> 03:19.450 Mine is US East two. 03:19.480 --> 03:21.790 And then we specify the node type. 03:21.820 --> 03:22.750 All right. 03:24.160 --> 03:31.030 So basically here you're specifying the resource what kind of resource requirements you want from your 03:31.030 --> 03:31.990 worker nodes. 03:32.020 --> 03:32.800 Okay. 03:32.830 --> 03:37.810 I'm going to say T3 dot medium I'll go over some other options in a bit. 03:37.810 --> 03:40.390 So T3 dot medium. 03:40.390 --> 03:44.890 This has two virtual CPUs four gigabytes of memory. 03:44.890 --> 03:51.640 It's very suitable for medium workloads application servers medium databases. 03:52.360 --> 04:00.980 Uh below that is T3 dot small um two virtual CPUs here, two gigabytes of memory, also suitable for 04:01.010 --> 04:02.540 medium workloads. 04:03.110 --> 04:05.570 There is also T3 micro. 04:05.600 --> 04:08.660 This one only has one gigabyte of memory. 04:08.810 --> 04:12.350 Um, we'll probably end up using T3 medium for this course. 04:12.350 --> 04:16.310 So above T3 medium is M5 large. 04:16.820 --> 04:18.410 Um, you know what? 04:18.410 --> 04:19.460 I'm not going to list them all. 04:19.460 --> 04:22.250 You can go on the AWS documentation. 04:22.280 --> 04:25.400 Uh, T3 medium should suit our purposes just fine. 04:25.430 --> 04:30.530 Okay, so it's pretty cool that we can decide the resource requirements for our worker nodes, and then 04:30.530 --> 04:33.440 we can decide how many worker nodes we want. 04:33.470 --> 04:35.990 We can just say two worker nodes. 04:36.020 --> 04:38.720 Let's just create two worker nodes in the cluster. 04:38.750 --> 04:41.180 You might be wondering what about the master nodes? 04:41.180 --> 04:45.650 The master nodes will already be managed and provisioned by AWS. 04:45.680 --> 04:51.140 We don't have direct control over the number or the configuration of the master nodes, but we do have 04:51.140 --> 04:58.760 control over how many worker nodes we want and their resource requirements, their configuration That's 04:58.760 --> 05:02.510 enough to create a Kubernetes cluster on AWS. 05:02.510 --> 05:10.790 And by virtue of executing this command, our kubectl command line, it's context is going to automatically 05:10.790 --> 05:14.930 be set to our Kubernetes cluster on the cloud. 05:14.930 --> 05:19.040 So it's going to ditch our Docker desktop Kubernetes cluster. 05:19.040 --> 05:23.060 And it's going to start working with the Kubernetes cluster on AWS. 05:23.090 --> 05:24.320 I can't wait to show you. 05:24.350 --> 05:26.660 Let's just go ahead and execute this command. 05:27.680 --> 05:30.950 This is going to take a really, really long time. 05:31.400 --> 05:38.720 So what I'm going to do is see you in a bit. 05:44.510 --> 05:44.990 All right. 05:45.020 --> 05:47.030 My Kubernetes cluster was just created. 05:47.030 --> 05:54.410 And now you can see that my kubectl context was switched to the cluster that I have on AWS. 05:54.410 --> 06:01.980 Because upon saying kubectl get nodes, it showed me the two worker nodes that I have in US East two. 06:02.010 --> 06:03.660 That's pretty darn cool. 06:03.690 --> 06:10.860 And if you go to your AWS dashboard, so make sure that you're logged in as the IAM user that you created 06:10.860 --> 06:11.880 in the articles. 06:11.880 --> 06:15.180 If you forgot how to do that, go to IAM. 06:17.340 --> 06:18.000 All right. 06:18.000 --> 06:19.710 I'll just show you real quick. 06:19.740 --> 06:25.350 Use the sign in URL and then sign in using your credentials. 06:25.380 --> 06:29.640 Okay, I'm already signed in as the IAM user developer. 06:30.060 --> 06:31.680 It's going to make me reload now. 06:32.580 --> 06:33.330 Darn it. 06:33.780 --> 06:36.720 Okay, whatever I got to show you at least. 06:39.420 --> 06:41.070 All right, so I'm signed in. 06:41.070 --> 06:45.240 So if I go to my elastic Kubernetes service. 06:47.490 --> 06:50.730 You can see that I've got a cluster deployed on AWS. 06:50.760 --> 06:51.540 Beautiful. 06:51.570 --> 06:56.970 Now, if for some reason you don't get a cluster, but you very clearly have it deployed, this cluster 06:56.970 --> 06:59.090 was deployed in US East two. 06:59.120 --> 07:04.310 So you might have specified the wrong, um, region by mistake. 07:04.340 --> 07:04.580 All right. 07:04.610 --> 07:07.970 So if I say us East one, we're not going to see a cluster. 07:08.000 --> 07:11.720 Our worker nodes are in US East two. 07:11.750 --> 07:16.100 Our nodes that make up the Kubernetes cluster are in US East two. 07:16.520 --> 07:17.300 Okay. 07:17.330 --> 07:18.950 Pretty cool stuff. 07:19.220 --> 07:21.290 Look how far we've gotten in this course. 07:21.320 --> 07:21.740 All right. 07:21.770 --> 07:27.830 Now I'm going to say kubectl config current context, just to show you that the context has been switched 07:28.070 --> 07:34.760 such that our kubectl commands will now interact with our cluster in AWS. 07:35.300 --> 07:36.020 Okay. 07:36.050 --> 07:37.700 Anything else I wanted to show you? 07:37.730 --> 07:42.410 Um, what I want to do is get you to copy the link. 07:42.440 --> 07:43.700 I should be pointing here, I think. 07:43.730 --> 07:46.130 Copy the link in your resources folder. 07:46.160 --> 07:46.400 Sorry. 07:46.430 --> 07:47.090 Not copy the link. 07:47.120 --> 07:52.550 Copy the kubectl command in your resources folder because that kubectl command. 07:52.550 --> 08:03.740 What it's going to do is deploy Nginx ingress controller on our cluster, and thereby orchestrate the 08:03.740 --> 08:09.920 creation of a load balancer that allows us to make public requests to our cluster. 08:09.950 --> 08:15.860 That's why we typically see that the ingress is the entry point of our cluster, because it works alongside 08:15.860 --> 08:22.490 the load balancer to allow public requests to allow public traffic into our container workloads. 08:22.520 --> 08:23.630 All right. 08:25.100 --> 08:34.100 Now if I go ahead and say kubectl get namespaces, here are the namespaces that divide our Kubernetes 08:34.100 --> 08:37.550 cluster on AWS into logical boundaries. 08:37.580 --> 08:44.510 Here I'm going to say kubectl get services inside of ingress engine x. 08:46.700 --> 08:47.900 R dash n. 08:47.930 --> 08:50.060 Sorry guys it's so late again. 08:50.630 --> 08:56.150 And this is the external IP that's going to allow us to make public requests to our cluster. 08:56.150 --> 08:57.620 So we've got that set up. 08:57.650 --> 09:03.200 The last thing I want to do is I'm only going to deploy the Great submission portal. 09:03.230 --> 09:03.770 Okay. 09:03.770 --> 09:07.310 We could deploy all of the other applications, but there's no point. 09:07.340 --> 09:09.140 We're being charged for this. 09:09.470 --> 09:11.900 Um, whether we deploy one or the other. 09:11.930 --> 09:17.090 All we're doing is deploying a helm chart, which, as you've seen, is really, really easy. 09:17.090 --> 09:21.440 So in the last section, we set up a helm package for the great submission portal. 09:21.440 --> 09:27.170 If for some reason you skipped that section, you can just say helm package followed by a dot to create 09:27.170 --> 09:32.300 a package that packages up all the configuration files for the Great Submission Portal application, 09:32.330 --> 09:38.570 and then we can release the contents of that package into our Kubernetes cluster on AWS, into this 09:38.570 --> 09:38.990 cluster. 09:38.990 --> 09:44.180 Right over here, we can release its contents by saying great submission portal release. 09:44.180 --> 09:46.970 That's going to be the name of our helm release. 09:47.540 --> 09:52.010 And we can create a helm release from the Great Submission Portal package. 09:54.860 --> 09:55.820 Namespaces. 09:55.820 --> 09:57.750 Great submission not found. 09:57.780 --> 09:58.830 Ah, I forgot about that. 09:58.830 --> 10:04.440 So these templates are trying to deploy artifacts into a great submission namespace, but we don't have 10:04.440 --> 10:06.300 such a namespace in our cluster. 10:06.300 --> 10:09.390 So let's say kubectl create namespace. 10:09.390 --> 10:10.470 Great submission. 10:10.500 --> 10:17.160 Isn't it cool how seamlessly we can interact with the AWS cluster through our command line at very, 10:17.160 --> 10:18.780 very minimal latency. 10:18.810 --> 10:20.700 All right kubectl create namespace. 10:20.700 --> 10:22.050 Great submission. 10:22.770 --> 10:27.480 Now we can go ahead and install our helm release. 10:27.480 --> 10:29.910 It already installed this one. 10:29.910 --> 10:35.520 Even though this helm release failed to deploy any of these artifacts, it was still installed. 10:35.520 --> 10:37.080 So we need to uninstall it. 10:37.110 --> 10:38.700 Helm uninstall. 10:39.510 --> 10:40.410 Great submission. 10:40.410 --> 10:41.790 Portal release. 10:42.210 --> 10:43.740 Reinstall it. 10:45.870 --> 10:46.920 Wonderful. 10:47.040 --> 10:48.120 All right. 10:48.300 --> 10:53.010 Um, so make sure that you're logged in as the IAM user first and foremost. 10:53.010 --> 10:57.640 Otherwise you're not going to be able to access or look at any of the resources in the cluster because 10:57.640 --> 11:02.020 you need to be signed in to the IAM user that created the cluster. 11:02.050 --> 11:02.950 Okay. 11:03.310 --> 11:05.830 The one with administrative privileges. 11:05.860 --> 11:12.340 If I go to resources here, we can actually view all the configurations that we've deployed. 11:12.340 --> 11:16.810 So we've got the ingress engine X workload. 11:17.590 --> 11:18.640 Let's go on. 11:18.640 --> 11:21.250 Um deployments. 11:21.280 --> 11:23.320 Great submission portal. 11:23.860 --> 11:25.150 Um no stateful sets. 11:25.150 --> 11:26.860 I'm not going to deploy the database. 11:26.860 --> 11:30.100 Um, simply because we're paying money for this stuff. 11:30.100 --> 11:30.550 Guys. 11:30.550 --> 11:34.180 No sense prototyping anymore if you already know how it works. 11:34.180 --> 11:36.040 All we did was deploy a helm release. 11:36.070 --> 11:38.980 Okay, we can look at the cluster, look at the nodes. 11:38.980 --> 11:41.170 Here are our two worker nodes. 11:41.200 --> 11:42.250 Pretty cool. 11:42.280 --> 11:44.020 The amount of things we can look at. 11:45.280 --> 11:46.840 Remember that deployments. 11:46.840 --> 11:49.600 They manage a replica set of pods. 11:49.600 --> 11:54.220 We've only defined one pod replica, so we only see the following. 11:54.220 --> 11:56.990 And all of this is being orchestrated by helm. 11:57.020 --> 12:02.060 Pretty, pretty cool stuff, because the great Submission Portal app is the entry point of the great 12:02.060 --> 12:03.020 submission platform. 12:03.020 --> 12:05.990 It's the front end that browsers are going to interact with. 12:06.020 --> 12:08.270 It has an ingress resource. 12:08.300 --> 12:14.450 Okay, so the ingress resource for the Great Submission portal, it doesn't define a specific host, 12:14.450 --> 12:18.410 which means it's going to map any URL request with any host. 12:18.410 --> 12:23.210 That starts with the following path to the Great Submission Portal service. 12:23.240 --> 12:23.930 Okay. 12:23.930 --> 12:26.660 Which means if I make a request. 12:27.170 --> 12:30.710 Moment of truth guys kubectl get services. 12:30.830 --> 12:36.290 We need to get the load balancer dash n ingress engine x. 12:37.970 --> 12:43.820 If I make a request to this URL that starts with the empty path slash, that's going to get redirected 12:43.820 --> 12:46.790 to the great Submission portal cluster IP service. 12:46.790 --> 12:51.890 So the ingress rule determines that that client request is going to get forwarded to this cluster IP 12:51.890 --> 12:58.640 service, which will in turn forward it to one of the pod replicas As you saw, we only have one pod 12:58.640 --> 13:04.460 replica here, but then that pod replica is going to process the request and send us back a response 13:04.460 --> 13:05.780 to our browser. 13:05.810 --> 13:08.510 Okay, you're probably like Ryan, just shut up and do it. 13:08.540 --> 13:12.140 Let's do it so we can specify an empty path or not. 13:12.860 --> 13:14.090 There you go. 13:14.120 --> 13:14.480 All right. 13:14.480 --> 13:18.920 I'm not going to deploy the API or Mongo because we're paying for these resources. 13:18.920 --> 13:22.040 And I don't want you to pay too much money. 13:22.130 --> 13:26.960 We probably just got charged like a couple cents right now, so don't worry too much about it. 13:27.440 --> 13:34.070 I'm going to go ahead and say helm and install the great submission portal release. 13:34.760 --> 13:40.100 So I guess one point that I really wanted to drive home is that the great submission portal is ultimately 13:40.100 --> 13:45.710 the entry point of the great submission platform, and if we were to deploy the Great Submission API, 13:45.710 --> 13:49.670 it already has all the configurations that it needs to interact with the cluster IP service. 13:49.670 --> 13:54.230 So if we were to deploy the following helm releases, everything would work seamlessly. 13:54.230 --> 13:59.970 All right That's the beautiful thing about Kubernetes is it's very portable in the sense that you only 13:59.970 --> 14:05.760 have to define your configurations once, and you can scale them to any cluster that you want. 14:05.790 --> 14:11.310 The great submission portal is already orchestrated to interact with the Great Submission API, and 14:11.310 --> 14:17.130 the Great Submission API has already been orchestrated to interact with this MongoDB database. 14:17.160 --> 14:17.730 All right. 14:17.760 --> 14:23.010 You just have to define your configurations once and you can deploy them wherever you want. 14:23.010 --> 14:26.760 That is one of the many benefits of using a Kubernetes cluster. 14:26.760 --> 14:35.430 Because we're running everything on a cluster, it abstracts away all the underlying AWS infrastructure 14:35.430 --> 14:36.090 details. 14:36.120 --> 14:36.630 All right. 14:36.630 --> 14:39.810 You don't have to worry about this platform or that platform. 14:39.810 --> 14:44.310 Kubernetes runs the same regardless of the cloud provider that you're using. 14:44.340 --> 14:44.970 Okay. 14:44.970 --> 14:51.690 These configurations will scale to any Kubernetes cluster on any cloud provider that you use. 14:51.720 --> 14:53.490 Now enough talking. 14:53.490 --> 14:57.630 Let's finalize this entire course by deleting our Kubernetes cluster. 14:57.630 --> 15:02.910 We don't want to keep getting charged to run nodes that we're not going to use. 15:02.910 --> 15:07.500 So we're going to once again leverage the Eksctl command. 15:07.500 --> 15:12.720 We're going to delete the cluster that's named whatever you called your cluster. 15:13.140 --> 15:14.700 My cluster. 15:16.560 --> 15:17.070 All right. 15:17.070 --> 15:20.730 As this is happening, I just want to say that I hope you enjoyed this course. 15:20.730 --> 15:25.590 When I first created this course, I had a vision of, hey, can I take someone from not knowing any 15:25.590 --> 15:30.240 Kubernetes at all to eventually deploy their container workloads on the cloud? 15:30.240 --> 15:35.730 And if you were able to benefit from this type of curriculum, then I would really appreciate it if 15:35.730 --> 15:39.570 you were to leave me a review at the end of this course to be very transparent. 15:39.570 --> 15:44.580 Reviews helped me a lot in getting discovered as an instructor, so if you'd be kind enough to leave 15:44.580 --> 15:48.660 one, if this course benefited you, I would really, really appreciate it. 15:48.660 --> 15:53.010 Thank you so much for trusting me with your education, and I hope I get to see you again