Learn about the Basics of ClusterIP

In this video, we will look at the most common type of Kubernetes service called ClusterIP. Now, ClusterIP is the default type. So, if you don't specify any type, this will be used. In ClusterIP, our endpoint, our service, will only be accessible from within the cluster, not from the outside world. ClusterIP is not used to route traffic from the outside world, only traffic within the cluster. So, anything happening within a cluster can be routed through ClusterIP.

Now, the service describes the different rules and configurations used to access our different pods or deployment resources. So, if we go ahead and check everything that we have within our Kubernetes by using the command kubectl get all -n example, we can see that I have redeployed the service. Now, we have ClusterIP running. We have a ClusterIP endpoint. Now, this is the endpoint, the IP address accessible within the cluster only. And then we have here the port over which it's accessible. So, now, we have the different resources that I described before.

We can go ahead and use the command “kubectl get endpoints”. I want to see the endpoints in our example namespace, and hence, I have to use the command kubectl get endpoints -n example. This command provides us with all the endpoints connected to our service. So, our node application service is connected to the following endpoints.

If we use the command kubectl get pods -o wide -n example, we can see the IP addresses for our two different pods. Now, those are the endpoints for different pods. And these are the endpoints connected with our service. So this is how the service knows which pods to connect.

The pods have endpoints and their own internal IP address. And the service can discover these endpoints. Now, the endpoints and the application are running on port 8080. So, that's why you see port 8080 in the endpoints. But the service itself is accessible through port 3000. So, how is that configured? And how does the service discover these endpoints?

Let's take a look at our service manifest. It is the manifest that's used to deploy the service. So, as you can see here, it's of type Service. Here's a name for it, node-application. I could call this anything. It doesn't have to be the same as within the deployment. So, I specify the type ClusterIP. If I do not specify this type, it will still be ClusterIP. So, I have ClusterIP defined, and then I have ports. The only port that has to be specified within the ports section is the main port.

Additionally, you have a target port. Finally, I have the type of protocol I want to use and a name. In this case, I'm using HTTP. You could also name it something else, such as the web. It's also really common to be used as a name.

Now, here's the critical part. It says within the selector section to run the node application. If you've watched the previous video, we've already seen that there's a matchLabel, and a label for a template called run: node-application. And through the selector: run: node-application, our service knows which ports to connect to independent of the endpoints.

We do not have to know the specific endpoints for our port to tell our service how to connect to those endpoints. We only have to have the selector in this case in place. Now, let's take a look at the ports. I've specified I want to access this service and the deployments connected to the service through port 3000. However, the target port, the target port that's the port that the service is supposed to target, is port 8080 because that's where my application runs. That's the container port.

Let's draw this to make this more visually pleasing. So, we have here our service, and we have here our deployments or our pod. So, let's say there's one pod, and this is our service. Now, the pod obviously might be part of a larger deployment. But, it might also not be.

Now we want to connect to it. We can assume any IP address, and then we want to connect to it over port 3000. So, if I port forward to the service, I will be localhost and then 3000 in this case. Now, this is because I specified the port to be 3000. First, however, it has to know what pod my pod runs on. And in this case, my pod here runs on the TargetPort or the containerPort. In this case, containerPort is 8080.

That's the port that my application exposes, and it is where my application gets connected. Now, how did I configure that? That's done way before and within my Dockerfile. As you can see, I'm exposing port 8080.

And also, within my application itself, I'm using port 8080 to run my Express server.

When I specify targetport: 8080, it has taken the name. So, I'm targeting port 8080. So, let's add this to the service. Now, this is the same as my containerPort in this case. So, the targetPort is targeting the containerPort here. So, what I do is I port-forward to my localhost.

My localhost will connect to my service port, in this case, 3000. So the localhost will be 3000. But the service knows that this is not the port where my application runs because I have a different target port, 8080, and it's forwarding it to my containerPort. And this is how I can connect through ClusterIP, in this case locally, to my application because the service knows those endpoints.