Open In App

Kubernetes – Service

Last Updated : 19 Jul, 2023
Improve
Improve
Like Article
Like
Save
Share
Report

Pre-requisite: Kubernetes

In Kubernetes, each pod is assigned its own IP address but the pods are ephemeral that is they can be destroyed easily and when a new pod is created in place of them a new IP address is assigned to them. Here the role of services comes into the picture. A service is like a permanent IP address assigned to a pod. A service IP address is stable. So instead of sending a request to a pod, the client makes a request to a service, and the service forward that request to the desired pod. Services also help in load-balancing.

Services in Kubernetes

Service in kubernetes will expose the application which is running in the pods to the internet. Each service will have there own set of endpoints from where they can be accessed from the internet.

For example, if you deployed a web application in the Kubernetes cluster with five replicas then you can access the five replicas with a single URL. The traffic will be routed to all the pods based on their incoming traffic. You can use ingress control to control the incoming traffic.

Defining a Service

In the kubernetes cluster, there are no.of objects which are having there own use cases and individual advantages. Same way service is part of objects which are present in kubernetes. To create an object or operate an object you can use the kubectl tool.

Example

apiVersion: v1
kind: Service
metadata:
name: deployment-service
spec:
selector:
Tomcat: deploymentapp
ports:
- protocol: TCP
port: 80
targetPort: 8080

In the above we are exposing the Tomcat application deployed in the kubernetes cluster with labels of Tomcat: deployment app port: 80 is the port exposed internally in the cluster and port 8080 is the port of the Tomcat application.

Port Definitions

In the kubernetes service, there is one section called targetPort in the nodePort service instead of using the port number you can directly use the name of the pods.

Example

kind: Pod
metadata:
name: tomcat
labels:
deployemnt: deployemnet-java
spec:
containers:
- name: tomcat
image: tomact:latest
ports:
- containerPort: 8080
name: http-deplyment-port

---
apiVersion: v1
kind: Service
metadata:
name:tomcat-service
spec:
selector:
deployemnt: deployemnet-java
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort:http-deplyment-port

For example, we can see that instead of using the “targetPortnumber” you can use the name of the container as mentioned below. The target port is the port number that the service or pod is forwarding requests to.

Services Without Selectors

This type of service will be exposed to all the pods in the kubernetes cluster. If the service is having selectors then that service will be exposed to only certain pods in the kubernetes cluster. We can use this special case of pods for different situations as the following:

Example

apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 8080

You can map the service to the required object by using the network address and port with the help of the Endpoint slice object manually.

EndpointSlices

EndpontSlices are the object available in the kubernetes cluster from Kubernetes v1.21 [stable]. Endpontslice main function is to break endpoints into smaller manageable segments. The limit of pods that can find in each endpoint slice was 100 pods. The new endpoint slice will be created only when the Endpointslice is filled up with 100 endpoints.

Custom EndpointSlices

The custom name can be given to endpoint slices when you create a new endpoint slice. By using the following EndpointSlices you can create custom Endpoint Slices.

Example

apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
name: my-custom-endpointslice
spec:
endpoints:
- addresses:
- 10.1.2.3
ports:
- name: http
protocol: TCP
port: 80

Application Protocol

The application protocol is the field where you can mention the type of protocol that a specific service is listening to. The protocol can be anything that depends upon our requirements here are the some of application protocols.

  1. TCP
  2. UDP
  3. HTTP
  4. HTTPS

Mostly the service will listen to the TCP protocol. If the service is TCP protocol the service will be load balancing service and if it is HTTP protocol the service type will be ingress.

Multi-Port Services

Multi-port Service allows you to expose different protocols to the same service or different applications on the same service. You can configure multiple ports using the object in kubernetes called to service.

Example

apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
ports:
- name: http
port: 8080
protocol: TCP
- name: https
port: 43
protocol: TCP

By using the yaml which is mentioned above you can expose multiple ports but the IP address and DNS name will be the only one with that you can use various services.

Load Balancers With Mixed Protocol Types

The service type LoadBalancer can have multiple ports but it should have only one protocol and which is supported by the cloud provider. You can have a kubernetes service that exposes protocols like TCP and UDP ports, which is called a mixed protocol service.

Choosing Your Own IP Address

Kubernetes will assign the IP address from within the service-cluster-ip-range CIDR range or you can choose your own customized IP address. You can reuse the DNS or IP address already in the kubernetes cluster. For reusing, you need to request while creating the service itself.

Example

apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
clusterIP: 10.10.10.10
ports:
- name: http
port: 8080
protocol: TC

Once you applied the above specification after that you can access the Tomcat application from the internet by using the IP address you mentioned in the yaml file our case it will be 10.10.10.10. You can also try the above yaml file to create your own customized IP address.

Choosing Your Own Port

