Kubernetes Label Selector and Field Selector

I'm an engineer at MayaData, a company dedicated to enabling data agility through the use of Kubernetes as a data layer and the sponsor of the CNCF project OpenEBS and other open source projects. Take it for a test drive via free and easy to use management software by registering here.

Ok - let's get started.  The resources that we create in a Kubernetes cluster can be organized using labels. Before we talk about the field selector in Kubernetes, let’s quickly walk through what labels are.

Labels are key value pairs that can be used to identify or group the resources in Kubernetes. In other words, labels can be used to select resources from a list. You can label Kubernetes-native resources as well as Custom Resources. To better understand this, let us do some hands-on practice with labels.

This tutorial will assume that you have a working minikube setup or a Kubernetes cluster setup.

The following is a link to the yaml. Its application will create a pod.

https://raw.githubusercontent.com/sonasingh46/artifacts/master/samples/sample-pod.yaml

The yaml looks like this:

Notice the bold text in this yaml. That is one way to add labels to a resource through specification in yaml.Let us now create a pod by executing the following command:

kubectl apply -f https://raw.githubusercontent.com/sonasingh46/artifacts/master/samples/sample-pod.yaml

You can use the above command directly or copy the content to save it on your local machine in a file , say sample-pod.yaml.

Now, we will run the following commands to check for labels in the pod:

As you can see in the above output, example-pod uses a label of key value pair as env=development.
You can also do a kubectl get pod example-pod -o yaml to see all of the fields and labels.

Let us now add another label to the above pod using the kubectl command.

Adding a label:

Removing a label:

Updating a label:

kubectl label --overwrite pods example-pod env=prod will update the value of key env in the labels, and if the label does not exist, it will create one.

Now we will create one more pod by editing the above yaml and changing metadata.name to example-pod1. We will also remove the label from yaml.

Create a yaml file with above content, let’s say sample-pod1.yaml, and apply it.

You can learn more about some other kubectl label commands using kubectl label --help

Now we know enough to tag our resources with labels either by providing it in yaml or using the kubectl command. Let us now explore how the label can help in filtering or grouping the resources.

Selection Via Labels (Label Selector)

Using selection via labels can have the following two types of requirements:

1. Equality-Based Requirement
2. Set-Based Requirement

Equality Based Requirement

An equality-based requirement will match the specified label and filter the resources. The supported operators are =, ==, !=.

Suppose I have the following pods with the labels.

Now, I want to see all pods with online status:

Similarly, go through the following commands:

In the above commands, labels separated by commas are a type of AND satisfy operation.

Similarly, you can try other combinations using the operators ( =,  !=, ==) and play!

Set-Based Requirement

Label selectors also support set-based requirements. In other words, label selectors can be used to specify a set of resources.

The supported operators here are in, notin and exists.

Let’s walk through kubectl commands for filtering resources using set-based requirements.

Here, in env in (prod,dev), the comma operator acts as an OR operator. That is, it will list pods which are in prod or dev.

Here the comma operator separating env in (qa) and tier in (frontend)will act as an AND operator.
To understand the exists operator, let us add the label region=central to example-pod and example-pod1 and region=northern to example-pod2.

Now, I want to view pods that are not in the central region:

You can see here that example-pod2 has a region key with the value northern, and hence appears in the result. But one point to note is that the other two pods in the result do not have any region field and will satisfy the condition to appear in the result. If we want pods that have the region key to be the set of resources over which filtering should be done, we can restrict via the exists operator. We do not specifically write exists as we do write the in and notin in commands.

Similarly, you can play around by using various combinations in set-based requirements too for selecting a set of pods.

For more information about Labels and Selectors you can visit

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Selection Via Fields (Field Selector)

We can also select kubernetes resources via a field-selector, but it has very limited support as of now.

The field selector does not support set-based requirement. Even the support for equality-based requirement is not extensive.

There are a limited number of fields that can be used for selection.

For example, the following command will fail:

So, one can conclude that field-selector only works for metadata.name and for additional fields for some types, but it is a very select set. For examples, visit the link to see fields supported on pods:

https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/core/v1/conversion.go#L160-L167

I hope that this explanation about label and field selectors will help you in understanding how they work and how they can be used.

This article was first published on Jul 14, 2018 on MayaData's Medium Account.