Okay.
So our first step is going to be in the Google Cloud console.
Look for the Kubernetes clusters under products and pages, and then we're going to go ahead and click
Enable to enable the Kubernetes Engine API.
So let's go ahead and click on Create to create a new Kubernetes cluster so we can see two types of
clusters.
We're going to go ahead and choose the autopilot.
So the autopilot mode will have automatic scaling built in and we're not going to have to manage any
of the nodes ourselves.
It'll be much easier.
We do pay per the pod in this method versus the standard mode which you pay per node.
However, since we're still on our free trial, we're not going to be paying for any of this.
So let's go ahead and continue with the autopilot cluster and we can always switch to a standard cluster
later if we need more customization so you can continue to see more of the great benefits we get with
this cluster autopilot, including logging security and best in class networking.
Let's go ahead and continue.
I'll call the cluster sleeper and I'm going to go ahead and run it in US Central one.
You can feel free to change any region you'd like.
After that, we can stick with the default settings and go ahead and click Create.
You should now see our new sleeper cluster displayed in this grid here.
It'll take a little bit for the cluster to be created, so go ahead and wait for that creation to complete.
So once our cluster is created and it has a green status, we'll go ahead and click on the sleeper cluster
and you can see all of the different metadata about this cluster.
Some of the most important options here are in the automation view where you can see we have vertical
pod auto scaling and node auto provisioning automatically enabled.
And what this means is that when we deploy our application, it will automatically scale to meet the
demand of what's hitting the system based on the CPU and memory usage of our pods.
Google, Kubernetes Engine will be taking care of all of this behind the scenes.
Now feel free to look over at these details.
There's also a bunch of information about the different storage classes, and we additionally get information
about our cluster.
You can see here out of the box we have CPU and memory information as well as logs from our actual Kubernetes
control plane.
So this is really useful information.
However, let's start off by just connecting to this Kubernetes cluster on the Kubectl command line.
To do this, we're going to go ahead and click the Connect button and you can see this command, which
will allow us to automatically configure Kubectl command line access.
So simply copy this, go back into your terminal and paste this in here so your kubeconfig is updated.
Now you should be able to run kubectl get nodes to see that we have currently no nodes running and that's
because we haven't deployed anything.
If we run kubectl get namespaces.
You can see our namespace is out of the box.
I'll go ahead and run Kubectl, get pods in the KUBE system and you can see all the different components
of the Google Cloud engine Kube system here, including a kube DNS and some networking pods.
Again, everything is in a dormant state because we haven't actually deployed anything to this cluster.
Let's go ahead and fix that.
In the root of the project here, I'll CD into our Cades folder and then CD into the sleeper directory
where we can run helm install Sleeper to install our helm chart in this Google Cloud engine cluster.
Our deployment was successful and if we run kubectl get pods out of the box, you can see that the pods
are going to be in a pending state and that's because we don't currently have any nodes yet and this
will change.
So since we now have pending pods, the node autoscaler is going to kick in and automatically provision
nodes for us as needed.
So go ahead and wait a little bit until you can see some nodes in your cluster.
So after a few minutes, if we run kubectl get nodes, now we can see we have three nodes running in
our cluster and we can run kubectl get pods to see that our pods have actually started and they are
now in a create container config error state.
And this is because we haven't configured any of the secrets that our pods rely on.
So if we run kubectl, describe pod on the auth pod.
We'll see.
We have an error secret.
MongoDB not found.
So let's go ahead and create the secrets in our cluster that we know we're going to need.
So let's switch back to our local Kubernetes cluster so we can transfer our secrets easily.
I'll run Kubectl config, get context here and you can see the local Docker desktop context.
We'll switch to this by running kubectl config use context and then enter in your local context name.
And then we can run kubectl get secrets to see all of our existing secrets.
Let's go ahead and start creating some temporary files so that we can create and transfer these secrets.
I'll run kubectl get secret stripe.
I'll put this to YAML and I'll put this to a stripe yaml file.
I'm going to go ahead and repeat the same process for the rest of the secrets.
So we'll switch to MongoDB next.
Then we'll go ahead and do the JWT secret here.
And finally we'll do the google secret in a google doc yaml.
We won't have to do the secret for our GCR json key.
And that's because in our Kubernetes engine cluster we don't need to explicitly define credentials.
We already authenticated to pull images from artifact registry because we're inside of Google Cloud
engine.
So now that we have all of these secrets, go ahead and switch back to your Google Cloud engine context
by copying the name of the existing one that we got from running get context and then paste it in to
switch back to that context.
Now we're going to run kubectl, create and create all of our secrets.
So go ahead and start with the Google doc yaml.
Next we'll do the JWT dot yaml the mongodb dot yaml.
So now that we've created the secrets in our cluster, let's go ahead and delete these secret files
so that we do not commit them and make them vulnerable now that we have our secrets created.
If we run kubectl get pods, we can see that all of our pods are in a running state.
We can even go ahead and get the logs for one of them, including the auth logs right here and see that
our application has successfully started.
So now we have our application fully running and deployed to Google Cloud Engine, which is great.
Let's go ahead and see how we can actually communicate with it by configuring some load balancers.