Services are the abstraction layer of making an application accessible as a network service on the set of pods. It offers a single DNS name and IP address by which the pods can be accessed. It is added in front of each Pod to provide a static IP address. This article describes the need for a service layer and the types of services in Kubernetes. Refer to this article from start to end if you are new to this concept and you don’t know how to create a Kubernetes service.
What Are Kubernetes Services?
A service in Kubernetes is an abstraction that defines a collection of logical pods where an active component or application is housed and contains an access policy. Due to the fleeting nature of individual pods, Kubernetes only ensures the availability of the specified pods and replicas, not their liveliness. This suggests that other pods that need to interact with this application or component didn’t rely on the IP addresses of their underlying pods.
A service is assigned with a simulated IP address as well (in Kubernetes, it is thus referred to as a clusterIP) and it survives until it is expressly killed. Queries to the service are forwarded to the appropriate pods, making it a reliable interface for application or module communication. Requests for Kubernetes-native applications can also be made thru an API in the apiserver for Kubernetes which constantly exposes and maintains the real pod endpoints.
When Do We Need the Kubernetes Services?
Here are the reasons why we need Kubernetes services:
Stable IP Address
Have a static IP address that stays even if the pod dies. In front of each pod, we call the services that provide persistent and stable IP address access to that pod.
When you have pod replicas. For example, you have three replicas of a microservice application or MySQL application. The service gets each request, targeting that application, for instance is MySQL, and forwards it to one of those parts.
Services are a good abstraction for loose coupling or communication within the cluster’s components.
Within and Outside the Cluster
Services provide communication within the cluster and outside of the cluster such as browser requests to the cluster or database.
Types of Services in Kubernetes
The more common or default type of service in Kubernetes. Without granting an outside access, it builds a service inside the Kubernetes cluster that may be used by the other apps within the cluster.
This service opens a particular port on all the implemented nodes in the cluster, and the traffic that is received by the port is forwarded to the service. The service cannot be accessed from the outside cluster IP.
It generates the public IPs to enable an access through the cloud. When you use the Google Kubernetes Engine (GKE), a Network Load Balancer is created with a single IP address that can be accessed by the outside users and directs the traffic to the appropriate node in your Kubernetes cluster. The same method as ClusterIP or NodePort can be used to access it.
This is a standard way to represent an external datastore, such as a database, within Kubernetes by creating a service. When the pods from one namespace need to communicate with a service in a different namespace, you can use that ExternalName service (as a local service).
Here are some must-have things before heading toward the following section:
- Kubernetes cluster
- Minikube cluster
- A cluster that is running on Kubernetes with at least a single worker node.
How to Create a Service in Kubernetes
Here, we’ll walk you through a straightforward example that shows you how to create a service on Kubernetes. Let’s begin!
Step 1: Start the Minikube Cluster
First, start the minikube cluster so that you can use the kubectl commands and run your application. The minikube cluster allows you to deploy your nodes, pods, and even cluster in the Kubernetes environment. Hence, it’s essential to keep the minikube in active mode using the subsequent command:
This activates the minikube cluster and makes the Kubernetes environment ready to use.
Step 2: Configure the YAML Manifest to Deployment for Nginx
The service directs all incoming requests to the deployment that we establish using the following command:
The following is the complete configuration file:
Step 3: Create a Service Object in the Cluster
To add a service object to a cluster, execute the following command:
Step 4: Create Three Replicas for Nginx
The following command deploys Nginx with three copies:
Step 5: Specify the Information (Pod, Replicas)
The following commands show you the specifics of the deployment, replicas, and pod:
Step 6: Pod Details
Here, we use the following command to see the exact copies of nginx:
You can see that three copies of Nginx are made in the previous screenshot.
Step 7: Create a Service Definition
In this step, we create a service definition using the following listed command:
With the aforementioned service description, a service of the NodePort type is built using the default namespace, and the requests are forwarded to the pods with the nginx label like pods that were generated during the previous deployment creation stage.
Step 8: Create a Service
To create a Service, use the following command:
In the output, you can see that the service is created successfully.
Step 9: Get the Service Details
In this step, we obtain the specification of the service and search for the NodePort where it is accessible. The command for doing that is as follows:
Step 10: Describe the Service Details
In this step, we use the describe command to see the service details. The describe command is given as follows:
The Service is accessible on Port 30747, as seen in the previous screenshot. You might experience something different because the port was chosen at random from the available range. Now, this service on NodeIp:NodePort allows access to the nginx application.
We learned that service is an abstract layer which is placed in front of pods to provide a stable IP address. We can access the internet using the loadbalancer service type. After that, we implemented the simple example of creating a service step-by-step on Kubernetes, allowing an access to the Nginx application.