Now, that's all something you learned
and for the moment I'm going to stick
at concepts you learned about because as a next step,
we will add a service, why?
Because we wanna reach that users API
even though authentic tasks API are not deployed yet
but we wanna reach the users API from the outside world,
for example with the postman tool,
but that could also be a web application which is connected.
We wanna be able to send such a request
and for that we need a service.
Because services just to really make that clear again,
allow us to do two main things.
They give us a stable address
which does not change all the time.
Pods do have IP addresses by default,
but these IP addresses change if they are removed
or moved to different nodes.
But besides the stable IP addresses
services also can be configured
to allow outside world access
which by default also is not possible.
So, a stable IP addresses and outside world access,
these are two strong arguments
and therefore I will add a users-service.yaml file here
and in there define my service.
The API version is we won the kind of resource here
is service and we can, of course also add metadata
and give this service a name
which could be users-service.
Next, we set up the spec, the specification to configuration
off that service,
and here we wanna do three important things.
We wanna select which parts should be part
of that service and besides that we want to set up
which ports should be exposed
and which type of service it should be.
Now, let's start with selecting ports
and here I wanna select all the pods created
by the users deployment.
Hence of course, here I can select my pots
by this app label with avail of users.
So, here below selector in a service,
we have app:users.
We don't have match labels here
because as I mentioned earlier in the course
this service specifications simply
is a bit simpler than the deployment specification.
When it comes to the selector deployments
support them more powerful selections
syntax services stoned
they're redirectly have labeled select doors.
So hence here I use a label name
and then a value for that label.
So now, we know which pods should be part of this service
as a next step, we need to set the type of this service.
And there I mentioned, we have three main types.
We have cluster IP, which is the default actually.
So if you don't specify a type cluster IP
will be used as a type and with cluster IP,
the service is an internal service
which is only reachable from inside the cluster,
not from the outside world,
hence it's not what we need here, of course.
We also could set it to node port
with node port we actually have a service
which is reachable from the outside world
but it's actually using the nodes IP address
and that's therefore still isn't great necessarily
if we have multiple nodes and ports,
move between nodes because replica's are created
and launched on a different node for example,
then we have different IP addresses here,
so this is not what we want.
Therefore, the most useful type here is load balancer.
This creates an outside available IP address
and it also automatically distributes incoming requests
across all ports no matter on which node they run,
and IP address is also independent
from the node on which a pod runs
because a brand new IP address is created, so to say.
So load balancer is a type you'll use a lot here.
Now, one thing I wanna note here real quick though,
is that with cluster IP,
you would also have some load balancing kubernetes
will then automatically distribute incoming requests
across the different parts that belong to the service,
but you never use a dedicated load balancing service
by a cloud provider, for example, nor
and that's the key thing here.
Do you have an outside world facing IP address?
So, cluster IP can be very useful internally in a cluster
because then you can have internal communication
and still have some load balancing
but load balancer also gives you
that outside world facing view.
I just wanted to mention this because
since this is named load balancer
it sounds like it's the only type of service,
which does distribute requests across different parts
but that will actually not be the case.
But it's the only type which does this distribution
even across different notes
and gives you that outside world IP address.
So with that, we set up the type.
Now, we can set up the ports for that service,
with which we define which ports should be opened up
and therefore reachable.
And to which ports you wanna redirect inside of your ports.
So, here we can list multiple ports
by adding multiple dashes
and every port should have a protocol
which by default and typically is TCP.
And then you have a port and a target port
and the port
is simply outside facing port.
So, the port on this service IP address
to which you can send the request
and the target port is to port insight off the pod
inside of the container,
to which the request will be forwarded.
And it is quite common that you use the same port here
but you can also use different ports.
Now, in my case this user's service actually listens
on port 8080
and that is the port exposed by the docker file therefore.
So I will use this here
obviously as a target port,
but also as a port here
for incoming requests though, as I just explained
you could use a different port here.
For the target port you need to use 8080 of course,
because that's the container internal port
on which it expects incoming requests.
And with that, the services created.
Now, we can of course apply that service
with Kube + Ctrl applied -f users-service.yaml,
and that will create this service.
And now, with a created here
in the mini cube world, in order to get access to it
we need to run minikube service and then our service name
which in my case is users service.
Of course, you won't need to do that if you deploy
to some Cloud provider
there you will automatically get an IP address
for the load balancer
which is created on the Cloud provider,
since we're in the minikube development setup though,
that will not happen and instead minikube
gives us a dynamically generated IP address
by running minikube service,
and then the service name.
It should open up into browser
though we don't need it there
but make sure you grab this URL here,
and then let's give this a try.
You can use this instead of localized ADHT
use the URL you just got
and try sending a post log-in request there
with a body's set to raw Json,
and then some data between curly braces,
like an email of any value of your choice
and a password of any value of your choice.
Make sure you wrap your keys
and your values between double quotes
and that you have a colon between the key value pairs,
and a comma after the first key value pair.
Then if you click send, you should get back a token.
And if you, for example omits D password
and send, you should get back an error.
If you admit it to comma,
you always get back a better error.
And if I add the password again, that all works.
Now, if we try signing up by replacing log in with sign up,
we get back user created when we send that email
and a password.
So, that is working
and that proves that our application
or our first container here is up and running.
Of course, they'll that was nothing new except
for the extra information about the type
and the load balancing I guess.
But it is crucial to understand
that services are a key object
a key resource when we are talking
about networking on kubernetes and about handling requests.
Now however, let's move on to the next step
and let's make sure
that we can enable this pod internal communication
between the users API,
the user of this container
and the Auth API, this auth container therefore.