To create this service,
we can again use the command line here.
Now, I will keep this dashboard process up and running,
and therefore create a new terminal window.
And then here we can, again use Kube Control
to create a service.
Now, if we run Kube Control Create,
we actually see that we could create a service here.
And whilst this would work,
it's actually not what I'll do here.
Instead, there is an even more convenient command
for exposing the pod created by a deployment.
And that's the Kube Control Expose command.
This command does what the name implies.
It exposes a pod created by a deployment
by creating such a service.
Now we need to let Kubernetes know
that we wanna expose a deployment,
and then we specify the name of that deployment.
And then we need to add two important options.
The first option is the port, which we wanna expose.
And in my case, that will be Port 8080
because that is what the container exposes,
because that is what the containerized app listens on.
So here, I'll expose Port 8080, like this,
and you need to assign the value with such an equal sign.
Now, that's one thing.
The other important option is the type of service
or exposing which you wanna create here.
And there are different built-in types.
One possible type you could specify here
would be cluster IP.
This is actually the default type which basically means
it will only be reachable from inside the cluster.
Still, we will then at least get an address
which doesn't change, but it's not what we need here.
Instead, we also have NodePort,
which actually means this deployment should be exposed
with help off the IP address of the worker node
on which it's running.
Distant actually would be accessible from outside.
But even better than that, there's the type LoadBalancer.
Now LoadBalancer utilizes a LoadBalancer
which has to exist in the infrastructure
on which our cluster runs.
And then this LoadBalancer will actually generate
a unique address for this service.
And it will not just do that, but as the name implies,
it will also evenly distribute incoming traffic
across all pods, which are part of this service.
Obviously, this doesn't matter to us here
because we only have one pod at the moment.
But if we would scale this,
and we would run multiple instances of this pod,
it would start to matter.
Now LoadBalancer, this type here
is only available if your cluster and the infrastructure
on which the cluster runs supports it.
AWS does, for example, and minikube thankfully also does it
which means that we can use this type here.
So if we now hit Enter, this service was created.
And we can check that it was created
by running Kube Control Get Services.
And here, you should actually see Kube Services here.
The first one, the bottom one, Kubernetes,
this actually has the type cluster IP,
and it's a default service which was created automatically,
not by us.
But here we see the service for the first app deployment.
You see the type and the cluster internal IP
which won't help us.
Now, if this would be deployed on a cloud provider,
we would actually see an external IP here,
but for minikube,
this will always stay in the pending status.
Nonetheless, minikube balls has got us covered.
The reason why we don't see the external IP here
is that of course, we must not forget that minikube
is still a virtual machine running on our local machine.
So it doesn't have too many IPs available
since well, these IPs would lead to websites out there.
So therefore, we don't have an external IP here,
but minikube has a command,
which will give us access to the service
by basically mapping a special port to an IP
which we can reach from our local machine,
and which identifies this virtual machine
running on our local machine.
And that command is the minikube service command,
where we then need to specify our deployment
and our service name therefore, in this case, first app.
Obviously, if you created this service on a Cloud provider,
which supports a LoadBalancer,
you should find an external address here
and you don't need this command.
This command wouldn't even work then
because it's minikube specific.
So if we now hit Enter, we get this table with an address
which we can use to view our application.
And normally, it should also automatically open that
in the browser for you.
So if everything worked, you can use this address
to view your running Node.js application
running in that container, which is running in that pod,
which was created by Kubernetes
based on the deployment we created
and sent to the Kubernetes cluster.
And because of this Kubernetes service which we created,
we can view it as on this address here.
And these are a couple of crucial steps.
Now, we will later switch away
from this imperative approach, which we're using here,
but nonetheless, these are huge steps forward.
And with the pod, the deployment,
and the service object type,
we learned about some of the most important types
which we'll use all the time when working with Kubernetes.
So now let's see what else we can do with Kubernetes.