What are Kubernetes Services? How do They Work?

Photo of author

By admin

In Kubernetes, a service is a way to define a set of pods that run the application. Each of these pods can have an IP address and be related to the network. Kubernetes makes it easy to use a service discovery without changing pod configurations. Kubernetes, however, makes sure each set of pods has its own IP address and DNS name, and they are load-balanced among one another.
The deployed set of pods in the Kubernetes cluster works in the same way, but these pods are ephemeral. That’s why a Kubernetes service enables a set of pods in the cluster, and it will assign new tasks to each pod so that they can get on with their job before they expire. Therefore, Kubernetes services are important for running individual pods on clusters by giving them a unique IP address.
We will discover more about Kubernetes services, including their advantages, the components they comprise, etc., in this article.

What is the Purpose of Kubernetes Services?

Pods are built and destroyed frequently in Kubernetes to keep track of the condition of your Kubernetes cluster. Thus, these pods are not permanent, and they can be destroyed, and to destroy pods, you can create a deployment. A deployment will generate and terminate pods actively. The work ethics of each pod in deployment can sometimes be different despite having a unique IP address. A group of pods running the same application this minute may differ from another group running the same application in a minute from now. But this work ethic can cause problems.

Assume that the first set of pods is a backend and the second set is a frontend. As a result, backend pods now offer some functionalities to frontend pods in your cluster. Your frontend pods, however, must know the IP addresses of the backend pods in order to maintain a record of the functionalities and overall tasks. Kubernetes services can help frontend pods to manage workloads in a Kubernetes cluster by keeping track of the backend fronts. Deploying a simple solution wouldn’t be enough.

The fundamental difference between Deployment and Kubernetes service is that deployment launches the pods with a containerized application. And deployment also ensures that the pod replicas are running on the cluster in the proper number. But Kubernetes service assigns an interface to the pods that allows the pods to get network access from the cluster and/or the outside services. There is a vital service resource that allows pods to work properly. Let’s see how the service resources work.

What is Kubernetes Service Resource?

Kubernetes service resource is a reflection that defines a group of pods and their policies that is important to follow while accessing them. The policies for the pods are also known as microservices in some cases. A selector determines which group of pods will be used in service, but there can be different techniques to establish service endpoints, too, and in that case, the service will work without a selector.
In the Kubernetes cluster, for instance, there is a stateless image-processing backend that has three replicas and these replicas are subject to change. In contrast, frontends do not need to know what backends they are using. Consequently, the frontend pods are decoupled from the backend pods by Kubernetes’ decoupling service, and the backend pods are not tracked.

Sometimes developers need to use Kubernetes APIs for service discovery, and for that, you will require endpoints. The endpoints are always changeable, and they are updated each time the group of pods in the Kubernetes service changes. Kubernetes come with some vital components that you should consider.

How Many Components are there in Kubernetes Services?

Kubernetes service connects the pods to IP addresses so that the services can offer routing and discovery between the group of pods. Even when the different sets of pods are running on the different deployments in the cluster, services will connect the application to both sets of pods. Often, services use labels and selectors that help them connect the pods with other containerized applications. Therefore, Kubernetes services need the vital components that get the job done of connecting two sets of pods with each other. Here are the vital elements of a Kubernetes service:

  • The label or selector discovers the group of pods
  • Assigned port numbers to each pod group
  • ClusterIP IP address to each pod group
  • The definitions of ports
  • Mapping of incoming ports to their target ports

We have already mentioned previously that Kubernetes can define a service without the pod selector. It can target one service to another service from a different cluster or namespace. There are four main types of Kubernetes services.

  • ClusterIP reveals the service that you may only access from the Kubernetes cluster
  • Node port reveals a service through a static port on the IPs of every node in the cluster
  • And LoadBalancer exposes a service through the load balancer of the cloud provider
  • ExternalName will map out a service to a preset externalName range by giving away a value for the CNAME record.

Let’s get to know about the Kubernetes services a little more.

Definitions of Each Kubernetes Services-

To help you understand how Kubernetes works on clusters, we have listed each of the four main services here.

1. The ClusterIP Service

The ClusterIP service is a default Kubernetes service that helps an IP address to access a service on the cluster, and the IP can only access the service from the cluster.

2. The Headless Service

