liveBook · Manning

Label

As explained in Kubernetes in Action, Second Edition

A label is a key-value metadata attribute attached to a Kubernetes object for identifying and selecting it.

A label is a key–value pair attached to a Kubernetes object to identify its role. Labels help people organize pods and other objects by application, release, or another useful criterion. Unlike namespaces, which separate groups of objects, labels let you group the same objects in several ways. section 7.2.1 section 7.2

Identify an application and its release

Give a stable pod the labels app=kiada and rel=stable. Give a canary pod app=kiada and rel=canary. The shared app value identifies the application; the differing rel values distinguish its releases. Put these pairs in the object's metadata.labels map when creating it. section 7.2.1 section 7.2.2

Listing 7.3 A pod with labels
apiVersion: v1
kind: Pod
metadata:
  name: kiada-001
  labels:           #1
    app: kiada         #2
    rel: stable      #3
spec:
  ...

The Pod manifest shows exactly where app and rel belong under metadata.labels. section 7.2.2

An object can have multiple labels, but each key must be unique on that object. Keys and values are strings you choose, subject to syntax rules. A key may have a prefix, as in kubernetes.io/arch; reserve the kubernetes.io/ and k8s.io/ prefixes for Kubernetes components. A value may be empty but cannot contain whitespace or exceed 63 characters. Use annotations for nonidentifying information that does not fit label values. section 7.2.1 section 7.2.3

You can inspect and change labels without recreating a pod:

  • Run kubectl get pods --show-labels to see every label, or kubectl get pods -L app,rel to show those keys as columns. section 7.2.2
  • Run kubectl label pod kiada-canary app=kiada rel=canary to add labels. To replace an existing value, add --overwrite; to remove a key, use its name followed by a hyphen, such as suite-. section 7.2.2

Labels also let label selectors find subsets of objects for bulk operations. A Service can select pods by label: an enabled=true selector includes a pod carrying that label, while removing the label removes it from the Service. Consistent application labels make related components recognizable to people and tools; Kubernetes also uses certain labels on system objects, such as nodes. section 7.2.4 section 11.6.2

How Kubernetes in Action, Second Edition covers it

How deep it goes
Defines key–value labels, demonstrates manifest and kubectl changes, and specifies syntax rules; does not examine label implementation internals.
Examples
Uses stable and canary pod labels, a Pod YAML manifest, kubectl commands, and a Service selector.
What it assumes
Assumes basic familiarity with pods, manifests, and kubectl while defining labels from the beginning.
What you can do after
Operate/configure it by adding, inspecting, changing, and removing object labels, then using them to select pods.
How it connects
Connects labels to namespaces, annotations, label selectors, Services, and nodes.

Also explained in

Compare how 7 books explain label →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.