Label Best Practices

John Harris

Labels are a means for describing and identifying components that make up an application with arbitrary key/value pairs. Labels are attached to Kubernetes API objects at time of creation or can also be added/modified/removed at a later time. Labels are simple pieces of metadata that can help with organization and administration of an application’s lifecycle.

Labels are not always arbitrary, and are sometimes applied automatically to some API objects by Kubernetes, typically via the kubelet.

Using Labels

Label Example

Here’s an example of some labels attached to a pod manifest:

---
apiVersion: v1
kind: Pod
metadata:
  name: my_app
  namespace: my_app
  labels:
    app: my_app
    version: 1.0.0
    component: frontend
spec:
  ...

Labels with Selectors

Selectors enable you to select Kubernetes API objects based on the labels applied to them. This is useful when defining what workloads should be routed to or from a service and their underlying components, such as what pods should be managed by a replica set. A selector achieves this by specifying which key/value pairs to search for within API object metadata (typically, but not limited to pod specifications) to be able to properly perform these tasks, and is one of the main purposes for labels.

Selector Example

Here’s an example of using a service to expose pods identified by their applied labels.

---
apiVersion: v1
kind: Service
metadata:
  name: myapp_db_svc
  namespace: my_app
  labels:
    app: my_app_db
    version: 1.0.0
    component: backend
spec:
  selector:
    app: my_app_db
    version: 1.0.0
    component: backend
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 3306
      targetPort: 3306

Identifying Application Components with Labels

The Kubernetes API can be queried with the kubectl client to list specific components with specific labels. There are three operators that can be used to perform these queries: =, ==, and !=.

Label Query Examples

Find all components in Kubernetes that are related to running MySQL (app: mysql) and not production (environment: production).

kubectl get all -l name==mysql,environment!=production -A

In the command above:

• get: lists the API objects
• all: is equivalent to all component/API object types
• -l: label(s) to query/filter on
• name==mysql: label with key name is/equals mysql
• ,: comma separator for multiple label queries
• environment!=production: label with key environment is not/not equal to production
• -A: from all namespaces in Kubernetes.

Considerations when Creating Labeling Standards

As you can see from the prior sections, labels have a fairly important place in successful application deployment within Kubernetes. It is important to standardize labels in every component within a Kubernetes environment. These design decisions will make locating and managing components easier in the long run.

Some recommended labels per the Kubernetes documentation include:

VMware recommends you extend the above labels with the following, where relevant.