Skip to content

Instantly share code, notes, and snippets.

@lindhe
Last active February 18, 2026 09:14
Show Gist options
  • Select an option

  • Save lindhe/e71e5a23e66a5a6abfe5866282de11a6 to your computer and use it in GitHub Desktop.

Select an option

Save lindhe/e71e5a23e66a5a6abfe5866282de11a6 to your computer and use it in GitHub Desktop.
Working with Kubernetes' recommended labels

Working with Kubernetes' recommended labels

Among Kubernetes' well-known labels, a subset of them are considered recommended. I have repeatedly tried to figure out what a good structure is, often when deploying resources in Kubernetes or when writing new manifests from scratch. But I frequently change my mind regarding what the right choices are and I am easily mislead by existing misguided choices.

This document is my attempt at finding a reasonable structure, hopefully easy to work with and flexible when it needs to be. I'm writing this publicly to force myself to be structured and think. You may or may not find this useful.

Goals

  • The selectors in a Service or Deployment must match all relevant pods but no other pods.
  • The labels should be useful when grouping resources, for example with kubectl get pods -l foo=bar or when using observability tools like the LGTM stack.
  • It should make sense in the context of a Helm chart.
  • It should make sense in the context of plain manifests (or Kustomize).
  • Labels should be unique but not overspecified.
  • Fewer labels are better than more labels.
  • People used to Kubernetes' set of recommended labels should recognize the structure.

Sturcture

TODO

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment