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

September 18, 2024

This content originally appeared on DEV Community and was authored by Joseph Cardillo

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

Verify the pod is running:

kubectl get pods

NAME                               READY   STATUS    RESTARTS        AGE
nginx-pod                          1/1     Running   0               8s

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

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

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

Now, edit the service to include the same selector:

kubectl edit service nginx-pod

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

  selector:
    role: developer

Step 4: Access the NGINX Service

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

kubectl get service nginx-pod

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

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

You should see the default NGINX welcome page HTML.

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

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

Label this pod accordingly:

kubectl label pod httpd-pod role=manager

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

Edit the service again:

kubectl edit service nginx-pod

Change the selector to:

  selector:
    role: manager

Step 7: Access the Updated Service

Curl the service again:

curl NODE_IP:32303
<html><body><h1>It works!</h1></body></html>

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.

This content originally appeared on DEV Community and was authored by Joseph Cardillo

kubernetes