DEV Community

Joseph Cardillo
Joseph Cardillo

Posted on

Understanding Service Labels in Kubernetes: A Simple Guide to Swapping Backends

I’ve always found the best way to grasp Kubernetes concepts is through real-world analogies and hands-on practice. Today, let's dive into how service labels work in Kubernetes by walking through a practical example. We'll see how labels can help us easily switch the backend of a NodePort service from one pod to another.

The Name Tag Analogy

Think of labels in Kubernetes like name tags at a conference. Each attendee wears a tag that shows their role or interest, such as 'Developer,' 'Designer,' or 'Manager'. These tags help people quickly identify and group attendees with similar interests. In Kubernetes, labels work the same way, acting as tags on resources, like pods and services, to help organize and manage them more easily.

Step 1: Create an NGINX Pod

First, create a pod running NGINX:

kubectl run nginx-pod --image=nginx
Enter fullscreen mode Exit fullscreen mode

Verify the pod is running:

kubectl get pods

NAME                               READY   STATUS    RESTARTS        AGE
nginx-pod                          1/1     Running   0               8s
Enter fullscreen mode Exit fullscreen mode

Step 2: Expose the Pod via a NodePort Service

Now, let's expose this pod so we can access it from outside the cluster.

kubectl expose pod nginx-pod --type=NodePort --port=80
Enter fullscreen mode Exit fullscreen mode

Check the service details:

kubectl get services

NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx-pod         NodePort    10.109.46.128   <none>        80:32303/TCP   6s
Enter fullscreen mode Exit fullscreen mode

Step 3: Add a Selector Label to the Service

Our service currently doesn't have a specific selector label, or "nametag". Let's add role: developer to the service so it knows to send traffic to pods with this label.

First, add the label to the pod:

kubectl label pod nginx-pod role=developer
Enter fullscreen mode Exit fullscreen mode

Now, edit the service to include the same selector:

kubectl edit service nginx-pod
Enter fullscreen mode Exit fullscreen mode

This will open a text editor. Find the selector section and modify it as follows:

  selector:
    role: developer
Enter fullscreen mode Exit fullscreen mode

Step 4: Access the NGINX Service

To access the nginx pod via the NodePort, get the NodePort number:

kubectl get service nginx-pod
Enter fullscreen mode Exit fullscreen mode

Output:

k get svc nginx-pod
NAME        TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx-pod   NodePort   10.109.46.128   <none>        80:32303/TCP   3m37s
Enter fullscreen mode Exit fullscreen mode

In this example, the NodePort is 32303. Now, curl the service using the node's IP address (replace NODE_IP with your node's actual IP, which can be found with ip a | grep eth0):

curl NODE_IP:32303
Enter fullscreen mode Exit fullscreen mode

You should see the default NGINX welcome page HTML.

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]
Enter fullscreen mode Exit fullscreen mode

Step 5: Create a New Pod Using the HTTPD Image

Now, let's bring in our second conference attendee by creating a new pod with the HTTPD image.

kubectl run httpd-pod --image=httpd
Enter fullscreen mode Exit fullscreen mode

Label this pod accordingly:

kubectl label pod httpd-pod role=manager
Enter fullscreen mode Exit fullscreen mode

Step 6: Update the Service Selector to Point to the New Pod

Edit the service again:

kubectl edit service nginx-pod
Enter fullscreen mode Exit fullscreen mode

Change the selector to:

  selector:
    role: manager
Enter fullscreen mode Exit fullscreen mode

Step 7: Access the Updated Service

Curl the service again:

curl NODE_IP:32303
<html><body><h1>It works!</h1></body></html>
Enter fullscreen mode Exit fullscreen mode

Wrapping Up

By simply changing the label selector in our service, we redirected traffic from one pod to another without changing the service's endpoint or port. This is the power of labels in Kubernetes—they allow you to dynamically manage and route traffic between different pods.

Top comments (0)