7.6 Kubernetes Recommended Labels

Kubernetes Recommended Labels is the specific, project-defined set of shared label keys, all under the app.kubernetes.io prefix, that Kubernetes suggests applying consistently to objects representing an application, giving tools, dashboards, and operators across the ecosystem a common vocabulary for identifying an application, its components, and the tooling responsible for managing it.

app.kubernetes.io/name

The Application's Generic Name

This label identifies the name of the application itself, such as mysql or wordpress, intended to reflect what the application fundamentally is rather than any particular deployment of it, making it useful for selecting all objects belonging to a given kind of application across potentially many separate installations.

app.kubernetes.io/instance

A Unique Identifier for This Deployment

While name identifies the application generically, instance distinguishes a specific installation of that application from any other, such as wordpress-abcxyz, which matters when multiple independent instances of the same application, for example separate WordPress sites, coexist within the same cluster or namespace.

app.kubernetes.io/version

The Application's Current Version

This label records the current version of the application, using whatever versioning scheme the application itself follows, such as a semantic version string or a Git commit-derived identifier, distinct from app.kubernetes.io/managed-by's own versioning, which refers to the managing tool rather than the application.

app.kubernetes.io/component

The Object's Role Within the Application

This label identifies the specific architectural role a given object plays within its larger application, such as database, frontend, or cache, useful for selecting or reasoning about a specific tier of a multi-component application independently of the application as a whole.

app.kubernetes.io/part-of

The Higher-Level Application This Belongs To

This label names the higher-level application that a given component is part of, useful when a single logical application is actually composed of several independently deployed objects, each labeled with its own name and component, but sharing a common part-of value tying them together as belonging to the same overall system.

app.kubernetes.io/managed-by

The Tool Responsible for Management

This label identifies the tool used to manage the object's lifecycle, such as helm or kustomize, distinguishing objects actively managed by an automated tool from those hand-authored or managed through some other process, which is useful both for understanding provenance and for tools themselves to avoid interfering with objects managed by a different tool.

app.kubernetes.io/created-by

Optional Provenance for the Creating Controller

Less universally applied than the others, this label can identify the specific controller or operator that created the object, useful in more complex operator-driven environments where distinguishing which specific automated actor created a given object adds diagnostic value beyond what managed-by alone conveys.

Applying the Full Set Together

A Worked Example

A WordPress Deployment might carry app.kubernetes.io/name: wordpress, app.kubernetes.io/instance: wordpress-prod, app.kubernetes.io/version: 6.4.1, app.kubernetes.io/component: frontend, app.kubernetes.io/part-of: wordpress, and app.kubernetes.io/managed-by: helm, together giving a complete, standardized picture of what the object is, which installation it belongs to, its version, its architectural role, the larger system it's part of, and how it's managed.

Not Every Label Is Always Applicable

Simpler applications with only a single component may find some of these labels, particularly component and part-of, add little value beyond what name alone already conveys, and omitting them in genuinely simple cases is a reasonable, pragmatic choice rather than a violation of the convention's intent.

Adoption Across the Ecosystem

Widely Recognized by Tooling

Because these labels are defined by the Kubernetes project itself rather than any single vendor, a growing body of dashboards, cost-attribution tools, and Helm charts across the ecosystem recognize and build functionality around them, making their adoption a low-cost way to gain compatibility with tooling an organization did not have to build itself.