Kubernetes services

I’m going to present ClusterIP services. ClusterIP is the default type of Kubernetes service. If we do not specify any type in the definition for a document file, then Kubernetes assumes that we are going to use ClusterIP.

The question arises of how the services will attach to the pods, when to attach the pods, and where to attach the pods. For example, you can see in the presentation slide on the left-hand side, I have a pod here and it has two containers. We have exposed two pods 3000 and 9000. I have to create a service. How will I be able to add this pod or the endpoint to my service? Kubernetes gives us this opportunity with the selector and labels we have. As you can see on the right side of the slide, in services, we use the selector to select the pods using the labels. The other point is the pods that we are exposing.

Let’s suppose for the sake of dialogue when we say that we have a microservice, which is exposed to the browser, and the client is going to access that service. I’m using here Ingress, but we will discuss this ingress in some other demo. Today, we are going to discuss the internal services, and how the traffic moves from ClusterIP service to the pods. We can say for the sake of dialogue that the traffic has reached the ClusterIP on pod 3200 on a specific IP 10 which is written 10.128.8.64. Our purpose is to look at how this service will forward the traffic to the pods.

As I told you in previous slides services use two mechanisms to select the pods and to forward the traffic. If we say that numerically the service will select the pods depending on the labels. For example, I am showing you that I have a service and I am using a selector, I’m using labels, and microservice. You can see that in the example that pods also have labels attached with App micro with key values on microservice one. The service will select the pods as an endpoint registered and forward traffic on the target pods which I have defined. In the definition files, you can see that the target pod is 3000. The service will select the pods on the basis of the selectors and forward traffic to the target pod.

We do not use node pod in production or development because node pod exposes the node directly to the client and we do not want this so we use a LoadBalancer. The LoadBalancer adds an extra layer. Client traffic will directly come on the LoadBalancer and then forward distant traffic to the services. When we are creating a LoadBalancer, the node pod and the ClusterIP will dynamically create it by themselves.

I have taken a super simple application hello world and this is my deployment. You can see that I have just added one replica for the sake of this demo presentation. I have added this label to the pods. My service will use selectors and match the labels with these labels and will add the port or replicas and its registration. This is my simple definition of deployment and this is the service that I have created. I am using a LoadBalancer and you can see that I am using a selector over here. On the basis of these labels, the replicas or the ports will be added with this service and I am assigning port 80 to the LoadBalancer and this port with the target port with the containers, so two ports. I have already run the service and similar files. You can see that I have created my pods and my pod is already running. This is the service I get. This is the external IP on which the client will send its traffic. You can see that dynamically, it has created this port, which is the LoadBalancer, and NodePort and this is the traffic I have access to. You can see from here as well that this is the page the client will send us traffic.