Now, after the last lecture
in the end we now got this version
of our application implemented with Kubernetes.
I mean, the tasks API is missing actually
but for the Users and Auth API,
we got those app and running in the same Pod
they are able to talk to each other
and we are able to send the request
to the Users API.
Now, however, of course
I also want to deploy the Tasks API
in a separate port
and make sure that we can send requests there too.
And now in addition,
actually the Auth API
should not be public-facing at all.
And it kind of already is
because we're not exposing its port
on the service I guess,
but I also wanna make sure
and that's the thing which is missing at the moment
that the Tasks API is able
to talk to the Auth API
because it also needs to do that in its code.
But, and that's the key thing
I still wanna have to Tasks API run in a separate port.
And therefore the goal
in the end is to create a brand new Pod
and also a new deployment for the Users API.
So that in the end we have three different kinds
of ports and therefore three different deployments.
And we ensure that these ports can communicate
with each other as shown on this picture
which means we'll also need multiple services.
And for example, those service
which manages the port for the Auth API,
should not be public facing at all.
It should be cluster-internal
but it should be reachable
by both the Users API.
So the Pod containing data container
and the Tasks API.
So that's where we were going to move next.
We're going to have a look
at port to Pod communication inside of a cluster,
and we will use multiple services for that.
So to move on
and to make sure that we implement our application
as shown on the last slide.
We obviously need to make a couple of changes.
For example,
we need a new deployment
for the Auth API,
so that the Auth and the user container
no longer run in the same port.
And that's actually what I'm going to start with.
So we should add a new Auth deployment on Yaml file here.
And we can basically copy
the users deployment configuration I guess,
but of course we'll tweak it a little bit.
For the Auth deployment
I will change the name of course,
to Auth deployment change my selector here
to app Auth and my label here
for the port to app Auth
remove the users container from that list
and only leave the Auth container here
so that our deployment looks like this.
And then also go
to the user's deployment Yaml file
and there of course removed the auth container
and leave it like this.
So with that
we now have two deployments
and therefore two different kinds of ports
which will be created.
So the Auth and the user container,
will no longer run in the same port.
Now that of course has a couple of key implications
for example, since the Auth deployment
creates a brand new port
this new Pod will not be reachable
through a service,
instead only inside Auth the cluster
but even there, as I mentioned earlier
because we're not having a service
for this Auth deployment yet
the IP address of that Pod could change all the time.
If we scale it up or if it fails
and it needs to be recreated for whatever reason
and that's not ideal,
hence I'll also add Auth service here
and copy the user service configuration
into the Auth service Yaml file.
But of course, name it Auth service
and select by the app Auth label,
which is the label we gave our new Pod here
in the Auth deployment Yaml file,
and then I also want to use a different type
and different ports.
Now, when it comes to the ports,
we have to look into the Auth API setup
and we see that there it's port 80
which has exposed,
hence in the Auth service
I will use port 80 as an outside and inside port.
But the type is always important with load balancer,
we would expose the Auth API
to the public,
and that's clearly not the goal here.
It should not be public-facing,
it should not be reachable from outset to cluster.
Hence here will not use type load balancer
for the Auth service,
but cluster IP.
This as I also mentioned briefly earlier
we'll do some automatic load balancing done by Kubernetes
but we're not getting exposed
to the outside world.
This will not be reachable from outside.
And that's exactly what we want here
only from inside our cluster
this service can be reached
and that of course then brings up
another important question.
How can we reach it?
What should be our Auth address?
It was a local host for requests sent
to the Abra container when the container
was in the same port as the users container.
But that of course is not the case anymore
so what should be the new address here?