Kubernetes Basics – Services

Introduction

In previous two posts on Kubernestes basics, we covered some fundamental concepts, a high level overview and then started working with Kubernetes cluster and Pods.

We learned that Kubernetes is all about running containerized apps. A Kubernetes cluster consists of masters and nodes which we can manage through an API using kubectl command line tool. We learned that Pods are the smallest deployable unit in Kubernetes API and Pod hosts the container(s).

If you are new to these topics you can read the following two posts which will provide you with all that basic information:

• Kubernetes Basics
• Kubernetes Basics – Pods

Today, we will cover Services in Kubernetes, what they are, their purpose and how to create and work with services.

If you remember from previous post, we had a pod running inside a cluster:

The question is, how can we connect with this pod? we saw we can use port-forwarding for this purpose. However port-forwarding may be useful for debugging purposes mainly. It’s neither fast nor, in my experience, especially reliable, but it’s useful for debugging.

The port-forward feature of kubectl simply tunnels the traffic from a specified port at your local host machine to the specified port on the specified pod. API server then becomes, in a sense, a temporary gateway between your local port and the Kubernetes cluster.

Kubernetes – Services

Before we start with services, let see is a sample situation where an external caller need to communicate with pods:

Now, each Pod in a cluster is assigned a unique IP address. Kubernetes Pods are created and destroyed to match the state of the cluster. They can live and die. So, as the Pods are ephemeral and that’s why we can not rely on Pods IP addresses. So, how do we connect to our apps in a reliable manner? meet Services. We can use services for stable networking.

• Services can help with external and/or external access to the Pods.
• A service provides a single point of entry for accessing one or more Pods.
• They lets you expose an application running in Pods to be reachable from outside your cluster.
• You can also use Services to publish services only for consumption inside your cluster.
• Service provide a reliable network endpoint for unreliable Pods.
• They are an abstraction layer which hides the unreliable nature of Pods.
• Services also do Pods load-balancing.
• Labels are used to associate Pods with Services.

Every service gets a Name, IP and Port, which are stable (Kubernetes makes sure that those never change). So now instead of connecting to Pods, we can point to Services.

Just like pods, We define services in a YAML file, post that to the API-Server and Kubnernetes does all of the creating magic.

Here is a very simple diagram to visualize a service in kubernetes:

We can run following command to list all the services:

kubectl get services

As you can see there is already a service listed, this service is setup by kuberetes and notice the Type which is mentioned as ClusterIP. Lets discuss different service types next:

Service Types

Depending on the requirement, we can create different type of services. Following is the list of different service types in kubernetes:

• ClusterIP (default): This type is used for internal cluster connectivity.
• NodePort: This type allows external access via nodes.
• LoadBalance: Provision external IP to act as a load-balancer for the service (cloud).
• ExternalName: Acts as an alias (proxy) for an external service.

These service types follow a layered design and built on top of each other.

Lets visualize these:

ClusterIP

NodePort

LoadBalance

ExternalName

Creating Services

As now we know the basics of what services are and their types. Lets see how we can create a service.

Just like Pods, we define a service in a YAML file and then post it to API-Server. Following shows a YAML structure for this purpose:

This is the same codebase from previous article. I created a new folder Services which will hold all the service related YAML files.

As you can see that the YAML structure is very similar to what we had for pods. We have now kind set to Service, we have metadata section as well. Then we have the specs section, we are associating pods which have the label matches what is defined in selector. we didn’t specified any type for the service and it will default to ClusterIP type automatically.

In ports section, we give it a name, then specified port which is a port inside the cluster. the name we mentioned in above and this port are registered with DNS. targetPort is container port where our app is listening.

Now, I also have a pod running from previous post, and here is the corresponding information about that pod (please check previous post for more details):

As you can see this pod has the same label (web) which we used in selector of Service YAML.

Ok, so we have a pod running and we also have now a YAML file for the service. Lets post service yaml file to API Server using following command:

kubectl apply -f service.yaml

and we will get service created message and we can check that using kubetctl as shown below:

and as mentioned before, because we did not specified the type, it defaults to ClusterIP (internal cluster connectivity).

We can see more information about service using get or describe commands as shown below:

We can delete a service using following command:

kubectl delete service tokengen

here is the command output:

So, we have created a ClusterIP type service, lets see how to create a NodePort type service next.

Creating a NodePort Service

Here I have the YAML file for a NodePort type of service and as we know that this type of service allows external access:

As you can see that this time, we specified the type (NodePort in this example) and then we also provide a value for nodePort. The value for nodePort is optional (default b/w 30000-32767) but can be specified as well. This external port (nodePort) maps on every cluster node.

Lets apply this file just like before and notice that service is created:

and as we know that NodePort allows external access and we can test this using postman as shown below:

So, our NodePort type of service is created and working as expected. We can access it from outside of our cluster.

Summary

In this post, we learned the basics of Kubernetes Services. We learned Services provides us stable networking to reach out to short lived pods. They also do the load balancing and there are different service types from InternlCluster connectivity to NodePort and Cloud LoadBalance.

We saw example of ClusterIP service type and NodePort type.

LoadBalance service type integrates easily with load balancers with cloud providers. We though did not cover this service type in detail however the principals are the same. ExternalName service type are not that common, but if needed you can create and use those in similar fashion.

Services follows a layered design and they are built on top of each other. We also saw some kubectl commands to create, list and delete services.

You can download the app source code and YAML files from this git repository.

Let me know if you have some questions or comments. Till next time, Happy Coding.

My Recent Books