Labels and Selector in Kubernetes

Understanding Kubernetes Labels and Selectors

Kubernetes labels and selectors are powerful features that help us to manage and organize our resources within a Kubernetes cluster. Labels are key/value pairs that we attached to Kubernetes objects like pods, services, and deployments. Selectors allow us to query those labels to perform operation on a group of objects. We will understand labels and selectors in this article with example, how it help us to in managing our cluster objects.

Let's take a example of Pod with labels.

apiVersion: v1
kind: Pod
metadata:
  name: webapp
  labels:
    app: webapp
    environment: sit
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Here in above example we can see that the pod is labeled with app: webapp and environment: sit

1. Equality-based selectors: Equality-based selectors allow us to filter objects based on the equality or inequality of their labels.

   \= or ==: Equals

   !=: Not Equals

Lets understand this Equality-Based Selectors with example. In the below example, Suppose we have 3 different pods and each having different labels.

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    app: webapp
    environment: sit
spec:
  containers:
  - name: nginx
    image: nginx

---

apiVersion: v1
kind: Pod
metadata:
  name: pod2
  labels:
    app: webapp
    environment: sit
spec:
  containers:
  - name: nginx
    image: nginx

---

apiVersion: v1
kind: Pod
metadata:
  name: pod3
  labels:
    app: backend
    environment: production
spec:
  containers:
  - name: nginx
    image: nginx

Now, if we want to select only the pods that have labels as app: webapp and environment: sit, we can use Equality-Based Selectors like below.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-sit-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp
      environment: sit
  template:
    metadata:
      labels:
        app: webapp
        environment: sit
    spec:
      containers:
      - name: nginx
        image: nginx

We can see that in above deployment objects we have used the selector matchLabels: { app: webapp, environment: sit } so that it will select that particular pods.

In below output when we describe the pod by below command.

kubectl describe deployments <deployment-name>

The above command will create below output and where in highlighted section we can see that it has created deployment which has label app: webapp and environment: sit.

2. Set-Based Selectors: Set-based selectors allow us to filter objects based on set operations. They use the below operators.

• In: Here value must be within a specified set.

• NotIn: Here value must not be within a specified set.

• Exists: The label key must exist

• DoesNotExist: The label key must not exist.

Example usage of In and NotIn operators.

Lets consider the same set of 3 pod which have different labels and here we will use In and NotIn operators in our deployments.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: multi-environment-deployment
spec:
  replicas: 2
  selector:
    matchExpressions:
    - key: environment
      operator: In
      values:
      - production
      - sit
    - key: app
      operator: NotIn
      values:
      - backend
  template:
    metadata:
      labels:
        app: webapp
        environment: production
    spec:
      containers:
      - name: nginx
        image: nginx

Here in above Deployment example we have used In operators to select pods with the environment label either as production or sit.

In below output when we describe the deployments by below command.

kubectl describe deployments <deployment-name>

The above command will create below output and where in highlighted section we can see that it has created deployments which has label app: webapp and environment: sit or production.

We have used here NotIn operator also to exclude pods with the app label backend.

Example usage of Exists and DoesNotExist operator.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-exists-deployment
spec:
  replicas: 2
  selector:
    matchExpressions:
    - key: app
      operator: Exists
    - key: tier
      operator: DoesNotExist
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: nginx
        image: nginx

Here in above example we have used Exists operator to selects pods with the app label, regardless of its value.

The DoesNotExist operator ensures that the deployment does not select the pods with the tier label.

In below output when we describe the deployments by below command.

kubectl describe deployments <deployment-name>

The above command will create below output and where in highlighted section we can see that it has created deployments which has label app regardless of its value and DoesNotExist operator ensures that deployment does not select pods with the tier label.

Practical Example: Blue-Green Deployment

Lets understand the practical usage of Labels and Selectors by Blue-Green Deployment example. In below example we will create 2 Deployment one named blue and other named green.

• Blue Version Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: blue
  template:
    metadata:
      labels:
        app: webapp
        version: blue
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

• Green Version Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: green
  template:
    metadata:
      labels:
        app: webapp
        version: green
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Now Lets create a service to expose the application.

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
    version: blue  # Initially point to the blue version
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort

Here in above example we have now exposed Blue version of application to the end users and meanwhile we are developing Green Version of our deployments with some extra features. When the Green Version will be tested internally and we are good to release the Green Version then we just need to update selectors in our service objects like below.

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
    version: green  # Finally switched to new version green
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort

That's all we have to understand in labels and selectors in Kubernetes.