Kubernetes Labels

What are Kubernetes Labels?

Kubernetes Labels are used for attaching meta tags to different resources, such as pods in the Kubernetes infrastructure. These labels enable DevOps engineers to identify objects, group them based on certain criteria, execute bulk operations, troubleshoot problems, and more. 

Each label has a key/value pair, wherein the key represents an identifier, and the value represents a type within the identifier. For instance, your key could be ‘release,’ and the value can be ‘stable.’ A particular key can have multiple values too. For example, release can have the values ‘stable’ and ‘canary.’ Based on these keys and identifiers, the grouping of objects and other operations, as mentioned above, is possible.

Rules for Kubernetes Labels

There are several rules DevOps Engineers must follow while specifying Kubernetes Labels. These include:

• The keys and values are case-sensitive.
• They must start and end with alphanumeric characters ([a-z0-9A-Z]).
• The only special characters to be used are dashes (-), underscores (_), and dots (.).
• The key can not be empty, but a value can be an empty string used for marking a resource as not having a particular property or as being in a specific state.
• Keys support a prefix, but they are optional and must be separated by a slash (/).
• The label is assumed to be private to the user if a prefix isn’t mentioned.
• Automated system components such as the kube-scheduler must include a prefix.
• If keys and values are without any prefix, they must have a maximum of 63 characters.
• In total, the key and values must have a maximum of 253 characters.
• Based on the Kubernetes syntax, certain labels must be a DNS subdomain.

Types of Kubernetes Labels

Kubernetes label selectors are used for grouping of objects since labels are not unique. Selectors specify requirements that determine which objects the labels must be applied to. In essence, the requirements are conditions, and a selector can have multiple conditions in succession. Only if all the conditions are met, the selector will be applied to the object under consideration. There are two types of label selectors in Kubernetes:

Equality-Based Label Selector

An equality-based label selector has two types of operators: ‘==’ and ‘!=’. The former represents equality, and the latter represents inequality. For instance, 

environment = production

tier != frontend

In the first case, Kubernetes will select all objects where the environment key has the value production. In the second case, Kubernetes will select all objects where the key tier is not equal to frontend. 

Below is a real-time example of how an equality-based label selector works. Here, the pod selects the node with the label ‘accelerator=nvidia-tesla-p100’

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Set-Based Label Selector

The set-based label selectors enable DevOps Engineers to select based on the set of values. There are three kinds of operators in, notin, and exists. For instance,

environment in (production, qa)

tier notin (frontend, backend)

partition

!partition

In the first case, Kubernetes selects all objects with the key as environment and the value as production or qa. In the second case, all objects with the key as tier with values besides frontend and backend are selected. In the third case, all objects with the key as partition are selected, and in the fourth case, all objects besides the ones with the key as partition are selected.

Use Cases of Kubernetes Labels

• Labels can be used for setting network policies to enhance the security of the Kubernetes infrastructure. This can happen by assigning labels for different kinds of users accessing the system and restricting the functions they can perform.

• Labels can also be used for segmenting the network traffic. One way is by assigning labels to different endpoints from where traffic comes into the system. DevOps engineers using labels based on namespaces, reserved labels, and tenancy labels can determine which services can access which endpoints.

• The labels are also used for segmenting resources with a high risk of being attacked due to their sensitivity and ensuring that only a specific set of users or traffic from services can access the critical resources.

• Usually, the above is achieved by using labels that can define ingress and egress communication for the cluster and its various resources. 

Overall, these use cases of Kubernetes labels ensure a higher security level and strengthen the infrastructure. In fact, labels can also be used to ensure that compliance policies for different resources and their configurations are implemented. 

Besides these, the labels are also used for grouping of objects and performing bulk operations. This helps reduce costs and increase the efficiency with which the DevOps engineers work with a Kubernetes cluster. 

Best Practices for Using Kubernetes Labels

• Labeling Strategy: Ensure that labels are clearly assigned such that they are easily understandable. It is important that labels do not cause confusion and, as a result, lead to misconfigurations or go against the set labeling policy.

• Automation using CI Tools: Continuous integration (CI) tools can help automate the labeling process in Kubernetes by integrating with the cluster and applying labels to resources as part of the CI/CD pipeline.

• Manage Labels via Code: Instead of using kubectl to manage and modify your labels, you can do it on a code level but must make sure that the resulting Kubernetes configuration does not override the changes made via the CLI.

• Customize Based on Kubernetes Recommendations: Customizing based on Kubernetes recommended labels can improve cluster consistency, organization, and efficiency, while simplifying the integration of new tools and services.
• Use Prefixes: Using prefixes always brings an additional layer of clarity to the code as engineers can differentiate between a label for a private user, a shared label, and a custom label.

Actionable, contextual, end-to-end
{Kubernetes-native security}

From code to cluster, helm to node, we’ve got your Kubernetes covered:

Cut the CVE noise by significantly reducing CVE-related work by over 90%

Automatic Kubernetes compliance for CIS, NSA, Mitre, SOC2, PCI, and more

Manage Kubernetes role-based-access control (RBAC) visually

By Security standards, at DevOps pace.

See ARMO in Action