While exposing the pod to the internet we will use service objects in the Kubernetes cluster. We will use mainly the nodPort service in Kubernetes while exposing the pod in Kubernetes. You can mention your own port in the yaml in the section which is called nodePort: <PortNumber>. On this port, the users can access the service from the internet and the service will listen on the port which you have mentioned.

Example

apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
type: NodePort
selector:
app: Webapp
ports:
- port: 80
targetPort: 8080
# Control Plane in kubernetes will allocates an default
IPaddress which is in the range of various between 30000-32767.
nodePort: 300023
Service type

There are four major types of services which are having their advantages in their perspective as explained following.

  1. ClusterIP
  2. NodePort
  3. LoadBalancer
  4. Headless

ClusterIP

When we create a service we will get one Virtual IP (Cluster IP) it will get registered to the DNS(kube-DNS). Using this Other Pds can find and talk to the pods of this service using the service name. Service is just a logical concept, the real work is being done by the “kube-proxy” pod that is running on each node. It redirects requests from Cluster IP(Virtual IP Address) to Pod IP.

Example

apiVersion: v1
kind: Service
metadata:
name: nginxsvc
spec:
selector:
app: nginx
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

1. ClusterIP Service (Internal Service)

In this service type when a Client makes a request then that request is first forwarded to the ingress controller and the ingress controller forwards it to the cluster service and then this service forwards it to the appropriate pod. When there are many replicas of a pod then these replicas serve as the endpoints of service and here service also works as a load balancer and forwards requests to the pod replica having the least load. This service is an Internal service because external traffic cannot directly access the cluster service. It can only be accessed via the Ingress Controller.

Example: Let us make a ClusterIP service for the Nginx Web Server using the following configuration:

yaml file

Also, the ClusterIP service is the default service if we do not specify the service type in the config file as in the example above.

Now we can create this service by applying the following command:

$ kubectl apply -f [file-name]

kubectl apply

2. NodePort Service (External Service)

In NodePort Service, external service has access to a fixed port on each Worker Node. In this case, instead of ingress, the browser request will directly come to the node at the port defined in the service config file and be exposed at the node port. The node port can range between 30000 to 32767. 

Example: 

yaml file for node port

Now we can create this service by applying the following command

$ kubectl apply -f [file-name]

3. LoadBalancer

Exposes the service externally using a cloud provider’s load balancer. NodePort and ClusterIP services, to which the external load balancer will route, are automatically created. If you are using a custom Kubernetes Cluster (using minikube, kubeadm, or the like). In this case, there is no LoadBalancer integrated (unlike AWS EKS or Google Cloud, KOPS, and AKS). With this default setup, you can only use NodePort.

Example

apiVersion: v1
kind: Service
metadata:
name: javawebappsvc
spec:
ports:
- port: 80
targetPort: 8080
selector:
app: javawebapp
type: LoadBalancer

4. Headless Service

Deployments are usually used for stateless applications. However, you can save the state of deployment by attaching a Persistent Volume to it and make it stateful, but all the pods of deployment will be sharing the same Volume, and data across all of them will be the same. SatefulSet is a Kubernetes resource used to manage stateful applications. It manages the deployment and scaling of a set of Pods and provides a guarantee about the ordering and uniqueness of these Pods.

Example

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
clusterIP: None
selector:
app: my-app
ports:
- name: http
port: 80
targetPort: 8080

When we are using the type of service you will use, you need to give the name “clusterIP: None”.

Discovering services

The kubernetes service can be discovered by using two methods as follows.

  1. DNS discovery
  2. Environmental Variables

DNS discovery

When you first create a service kubernetes will automatically create DNS records for the service. The application finds the service in kubernets with the help of DNS discovery which will point to the IP address of the service.

All the cluster services will be stored in the cluster-wide domain which is svc. cluster. local. The format of the DNS record is as follows.

<service-name>.<namespace>.svc.cluster.local

DNS in Kubernetes assigns the domain and sub-domain name to the pods and for service. By which other objects or resources in the Kubernetes cluster can discover services by the domain names.

Environmental Variables

Environmental variables will be helpful for the DNS discovery to discover the service in the Kubernetes cluster. You need to mention the environmental variables in the service yaml file as follows then only DNS discovery will discover the service which is available in the Kubernetes cluster;

apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
selector:
app: my-app
ports:
- name: http
port: 8080
protocol: TCP
env:
- name: SERVICE_IP
value: "127.0.0.1"
- name: SERVICE_PORT
value: "80"

FAQs On Kubernetes

1. What Is Kubernetes Service discovery spring boot?

Spring-cloud-starter-kubernetes it is a dependency in kubernetes cluster

2. What is a Kubernetes service vs a pod?

Kubernets service allows virtuals routes to the pods. Pods are smallest execution unit in kubernetes cluster.

3. How do I list services in Kubernetes?

kubectl get services is the command used to list all the services in the kubernets cluster.



Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads