Joseph CardilloI’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.