Headless services expose only a single IP address and specify “none” as the clusterIP. Services that don’t use load balancing can only create headless services. And these headless services might need selectors to be defined, in which scenario the endpoints are generated in the Kubernetes API that can tell the DNS to give back the IPs that connect the pods that are exposing the service.
Headless services don’t have selectors, so they aren’t able to create endpoint records. As a result, the DNS is configured with an endpoint record that has the same name as the service. The DNS can’t configure both CNAME records and endpoint records simultaneously.

3. Kubernetes Nodeport Service

Node ports refer to open ports on cluster nodes. Kubernetes routes the traffic to a service that a node port receives no matter if the service is running on that node or not. Node port is used for the development of Kubernetes applications and falls in the high category such as load balancers.

4. Kubernetes ExternalName Service

ExternalName services are not so different from other services in Kubernetes. However, the ExternalName service is not accessed through the cluster IP address, but it gives away a CNAME record of value defined by the external name while creating the Kubernetes service.

5. Kubernetes Load Balancer

A Loadbalancer service is similar to the clusterIP service that extends the service to an external load balancer. And the load balancer is particular to the cloud providers such as AWS or Azure that are running in Kubernetes clusters. Therefore, when you are creating a Loadbalancer service provider, it will equal the cluster IP service. Kubernetes automatically creates the load balancer and firewall rules whenever required. Kubernetes also matches the service with an external IP address which is assigned by the public cloud provider.

When you are using a Kubernetes service, you need specific commands that will help you define the value.

How to Define a Kubernetes Service?

A Kubernetes service is known as a REST object which is like a pod, and you can POST the definition of the service to the API server so that you can generate a new example. The title of the service object needed to be a valid RFC 1035 label name. Like, if you have a group of pods that works on the TCP port 9376 and comes with an app=MyApp label, then the service definition will be:

apiVersion: v1

kind: Service

metadata:

name: my-service

spec:

selector:

app: MyApp

ports:

– protocol: TCP

port: 80

targetPort: 9376

In this definition, there is a unique service object labelled as “my-service”, and it targets the TCP port 9376 on any pod that comes with an app=MyApp label. Kubernetes will assign this service with an IP that will be used by service proxies. Whenever your controller works with a selector, it will search for PODs that are similar to the selector. Afterwards, the selector will POST the latest information to an endpoint object called “my-service”.

Please note that service in Kubernetes can set any port as a target port, and by default, the target port has the equivalent value as the port field. The port outlines in pods have different names, and these names can be used as a reference in the targetPort characteristic of the service.

If you want to access a Kubernetes service, you can do that in two ways. You can use the DNS method or ENV variable.
. The DNS method is for discovering services, and if you want to use the DNS method to access services, you need to install DNS on the cluster. The DNS server will monitor the API, and after the creation of a new server, the server will be up for managing pods in application clusters.
And the ENV variable depends on the kubelet environment variable for the services that are running in every node and every pod.

Services mostly separate access to pods, but services can also separate access to other backends.

Services without Selectors

There are many cases where you can define a service without using a selector:

  • You need an outside database cluster in developing an application, but you can apply your existing private databases in your testing environment.
  • If you need to connect a service to another service from a separate namespace or cluster.
  • When you are shifting a task to Kubernetes, you can work simply a part of backends in Kubernetes in that case.

If these cases happen, you can establish service with no help from a selector like this:

apiVersion: v1

kind: Service

metadata:

name: my-service

spec:

ports:

– protocol: TCP

port: 80

targetPort: 9376

Here the service didn’t have any selector, and the endpoint object was not generated on its own. But you can outline the service on your own and send it to the network address and port. Send it where the service is running. For that, you will have to add an endpoint object by your hand:

apiVersion: v1

kind: Endpoints

metadata:

name: my-service

subsets:

– addresses:

– ip: 192.0.2.42

ports:

– port: 9376

The name of this endpoint object should be a legitimate DNS subdomain name. Even when you are entering a service outside a selector, it should work likewise as when you owned a selector.

Conclusion

Kube-proxy handles iptables to define the IP addresses in services, and these IP addresses are redirected to another endpoint when required. Pod ip addresses, however, are routed to a specific destination. But in kube-proxy, there are three proxy nodes that include userspace, iptables and IPVS that work differently than each other on a slight note. Pod IP addresses transfer traffic to an appropriate endpoint when the client connects to the VIP.

There are many more Kubernetes services than we’ll ever be able to cover in one article. If you wish to learn more about Kubernetes and its services, please review our other guides. Feel free to ask us any questions in the comment box below.

Leave a Comment