Understanding the Kubernetes Service YAML Parameters

In the previous post, we did a walk-through of the Kubernetes Pod YAML file. In this post, we will do the same for Kubernetes Service YAML file.

Basically, we will walk-through the various parameters in the Service YAML file.

So without wasting any time, let’s dive in.

1 – Revisiting the Kubernetes Service YAML file

Below is the YAML file we created for our first Kubernetes service in an earlier post about using Kubectl to create our first Kubernetes Pod.

apiVersion: v1
kind: Service
metadata: 
  name: docker-react-node-port
spec:
  type: NodePort
  ports: 
    - port: 3050
      targetPort: 80
      nodePort: 31515
  selector: 
    component: web

Basically, this file describes the minimum parameters for defining a Kubernetes Service. Using Kubectl, we can apply this configuration file on our Kubernetes cluster.

Let’s understand the various parameters present in this file.

2 – Kubernetes Service YAML Parameters

As a reminder, in Kubernetes, every configuration file creates an object. Different objects do different things on our cluster. Some objects run our application. Other objects might deal with networking or monitoring.

Let’s look at each parameter for our service object.

2.1 – API Version

API version basically limits the type of object we can create.

In other words, with something like the Kubernetes API version v1, we get access to object types such as Pod, Service and so on. Similarly, different API versions may provide access to different object types.

2.2 – Kind

The next important parameter is known as Kind. Basically, the Kind parameter specifies the object type we want to create using this configuration file.

In this example, we are creating a Service object and hence the value of Kind parameter is Service.

kind: Service

A Service object is typically used for networking related aspects in a Kubernetes cluster.

2.3 – Meta Data

Next up, we have the Meta Data parameter as below:

metadata: 
  name: docker-react-node-port

Under meta-data, we specify the property name. Basically, name helps us reference the object in our cluster.

In other words, this property can be used to access our service from other Kubernetes objects. Also, Kubectl commands can access our service object using the value of the name parameter.

2.4 – Spec Type

Kubernetes Service also has its own individual types. And the Type property under Spec helps specify the same.

spec:
  type: NodePort

There are basically four different types of services:

• Cluster IP
• Node Port
• Load Balancer
• Ingress

Node Port is the simplest of the lot. Its sole purpose is to expose a container to the outside world. Therefore, in essence, it is only good for development purposes.

2.5 – Selector

Before we look at the Ports property, it is better to check out the Selector parameter.

selector: 
    component: web

Basically, this parameter acts as the link between the Service and the Pod. If you recall from the previous post, we had used the label of web while defining the Pod. See below:

metadata:
  name: docker-react-pod
  labels: 
    component: web

Using the selector property, we are able to tell the Kubernetes Service about where to route the incoming traffic. Basically, when the service receives a request, it will check for any other objects with label having the combination of component: web and route the traffic to that particular object.

This is part of the label selector system in Kubernetes and is a fundamental way in which we glue objects together in Kubernetes.

2.6 – Ports

The last piece of the puzzle is the Ports parameters. Basically, this property takes an array of port mappings depending on your requirement.

ports: 
    - port: 3050
      targetPort: 80
      nodePort: 31515

The port property defines the port that can be used by another application running on a different pod in our Kubernetes cluster.

Second, the targetPort property is the actual port on the Pod we want to expose. In this case, it is port 80 on our Nginx server running on the Pod. You can refer to our earlier post for more details about the same.

Lastly, the nodePort property defines the port that we can use to access our application from our browser. It can have a range from 30000-32767. As you can see, we have defined it explicitly to 31515.

Conclusion

With this, we have covered every parameter in our Kubernetes Service YAML file.

You can check out the YAML file on Github for reference.

Happy Learning!