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
  name: my_app
  namespace: my_app
    app: my_app
    version: 1.0.0
    component: frontend

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
  name: myapp_db_svc
  namespace: my_app
    app: my_app_db
    version: 1.0.0
    component: backend
    app: my_app_db
    version: 1.0.0
    component: backend
  type: ClusterIP
    - 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 !=.

Operator Description
= equal to or is
== equal to or is
!= not equal to or is not

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:

Key Description Example
name The name of the application mysql
instance A unique name identifying the instance of an application frontend-green
version The current version of the application (e.g., a semantic version, revision hash, etc.) 1.0.0
component The component within the architecture database
part-of The name of a parent application this application is part of wordpress
managed-by The tool being used to manage the operation of an application app-manager

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

Key Description Example
tier The tier in the overall application architecture frontend
environment The environment in reference to the systems development lifecycle dev
purpose The purpose of this particular application component queue
owner The team or individual responsible for deploying or maintaining the application component “John Doe”
owner-email The email address of the responsible team or individual for deploying or maintaining the application component
repository A URL to the repository that contains this application’s source code “”
managed-by The tool being used to manage the operation of an application helm
business-unit The business unit who owns this application “finance”