Kubernetes Labels & Selectors (original) (raw)

Last Updated : 15 Sep, 2025

Labels are key/value pairs that you attach to Kubernetes objects like Pods, Deployments, and Services. They are the primary way to organize your resources. Common examples of labels include:

Working with Labels

**1. Create a Pod with Labels Save the following manifest as labeled-pod.yaml. We are attaching three distinct labels to this Pod in the metadata.labels section.

apiVersion: v1
kind: Pod
metadata:
name: web-server-pod
labels:
app: nginx
tier: frontend
environment: development
spec:
containers:

Apply the manifest to create the Pod:

$ kubectl apply -f labeled-pod.yaml

**2. Viewing Labels You can view the labels of your Pods using the --show-labels flag.

$ kubectl get pods --show-labels

**Output:

NAME READY STATUS RESTARTS AGE LABELS
web-server-pod 1/1 Running 0 30s app=nginx,environment=development,tier=frontend

To view specific labels as columns, use the -L flag.

$ kubectl get pods -L app,environment

**3. Adding and Modifying Labels You can easily add or update labels on an existing object using the kubectl label command. Let's add an owner label.

$ kubectl label pod web-server-pod owner=admin

Verify the new label was added:

$ kubectl get pods --show-labels

To update an existing label, you must use the --overwrite flag.

$ kubectl label pod web-server-pod environment=staging --overwrite

What are Selectors?

If labels are the sticky notes you put on objects, **Selectors are how you find and filter those objects based on the notes. Selectors are used extensively in Kubernetes to define which Pods a Service should target, which Pods a Deployment should manage, and more.

There are two types of selectors:

  1. **Equality-Based: The most common type. It filters based on exact key and value matches. The operators are =, ==, and !=.
  2. **Set-Based: More flexible. It filters based on whether a key's value is in a set of values. The operators are in, notin, and exists.

Hands-On: Using Selectors

To make this interesting, let's create two more Pods. db-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
name: database-pod
labels:
app: postgres
tier: backend
environment: development
spec:
containers:

api-pod.yaml:

apiVersion: v1
kind: Pod
metadata:
name: api-pod
labels:
app: user-api
tier: backend
environment: production
spec:
containers:

Apply both files: $ kubectl apply -f db-pod.yaml -f api-pod.yaml

Now, let's query these Pods using selectors with the -l flag.

**1. Equality-Based Selection Find all Pods in the development environment.

$ kubectl get pods -l environment=development

Find all Pods that are part of the backend tier.

$ kubectl get pods -l tier=backend

You can also combine selectors with a comma. Find the Pod that is both backend and production.

$ kubectl get pods -l 'tier=backend,environment=production'

**2. Set-Based Selection Find all Pods in either the development or staging environment.

$ kubectl get pods -l 'environment in (development,staging)'

Find all Pods that do **not have the tier label set to frontend.

$ kubectl get pods -l 'tier notin (frontend)'

Find all Pods that have an app label, regardless of its value (the exists operator).

$ kubectl get pods -l 'app'