Let's start with a command.
Let's apply our two yaml files
because that is the big idea behind Kubernetes.
That we just need to create a cluster
which of course can involve a couple of steps as you saw,
but it wasn't too difficult,
I would argue.
But then once we got that cluster,
we can use the configuration
which we used before with MiniKube
and take it as it is and apply it to that cluster.
We don't need to add any AWS-specific instructions here
for this deployment.
We don't need to do anything else.
We just wanna apply these yaml files
and then hopefully have our running application
up and running on AWS.
So let's do that here.
For this, I will cd into the Kubernetes folder,
which holds my yaml files,
and then run kube ctrl,
which is connected to the AWS cluster
as you learned before,
apply dash f=auth.yaml and then again, f=users.yaml.
Applying these two yaml files to our AWS cluster.
And if we hit enter here, this should finish successfully
and create these deployments and services.
And therefore we can run get deployments
to see our deployments here.
Of course, by the way, make sure you pushed your images.
If you didn't push your images as instructed earlier,
this will not work,
but if you pushed your images,
you will eventually see that both deployments
are up and running.
We can also get our pods, of course, and see these pods.
And we can also get our services.
And if we do that, we'll also notice something interesting
about the load balancer service.
With MiniKube, the external IP field was always pending
and we had to run MiniKube service
to really expose that load balancer service
to the outside world.
Well, that was something MiniKube specific
because it was that local virtual machine dummy set up.
With AWS, it's different.
We get a URL here,
which we can simply use to send requests to.
Now, this is our users service and we can,
for example, use this in Postman.
Simply open Postman and send a new post request to that URL
which you got here from get services,
slash sign up.
And then go to Body, Raw and select CHSN,
add curly braces, opening and closing
and add an email field between double quotes,
maybe with test@test.com
and a password field between double quotes
with a value of testers.
It should be at least seven characters long.
Then click Send.
And you should get back a user-created response.
If you now try to create that same user again,
you'll get an error
because it already exists.
If you omit the @ in the email address,
you get an error that the email or password is invalid.
And if you create another user with a new email address
which wasn't used before, it'll work again.
We can also create another post request
to that same URL slash login
and add a body which is Raw, CHSN
and then also contains an email and a password,
maybe the email and password we used before.
And if we send this post request,
we should get back a response with a token.
If we send it with an invalid password,
we get back an error.
And this all proves that our application is running
because we are sending these requests
to our AWS cluster here.
And that is our application deployed with Kubernetes.
And you can hopefully see
the big advantage of Kubernetes here.
The same configuration,
which we worked with over the last sections
and which would work MiniKube,
works just like this with AWS.
I also wanna show you that in the AWS console,
if you go to the EC2 console again,
you will see that on load balancers,
we now got one load balancer
which was created automatically by AWS
because we deployed this load balancer service.
And here you got this URL,
which you also see if you run get services, this one.
And that's the great thing about Kubernetes
especially when using it together with
managed services like EKS.
It was super simple to deploy this basic application
and we didn't have to learn many new things.
Yes, we had a couple of setup steps
to bring that cluster to life,
but I would argue that was not too difficult.
And then we just apply what we learned
over the last sections
and we have our successfully running Kubernetes application.
And we can now manage it
just as you learned it over the last sections.
If you make a change to one of these yaml files,
you can simply kubectrl apply it
and your deployment will be updated.
For example, if I go to my user's yaml file
and I change my replicas to free there,
I can apply the updated users.yaml file.
And if I do that and I run kubectrl get pods thereafter,
you now see we got more pods up and running
and there are new pods getting started now.
As a side note, pods are not nodes, as you learned.
Pods are to things which contain containers
which run on your nodes.
And they will be distributed by Kubernetes
across the available nodes
of which, in our case we have two.
So pods are distributed across the nodes.
Nodes are not started with replicas.
Nodes and the number of nodes are configured
in your cluster here
in the case of EKS with these node groups.
And that's our deployed Kubernetes service.
Please also note that this cluster internal communication
with that automatically generated domain name
works just fine.
We didn't have to change anything here.
I'm just using the service name dot default
because we have that default namespace here
in the Kubernetes cluster created by EKS as well.
You can run kubectrl get namespaces
to see the available namespaces.
And here, you see that default namespace,
which we are utilizing here.
So this internal communication
with this service of type ClusterIP
and this automatically generated domain name,
again, just works.
It all just works as it did with MiniKube.
And it should
because that is the core philosophy behind Kubernetes
in the end,
that we have a standardized configuration
which we can apply to any Kubernetes cluster
to bring our Kubernetes-managed application to live there.