In a Helm chart, which built-in objects supply the app.kubernetes.io/instance, managed-by and version label values?

## Who emits what There are two sources of metadata on a Helm-managed object and candidates routinely conflate them. Helm itself stamps ownership metadata on every resource it manages, which includes a `managed-by` label naming Helm. Everything else - the `app.kubernetes.io/name`, `/instance`, `/version` set and the `helm.sh/chart` label - is emitted by the chart's own templates. If the author does not write them, they do not appear. So the interview question is really: for each label a chart is expected to emit, which built-in object holds the value? ## The four values **`app.kubernetes.io/instance` <- `.Release.Name`.** This is the one that makes the label set per-install rather than per-chart. Install the same chart twice into a namespace as `fraud-a` and `fraud-b` and the two sets of objects differ by exactly this label. Using `.Chart.Name` here instead is the classic beginner error: both releases then carry identical labels, and any selector built on them matches the other release's Pods. **`app.kubernetes.io/managed-by` <- `.Release.Service`.** `.Release.Service` is documented as "the service that is rendering the present template", and in practice it always renders the literal string `Helm`. The word *service* here has nothing to do with a Kubernetes Service object - it means the tool doing the render. **`app.kubernetes.io/version` <- `.Chart.AppVersion`.** Note *App*: this is the `appVersion` field of `Chart.yaml`, the version of the software being shipped, not the chart's own `version`. Two details matter. First, `appVersion` is optional, so the emitted block is normally guarded: ```yaml {{- if .Chart.AppVersion }} app.kubernetes.io/version: {{ .Chart.AppVersion | quote }} {{- end }} ``` Without the guard you emit a key with an empty value. Second, the `quote` is not decoration. `Chart.yaml` is YAML, so `appVersion: 1.20` unquoted is parsed as the number 1.2 and renders as `1.2`. Quote it in `Chart.yaml` and pipe it through `quote` in the template. **`app.kubernetes.io/name` <- the chart name**, normally through a small named template that lets a values key such as `nameOverride` replace it and truncates the result. This is the label most often carried into a selector, which is why it must stay stable for the life of a release. ## `helm.sh/chart` is different `helm.sh/chart` is Helm's own namespaced label and it identifies the chart *artefact*, not the app: ``` {{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" }} ``` Every pipe stage earns its place. `.Chart.Version` is a SemVer string and SemVer allows build metadata after a `+` (`2.14.3+build.17`), but a label *value* may not contain `+`, so it is rewritten to `_`. A label value is capped at 63 characters, hence `trunc 63`; truncation can leave a trailing `-`, which is also illegal at the end of a label value, hence `trimSuffix "-"`. Skipping those pipes gives you a chart that installs fine for months and then fails validation the first time someone publishes a build-metadata version or a long chart name. ## Where the values land The full set normally goes on every rendered object's `metadata.labels` and on the Pod template's labels. A Deployment's `spec.selector.matchLabels`, however, takes only the stable subset - `name` and `instance` - because `helm.sh/chart` and `app.kubernetes.io/version` change whenever a version is bumped, and a selector cannot change after install. ## What good looks like A good answer names the built-in for each label without hesitating, distinguishes `.Release.Name` from `.Chart.Name`, distinguishes `.Chart.Version` from `.Chart.AppVersion`, and knows that `.Release.Service` is a fixed string rather than something the caller sets. A very good answer adds that these are chart-authored: rendering the chart with `helm template` shows them, and a chart that omits them produces objects nobody can query by application or by release.