Understanding Kubernetes Labels — A Beginner’s Guide

Why Labels in Kubernetes so important ?

Find Complete mind map of A Beginner’s Guide to Kubernetes

Kubernetes provides a flexible and powerful way to organize resources using Labels. Labels are key/value pairs that can be attached to Kubernetes objects like Pods, Nodes, and more. They are used to identify, group, and filter resources based on specific attributes.

Check out “Understanding Kubernetes — A Beginner’s Guide” for the comprehensive series🚀

What are Kubernetes Labels?

Labels are key-value pairs that are attached to Kubernetes objects, such as pods and services, to help organize and identify them. Labels are used extensively in Kubernetes for a variety of purposes, including grouping resources together, selecting objects for processing by Kubernetes controllers, and routing network traffic to services.

Here are some key concepts to focus on:

1. Labeling Resources: Learn how to add labels to resources using kubectl commands or by defining them in YAML manifests.
2. Label Selectors: Understand how label selectors work and how they can be used to query resources based on their labels.
3. Labels in Controllers: Many Kubernetes controllers such as ReplicaSet, Deployment, and DaemonSet use labels to manage and select resources. Understanding how these controllers use labels is crucial to effectively manage Kubernetes resources.
4. Label Best Practices: Learn best practices for labeling resources to ensure consistency and easy maintenance.

Adding and Editing Labels

Labels can be added and edited in two ways, imperatively with kubectl or declaratively in a Manifest file in YAML format. Here are some examples:

Imperatively with kubectl

# add labels
$ kubectl label pod nginx-pod-1 tier=PROD app=v1
$ kubectl label pod nginx-pod-2 tier=ACC app=v1
$ kubectl label pod nginx-pod-3 tier=TEST app=v1

# update label
$ kubectl label pod nginx-pod-1 tier=ACC app=v1 --overwrite  # overwrite
$ kubectl label pod nginx-pod-1 tier-   # delete label

Declaratively in a Manifest in YAML

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-1
  labels:
    app: v1
    tier: PROD
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-2
  labels:
    app: v1
    tier: ACC
spec:
  containers:
  - name: nginx
    image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod-3
  labels:
    app: v1
    tier: TEST
spec:
  containers:
  - name: nginx
    image: nginx

Querying Using Labels and Selectors

Labels and Selectors allow us to easily query and filter Kubernetes objects based on specific attributes. Here are some examples:

# show labels of all pods
$ kubectl get pods --show-labels

# select pods with tier=PROD label
$ kubectl get pods --selector tier=PROD

# select pods with tier=PROD or tier=TEST label
$ kubectl get pods -l 'tier in (PROD, TEST)'

# select pods without tier=PROD or tier=TEST label
$ kubectl get pods -l 'tier notin (PROD, TEST)'

How Kubernetes Uses Labels?

Kubernetes uses Labels extensively for different purposes, including:

• Controllers and Services match pods using Selectors
• Pod Scheduling, scheduling to specific Node

Here’s an advanced example of how you can use labels with a deployment and a service to ensure high availability and scalability:

Let’s say you have a microservice application that consists of three replicas of a frontend service and three replicas of a backend service. You want to ensure that the frontend service replicas always connect to the same backend service replicas to maintain consistency.

To achieve this, you can use labels to label the backend service replicas with a unique identifier, and use a label selector in the frontend service’s deployment to ensure that it always connects to the same backend replicas.

Here’s how you can set this up:

1.Label the backend service replicas with a unique identifier, let’s say “app=backend-1”.

$ kubectl label pod backend-1-abc12 app=backend-1
$ kubectl label pod backend-1-def34 app=backend-1
$ kubectl label pod backend-1-ghi56 app=backend-1

2.Create a deployment for the frontend service with a label selector that matches the backend service replicas labeled with “app=backend-1”.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: frontend:latest
        env:
        - name: BACKEND_SERVICE_HOST
          value: backend-service
        - name: BACKEND_SERVICE_PORT
          value: "80"
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - backend-1
            topologyKey: kubernetes.io/hostname

Note the affinity section that uses podAntiAffinity to ensure that the frontend pods are not scheduled on the same node as the backend pods labeled with "app=backend-1". This ensures high availability by avoiding a single point of failure.

3. Create a service for the backend replicas labeled with “app=backend-1”, and use a label selector to ensure that the frontend pods always connect to the same backend replicas.

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
    app-name: backend-1
  ports:
  - name: http
    port: 80
    targetPort: 80
  type: ClusterIP

Note the selector section that uses two labels to ensure that the service only selects the backend replicas labeled with "app=backend" and "app-name=backend-1". The frontend pods will use this service to connect to the backend replicas.

With this setup, the frontend service pods will always connect to the same backend service replicas labeled with “app=backend-1”, ensuring consistency and high availability. You can also scale the number of replicas for both the frontend and backend services as needed, and Kubernetes will automatically ensure that the affinity and label selectors are respected.

In conclusion, Labels are a powerful and flexible mechanism for organizing and filtering Kubernetes resources. By leveraging Labels and Selectors, we can easily manage large and complex Kubernetes environments.

🔔 Stay tuned or subscribe to my series: “Understanding Kubernetes — A Beginner’s Guide” to explore everything about Kubernetes. 🚀

➕Join the Medium Membership Program to support my work and connect with other writers.

📝 Have questions or suggestions? Leave a comment or message me through Medium. Let’s connect!

Thank you for your support! 🌟