What is the difference between Label and Selector in kubernetes?

Question

After reading the official documentation on kubernetes.io, I am still wondering what exactly is the difference between label and selector in Kubernetes?

Editing: For example consider the following Kubernetes object, what is the difference between Labels and Selectors of the following yaml file.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: App1
  template:
    metadata:
      labels:
        environment: production
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9

Answer 1

Labels are key/value pairs that are attached to objects, such as pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects.

Via a label selector, the client/user can identify a set of objects. The label selector is the core grouping primitive in Kubernetes.

In a nutshell label selectors depend on labels to select a group of resources such as pods. For example a deployment selects a group of pods by a label selector in the deployment spec.

Answer 2

Labels are properties that we can attach to each item for example for their type, kind, and so on.

Selectors help us in finding these items. You can think of a selector as a filter.

We could label pods based on some attributes i.e. app name, front-end, back-end.

To select only the pods with the label 'front-end', you would use the keyword selector to filter.

We have different types of objects in kubernetes, pods, nodes, services, replicates, deployments, etc. Over time these objects grow and we need a way to filter them by different categories such as grouping them by their type (pods) or viewing objects by application name (app1, app2) or by their functions (front-end, back-end, etc).

These are the labels:

In this example, once we create the pod, we can use the kubectl with the selector option to view the pods with these labels.

Note: Labels are key-value pair as you can see from the image (app: App1)

Here is another example of how to select pods based on the labels (env, bu for the business unit, and finally all objects)

controlplane ~ ➜  kubectl get pods --selector env=dev
NAME          READY   STATUS    RESTARTS   AGE
db-1-d2rmb    1/1     Running   0          33m
app-1-cxw9j   1/1     Running   0          33m
app-1-gd9bb   1/1     Running   0          33m
app-1-rlxdz   1/1     Running   0          33m
db-1-5xxlc    1/1     Running   0          33m
db-1-gkflt    1/1     Running   0          33m
db-1-lpd5d    1/1     Running   0          33m

controlplane ~ ➜  

controlplane ~ ➜  kubectl get pods --selector bu=finance
NAME          READY   STATUS    RESTARTS   AGE
db-2-kkhkb    1/1     Running   0          34m
app-1-cxw9j   1/1     Running   0          34m
app-1-gd9bb   1/1     Running   0          34m
app-1-zzxdf   1/1     Running   0          34m
app-1-rlxdz   1/1     Running   0          34m
auth          1/1     Running   0          34m

controlplane ~ ➜  kubectl get all --selector env=prod
NAME              READY   STATUS    RESTARTS   AGE
pod/db-2-kkhkb    1/1     Running   0          34m
pod/app-1-zzxdf   1/1     Running   0          34m
pod/app-2-ptvcv   1/1     Running   0          34m
pod/auth          1/1     Running   0          34m

NAME            TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/app-1   ClusterIP   10.43.28.163   <none>        3306/TCP   34m

NAME                    DESIRED   CURRENT   READY   AGE
replicaset.apps/db-2    1         1         1       34m
replicaset.apps/app-2   1         1         1       34m

controlplane ~ ➜  kubectl get all --selector env=prod,bu=finance,tier=frontend
NAME              READY   STATUS    RESTARTS   AGE
pod/app-1-zzxdf   1/1     Running   0          34m