Welcome to Day Part 4 of Day 01 of the #5DaysOfKubernetes challenge! Today, we dive deep into Kubernetes’ powerful features: Labels, Selectors, and Node Selectors. These tools are essential for organizing and managing your Kubernetes objects efficiently. Let’s explore how they work and why they matter.

Labels

Labels are used to organize Kubernetes Objects such as Pods, nodes, etc.
You can add multiple labels over the Kubernetes Objects.
Labels are defined in key-value pairs.
Labels are similar to tags in AWS or Azure where you give a name to filter the resources quickly.
You can add labels like environment, department or anything else according to you.

Labels-Selectors

Once the labels are attached to the Kubernetes objects those objects will be filtered out with the help of labels-Selectors known as Selectors.

The API currently supports two types of label-selectors equality-based and set-based. Label selectors can be made of multiple selectors that are comma-separated.

Node Selector

Node selector means selecting the nodes. If you are not aware of what is nodes. There are two types of nodes Master Nodes and Worker Nodes.

Master Nodes is responsible for the entire Kubernetes Cluster that communicates with the Worker Node and runs the applications on containers smoothly. Master nodes can have multiple Worker Nodes.

Worker Nodes work as a mediator where the nodes communicate with Master nodes and run the applications on the containers smoothly.

So, the use of node selector is choosing the nodes which means on which worker node the command should be applied. This is done by Labels where in the manifest file, we mentioned the node label name. While running the manifest file, master nodes find the node that has the same label and create the pod on that container. Make sure that the node must have the label. If the node doesn’t have any label then, the manifest file will jump to the next node.

Label and Label-Selector HandsOn

If you don’t understand properly, don’t worry. We will do hands-on which will make it easy to understand the concepts of labels, labels-selectors, and node selectors.

YAML file

apiVersion: v1
kind: Pod
metadata:
  name: day07
  labels:
    env: testing
    department: DevOps
spec:
  containers:
    - name: containers1
      image: ubuntu
      command: ["/bin/bash", "-c", "while true; do echo This is Day07 of 30DaysOfKubernetes; sleep 5 ; done"]

After creating the pods by the following command.

List the pods to see the labels that are attached to the pod by the given command

kubectl get pods — show-labels

I have created one more manifest file that doesn’t have any label as you can see in the below screenshot.

Now, I want to list those pods that have the label env=testing.

As we have discussed earlier, there are two types of label-selectors equality and set-based.

This is the example of equality based where we used equalsTo(=).

kubectl get pods -l env=testing

Now, here I want to list those pods that don’t have the label department=DevOps.

kubectl get pods -l department!=DevOps

Now, Suppose I forgot to add the label through the declarative(via manifest) method. So, I can add labels after creating the pods as well which is known as the imperative(via command) method.

In the below screenshot, I have added the new label location and given it the value India.

kubectl label pods day07 Location=India

As we discussed the type of label-selector, let’s see the example of a set-based label-selector where we use in, notin, and exists.

In the below screenshot, we are trying to list all those pods that have an env label with value for either testing or development.

kubectl get pods -l ‘env in (testing, development)

Here, we are trying to list all those pods that don’t have the India or US value for the Location key in the Label.

kubectl get pods -l ‘Location not in (India, US)’

We can also delete the pods as per the label.

Here, We have deleted all those pods that don’t have the Chinda value for the location key in the Label.

kubectl delete pod -l Location!=China

Here, We have completed the HandsOn for the label and label-selector. You can explore more yourself.

Let’s move it to node-selector

nodeSelector HandsOn

As you remember, we have set up minikube on our machine. So, our master and worker node is on the same machine.

To list the nodes on the master node, use the command

kubectl get nodes

apiVersion: v1
kind: Pod
metadata:
  name: nodelabels
  labels:
    env: testing
spec:
  containers:
    - name: container1
      image: ubuntu
      command: ["/bin/bash", "-c", "while true; do echo Node-Selector Example; sleep 5 ; done"]
  nodeSelector:                                         
   hardware: t2-medium

Here, I have created the pod but when I list the pods the status is pending for the created pod.

If you observe the manifest file, the master node is looking for that worker node which has the label hardware=t2-medium.

As you can see there is no label added like hardware=t2-medium

Here we have added the label to the worker node

kubectl label nodes minikube hardware=t2-medium

As sooner the label is added, the sooner the pod will be in a running state.

Conclusion

By mastering Kubernetes Labels, Selectors, and Node Selectors, you gain granular control over resource organization and deployment. These features are invaluable for managing complex Kubernetes clusters effectively.

Power of Kubernetes: Part 2 of Day 02