WEBVTT 00:00.230 --> 00:00.530 Okay. 00:00.530 --> 00:07.940 So to create our EKS cluster on AWS, we're going to use a command line tool called Eksctl, which is 00:07.940 --> 00:13.940 the official CLI for Amazon EKS and will allow us to easily create and manage our clusters from the 00:13.940 --> 00:14.890 command line. 00:14.900 --> 00:23.750 So to get started, let's click on the introduction page and we are@eksctl.io click on Introduction. 00:23.750 --> 00:30.680 And then on the right here, let's click on installation to find out how we can install Eksctl so you 00:30.680 --> 00:32.600 can see for your operating system. 00:32.600 --> 00:37.280 We have different installation commands here is for Windows and for Unix. 00:37.520 --> 00:43.670 So go ahead and copy and paste these commands into your terminal to make sure you have eksctl properly 00:43.670 --> 00:44.540 installed. 00:45.170 --> 00:51.680 So after you have it installed, you should be able to go to your command line and run eksctl get clusters 00:51.680 --> 00:56.120 and this is going to use the default AWS credentials we set up at the beginning. 00:56.720 --> 01:02.880 We want to go ahead and define a new cluster config file in our project that will define how our cluster 01:02.880 --> 01:03.900 is created. 01:04.350 --> 01:10.500 So if we go back to the documentation and go to the home page, we can scroll down until we find a default 01:10.500 --> 01:12.190 cluster dot yaml file. 01:12.210 --> 01:18.540 Let's go ahead and copy this and then we can go back to our root project and create a new cluster dot 01:18.540 --> 01:21.660 yaml and I'll paste in this cluster config. 01:22.490 --> 01:25.910 Where we can change the name to be called Sleeper. 01:25.910 --> 01:29.900 And I'm going to change the region to be closest to me, which is us East one. 01:29.900 --> 01:32.810 Phil feel free to use whichever region you would like. 01:32.810 --> 01:38.060 And then importantly, we have different node groups defined and this is going to be the nodes we have 01:38.060 --> 01:40.080 available to run our workloads. 01:40.100 --> 01:47.450 In our case, we only want to run one node group so we can call it NG1 and we want to change the instance 01:47.450 --> 01:50.150 type to AT2 micro instance. 01:50.240 --> 01:56.750 This type of instance is available on the free tier, so we won't be charged for its usage if we don't 01:56.750 --> 02:02.000 go above the default CPU limits of 750 burst hours a month. 02:02.240 --> 02:06.500 We can also specify the number of nodes we want to have. 02:06.500 --> 02:08.780 In this case, we can just keep this at three. 02:08.780 --> 02:10.880 So now we have this cluster defined. 02:10.910 --> 02:19.100 We can run eksctl, create cluster and then provide dash dash config and then provide dash F and then 02:19.100 --> 02:22.940 provide the cluster dot YAML file. 02:22.940 --> 02:30.680 And now Eksctl is going to execute tasks through CloudFormation to create our cluster. 02:30.680 --> 02:32.910 So go ahead and let this command finish. 02:32.930 --> 02:35.390 It might take some time to create the cluster. 02:35.660 --> 02:42.500 So after some time we can see that our ECS cluster has finished creating and we can see this note here 02:42.500 --> 02:46.670 that our kube config has been updated automatically. 02:46.940 --> 02:52.790 So now we can run kubectl, get nodes and we can see the three nodes that have been provisioned in our 02:52.790 --> 02:53.570 cluster. 02:53.600 --> 03:01.970 We can run eksctl, get node groups and specify the cluster is sleeper to see the current node groups 03:01.970 --> 03:05.630 in our cluster and we can see the size is at three. 03:06.410 --> 03:11.390 Okay, so now we're ready to actually install our helm chart into our ECS cluster. 03:11.600 --> 03:17.840 Firstly, we need to make an update to our helm chart to point our images at our repository. 03:17.840 --> 03:24.000 So let's open up our build spec and then let's copy the name of the reservation's image and we'll go 03:24.000 --> 03:31.500 into our helm chart and open up our templates folder reservations deployment, and then we'll go ahead 03:31.500 --> 03:35.310 and swap out the image to be pointing to ECR. 03:35.340 --> 03:39.120 Now let's go ahead and do the same thing for Auth. 03:39.120 --> 03:43.500 We'll copy the tag and swap this in for the image. 03:43.500 --> 03:49.110 We'll grab the payments image and do this for the payments deployment as well. 03:51.010 --> 03:55.360 And finally, we will grab the notifications repository. 03:58.610 --> 04:00.890 And swap out this image. 04:01.580 --> 04:08.060 So before we deploy our helm chart into X, we need to provide the secrets needed for our deployments. 04:08.090 --> 04:16.490 The easiest way to do this is to run kubectl config, use context, Docker desktop and switch back to 04:16.490 --> 04:18.380 our local Kubernetes cluster. 04:18.860 --> 04:25.340 We can of course now run Kubectl, get secrets to see our secrets that we've created previously that 04:25.340 --> 04:27.110 needed for our deployment. 04:27.500 --> 04:36.460 So now I'm going to run kubectl, get secrets and output this to YAML and pipe it to a secret yaml file. 04:36.470 --> 04:42.800 Then I'm going to open up the newly created secret dot yaml file which is just going to be a temporary 04:42.830 --> 04:47.980 file and I want to get rid of the GCR json key. 04:47.990 --> 04:54.950 So let's remove this first entry here so that we just have the other secrets that we want to carry over. 04:54.950 --> 05:04.520 So now let's run kubectl config, get context to get all of the contexts in our system and our Kubernetes 05:04.520 --> 05:05.450 clusters. 05:05.450 --> 05:09.950 And I want to copy the context for our ECS cluster. 05:09.950 --> 05:18.710 So copy this one and then we can run again kubectl config, use context and paste in our context. 05:18.710 --> 05:24.050 So now we can again run kubectl, get nodes and see our EC2 instances again. 05:24.050 --> 05:33.080 But now importantly I want to run kubectl, create dash f for file and apply the secret yaml we've created 05:33.080 --> 05:35.840 and now all of our secrets will be created. 05:36.140 --> 05:41.930 Then I'll go ahead and make sure we delete this temporary secret file so we don't expose these secret 05:41.930 --> 05:42.860 credentials. 05:42.890 --> 05:49.310 Now that our images have been updated, we can CD into our folder and then CD into the sleeper directory. 05:49.310 --> 05:53.780 And now we're going to run helm, install sleeper and specify the path. 05:53.780 --> 05:56.270 Is the current directory to the helm chart. 05:56.980 --> 05:59.980 Now you can see that our deployment was successful. 06:00.190 --> 06:06.160 So after giving our helm chart a little bit of time, we can run kubectl, get pods and see that all 06:06.160 --> 06:08.020 of our pods are in a running state. 06:08.050 --> 06:14.020 We can then get the logs of our reservations or any one of the pods and see that it has fully started 06:14.020 --> 06:15.730 up and is listening. 06:16.910 --> 06:23.150 Next, let's look at how we can provision a load balancer to expose an externally available URL that 06:23.150 --> 06:24.290 won't change. 06:24.320 --> 06:25.160 So a quick note. 06:25.160 --> 06:33.350 If you run Kubectl, get pods and you find that some pods aren't starting up because of the fact that 06:33.350 --> 06:40.580 there are not enough nodes available, we can easily scale up our existing node group by running eksctl 06:40.610 --> 06:44.330 get node groups in our cluster of sleeper. 06:46.660 --> 06:52.750 And then we can say Eksctl Scale Node Group Ng1. 06:53.370 --> 06:56.400 And set dash n to five. 06:56.430 --> 07:04.440 You can see that our max size also needs to be updated so we can provide a dash capital M five to increase 07:04.440 --> 07:05.820 the maximum number. 07:05.850 --> 07:12.630 So in order to provision a load balancer in ECS, we're going to use the AWS load balancer controller, 07:12.630 --> 07:14.580 which you can find at Kubernetes. 07:14.580 --> 07:20.640 Dash SIGs dot Github.io Slash AWS load Balancer controller. 07:20.790 --> 07:27.300 Now this load balancer controller is automatically going to provision an application load balancer inside 07:27.300 --> 07:28.410 of AWS. 07:28.440 --> 07:35.220 Anytime we create a service with an ingress resource, so to install this load balancer controller, 07:35.220 --> 07:39.860 we click on the deployment link and then click on configure IAM. 07:39.870 --> 07:46.470 Scroll down to the steps to set up the load balancer controller and we'll copy this first command where 07:46.470 --> 07:51.690 we associate an Iam Oidc provider and go ahead and paste this in. 07:51.720 --> 07:56.710 We just need to change the name of our cluster to be the one that we are using. 07:56.710 --> 08:02.560 In this case I'm using the sleeper cluster and then we'll change the region to whatever region we're 08:02.560 --> 08:05.170 using, in this case US East one. 08:05.290 --> 08:09.350 Next, we're going to download the IAM policy based on the region we're in. 08:09.370 --> 08:14.200 So we have one for the US government cloud China and all other regions. 08:14.200 --> 08:19.720 So I'll copy the all other regions, curl this and download it to the current directory. 08:19.720 --> 08:23.710 And then we create a new policy based on this downloaded file. 08:23.710 --> 08:28.600 So copy this command, paste it in and enter to create a new policy. 08:28.630 --> 08:35.470 Finally, we want to create an IAM service account using this policy so paste this final command in 08:35.470 --> 08:41.650 to have eksctl take care of this for us in creating an IAM service account. 08:41.830 --> 08:45.550 So we need to provide the region like we just did before. 08:45.550 --> 08:47.980 So this would be us East one for me. 08:48.220 --> 08:54.520 And then importantly, we need to provide the AWS account ID associated with our account. 08:54.520 --> 09:04.240 So in order to get this, you can go back to the AWS console, go to the IAM dashboard and copy the 09:04.240 --> 09:06.370 account ID in the right here. 09:08.090 --> 09:11.540 And then go ahead and swap this out in this command. 09:13.330 --> 09:17.260 Finally, we need to provide the name of the cluster we're installing this into. 09:17.290 --> 09:20.410 As we've done before, this will stay the same as Sleeper. 09:20.410 --> 09:26.650 So enter this and let Eksctl roll out a CloudFormation to create this. 09:26.770 --> 09:31.060 So finally we're ready to actually install the load balancer controller. 09:31.060 --> 09:39.220 So scroll down to the summary where we get the first command to add the helm repository and paste this 09:39.220 --> 09:39.820 in. 09:39.970 --> 09:46.660 Now that we have the repository, we're going to go ahead and apply the helm chart with this next command. 09:46.690 --> 09:52.420 Now finally we can actually install the helm chart, so we're going to copy this command for clusters 09:52.420 --> 09:57.280 with RSA, copy this command and now paste it in. 09:57.310 --> 10:03.370 Of course, we'll need to update the cluster name as we've done before, so go ahead and update that 10:03.370 --> 10:04.510 to Sleeper. 10:04.870 --> 10:11.020 So go ahead and swap this out to our cluster name of Sleeper and let this helm chart install. 10:11.050 --> 10:18.080 Now, if we run kubectl, get pods in the KUBE system, we can see to load balancer controller pods 10:18.080 --> 10:26.990 running and we can run kubectl logs in the KUBE system and follow this to get some logs and we can see 10:26.990 --> 10:31.550 that the load balancer controller is up and running and watching our services now. 10:31.550 --> 10:37.790 So back in our helm chart, we can remove this temporary IAM policy we created. 10:38.030 --> 10:43.970 Now finally, in order to tell the load balancer controller about our ingress resources, we need to 10:43.970 --> 10:46.880 include some annotations on our ingress. 10:46.880 --> 10:53.030 So let's add a new annotation section here where we define two new annotations, the first of which 10:53.030 --> 11:00.170 is going to be ALB ingress dot kubernetes.io slash scheme internet facing to make sure that this load 11:00.170 --> 11:04.220 balancer is attached to a public subnet that is externally facing. 11:04.220 --> 11:10.910 And then we provide the Kubernetes ingress class ALB to provision an application load balancer. 11:11.120 --> 11:18.950 So let's go ahead and save this and then we can run helm, upgrade Sleeper and provide the root path 11:18.950 --> 11:19.580 here. 11:19.610 --> 11:26.960 Now we can run Kubectl, get ingress and we can see that a new address has been provisioned for us. 11:26.990 --> 11:33.170 It will take some time for the application load balancer to get provisioned and we can even check the 11:33.170 --> 11:40.880 status in AWS by going to the EC2 dashboard and then scrolling down to load balancers. 11:40.880 --> 11:45.830 And then we can see our application load balancer that is in a provisioning state. 11:45.830 --> 11:48.520 So let's go ahead and let this finish provisioning. 11:48.540 --> 11:52.940 After a little bit of time we can see the status has now switched to active. 11:52.970 --> 12:00.290 So if I copy the DNS name now, we can then open up Postman to test out this load balancer. 12:00.290 --> 12:07.220 So now in Postman, if we enter in our load balancer URL and enter slash reservations with a with a 12:07.220 --> 12:13.730 trailing slash and send off this request, we get a response back from our reservations deployment, 12:13.730 --> 12:20.090 which is great to see because we're not passing in any information, but we are able to reach our application 12:20.090 --> 12:23.570 externally from this URL, which is great to see. 12:23.600 --> 12:29.750 Now we have a way to provision an external load balancer and expose our application externally.