WEBVTT 00:00.840 --> 00:01.170 Okay. 00:01.170 --> 00:05.130 So our first step is going to be in the Google Cloud console. 00:05.160 --> 00:11.550 Look for the Kubernetes clusters under products and pages, and then we're going to go ahead and click 00:11.580 --> 00:15.210 Enable to enable the Kubernetes Engine API. 00:15.240 --> 00:21.720 So let's go ahead and click on Create to create a new Kubernetes cluster so we can see two types of 00:21.720 --> 00:22.560 clusters. 00:22.560 --> 00:24.770 We're going to go ahead and choose the autopilot. 00:24.780 --> 00:29.820 So the autopilot mode will have automatic scaling built in and we're not going to have to manage any 00:29.820 --> 00:31.200 of the nodes ourselves. 00:31.200 --> 00:32.610 It'll be much easier. 00:32.610 --> 00:38.100 We do pay per the pod in this method versus the standard mode which you pay per node. 00:38.130 --> 00:42.630 However, since we're still on our free trial, we're not going to be paying for any of this. 00:42.630 --> 00:50.460 So let's go ahead and continue with the autopilot cluster and we can always switch to a standard cluster 00:50.460 --> 00:56.190 later if we need more customization so you can continue to see more of the great benefits we get with 00:56.190 --> 01:01.360 this cluster autopilot, including logging security and best in class networking. 01:01.360 --> 01:02.550 Let's go ahead and continue. 01:02.560 --> 01:07.780 I'll call the cluster sleeper and I'm going to go ahead and run it in US Central one. 01:07.810 --> 01:10.750 You can feel free to change any region you'd like. 01:10.750 --> 01:14.980 After that, we can stick with the default settings and go ahead and click Create. 01:14.980 --> 01:19.540 You should now see our new sleeper cluster displayed in this grid here. 01:19.540 --> 01:24.820 It'll take a little bit for the cluster to be created, so go ahead and wait for that creation to complete. 01:24.820 --> 01:33.400 So once our cluster is created and it has a green status, we'll go ahead and click on the sleeper cluster 01:33.400 --> 01:38.050 and you can see all of the different metadata about this cluster. 01:38.050 --> 01:43.600 Some of the most important options here are in the automation view where you can see we have vertical 01:43.600 --> 01:48.100 pod auto scaling and node auto provisioning automatically enabled. 01:48.100 --> 01:54.010 And what this means is that when we deploy our application, it will automatically scale to meet the 01:54.010 --> 02:00.130 demand of what's hitting the system based on the CPU and memory usage of our pods. 02:00.160 --> 02:04.000 Google, Kubernetes Engine will be taking care of all of this behind the scenes. 02:04.030 --> 02:06.670 Now feel free to look over at these details. 02:06.670 --> 02:13.030 There's also a bunch of information about the different storage classes, and we additionally get information 02:13.030 --> 02:13.930 about our cluster. 02:13.930 --> 02:21.640 You can see here out of the box we have CPU and memory information as well as logs from our actual Kubernetes 02:21.640 --> 02:22.660 control plane. 02:22.660 --> 02:25.000 So this is really useful information. 02:25.000 --> 02:30.700 However, let's start off by just connecting to this Kubernetes cluster on the Kubectl command line. 02:30.820 --> 02:36.970 To do this, we're going to go ahead and click the Connect button and you can see this command, which 02:36.970 --> 02:41.560 will allow us to automatically configure Kubectl command line access. 02:41.560 --> 02:47.620 So simply copy this, go back into your terminal and paste this in here so your kubeconfig is updated. 02:47.620 --> 02:54.760 Now you should be able to run kubectl get nodes to see that we have currently no nodes running and that's 02:54.760 --> 02:56.740 because we haven't deployed anything. 02:56.740 --> 02:59.260 If we run kubectl get namespaces. 02:59.260 --> 03:02.050 You can see our namespace is out of the box. 03:02.050 --> 03:09.280 I'll go ahead and run Kubectl, get pods in the KUBE system and you can see all the different components 03:09.280 --> 03:16.480 of the Google Cloud engine Kube system here, including a kube DNS and some networking pods. 03:16.510 --> 03:21.840 Again, everything is in a dormant state because we haven't actually deployed anything to this cluster. 03:21.850 --> 03:24.070 Let's go ahead and fix that. 03:24.070 --> 03:31.120 In the root of the project here, I'll CD into our Cades folder and then CD into the sleeper directory 03:31.120 --> 03:39.700 where we can run helm install Sleeper to install our helm chart in this Google Cloud engine cluster. 03:39.730 --> 03:47.440 Our deployment was successful and if we run kubectl get pods out of the box, you can see that the pods 03:47.440 --> 03:53.200 are going to be in a pending state and that's because we don't currently have any nodes yet and this 03:53.200 --> 03:53.860 will change. 03:53.860 --> 04:00.070 So since we now have pending pods, the node autoscaler is going to kick in and automatically provision 04:00.070 --> 04:01.750 nodes for us as needed. 04:01.750 --> 04:07.720 So go ahead and wait a little bit until you can see some nodes in your cluster. 04:07.720 --> 04:13.330 So after a few minutes, if we run kubectl get nodes, now we can see we have three nodes running in 04:13.330 --> 04:20.020 our cluster and we can run kubectl get pods to see that our pods have actually started and they are 04:20.020 --> 04:23.080 now in a create container config error state. 04:23.080 --> 04:28.060 And this is because we haven't configured any of the secrets that our pods rely on. 04:28.060 --> 04:32.560 So if we run kubectl, describe pod on the auth pod. 04:34.520 --> 04:35.270 We'll see. 04:35.270 --> 04:36.560 We have an error secret. 04:36.560 --> 04:38.610 MongoDB not found. 04:38.630 --> 04:42.770 So let's go ahead and create the secrets in our cluster that we know we're going to need. 04:42.800 --> 04:48.020 So let's switch back to our local Kubernetes cluster so we can transfer our secrets easily. 04:48.050 --> 04:55.400 I'll run Kubectl config, get context here and you can see the local Docker desktop context. 04:55.430 --> 05:02.900 We'll switch to this by running kubectl config use context and then enter in your local context name. 05:02.900 --> 05:07.730 And then we can run kubectl get secrets to see all of our existing secrets. 05:07.760 --> 05:13.850 Let's go ahead and start creating some temporary files so that we can create and transfer these secrets. 05:13.880 --> 05:17.480 I'll run kubectl get secret stripe. 05:17.660 --> 05:21.980 I'll put this to YAML and I'll put this to a stripe yaml file. 05:22.790 --> 05:26.940 I'm going to go ahead and repeat the same process for the rest of the secrets. 05:26.960 --> 05:29.600 So we'll switch to MongoDB next. 05:34.830 --> 05:38.220 Then we'll go ahead and do the JWT secret here. 05:42.760 --> 05:46.580 And finally we'll do the google secret in a google doc yaml. 05:46.600 --> 05:52.030 We won't have to do the secret for our GCR json key. 05:52.030 --> 05:57.880 And that's because in our Kubernetes engine cluster we don't need to explicitly define credentials. 05:57.880 --> 06:04.150 We already authenticated to pull images from artifact registry because we're inside of Google Cloud 06:04.150 --> 06:04.880 engine. 06:04.900 --> 06:10.120 So now that we have all of these secrets, go ahead and switch back to your Google Cloud engine context 06:10.120 --> 06:15.790 by copying the name of the existing one that we got from running get context and then paste it in to 06:15.790 --> 06:17.380 switch back to that context. 06:17.410 --> 06:21.820 Now we're going to run kubectl, create and create all of our secrets. 06:21.820 --> 06:25.090 So go ahead and start with the Google doc yaml. 06:25.120 --> 06:30.010 Next we'll do the JWT dot yaml the mongodb dot yaml. 06:30.250 --> 06:36.280 So now that we've created the secrets in our cluster, let's go ahead and delete these secret files 06:36.280 --> 06:41.860 so that we do not commit them and make them vulnerable now that we have our secrets created. 06:41.860 --> 06:47.840 If we run kubectl get pods, we can see that all of our pods are in a running state. 06:47.870 --> 06:54.380 We can even go ahead and get the logs for one of them, including the auth logs right here and see that 06:54.380 --> 06:57.110 our application has successfully started. 06:57.110 --> 07:02.310 So now we have our application fully running and deployed to Google Cloud Engine, which is great. 07:02.330 --> 07:07.700 Let's go ahead and see how we can actually communicate with it by configuring some load balancers.