Use Kubernetes-recommended labels for airflow helm chart

Description

Kubernetes offers a list of recommended labels for grouping resource objects. The prefix app.kubernetes.io differentiates these recommended labels from custom labels.

Why is it needed?
Enhancing readability and maintainability

References
https://helm.sh/docs/chart_best_practices/labels/#standard-labels
https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels

Use case/motivation

airflow/chart/templates/webserver/webserver-deployment.yaml

Lines 36 to 40 in 913eff6

    
           tier: airflow 
        
           component: webserver 
        
           release: {{ .Release.Name }} 
        
           chart: "{{ .Chart.Name }}-{{ .Chart.Version }}" 
        
           heritage: {{ .Release.Service }}

The above labels would be changed as follows:

app.kubernetes.io/part-of: airflow
app.kubernetes.io/component: webserver
app.kubernetes.io/instance: {{ .Release.Name }}
helm.sh/chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
app.kubernetes.io/managed-by: {{ .Release.Service }}

Related issues

No response

Are you willing to submit a PR?

Yes I am willing to submit a PR!

Code of Conduct

I agree to follow this project's Code of Conduct

I'd be for it. Not sure where the original tier/component etc. came from but the standard labels seem to be also useful for any tools that understand them and visualise things better.

Are there are any disadvantages backwards/compatibility issues we see with replacing those labels rather than adding new labels to the existing ones - effectively duplicating them?

@jedcunningham

cc: @jedcunningham @ephraimbuddy @dstandish

Happy to take this up. Could you assign this issue to me ? Thanks

@Owen-CH-Leung

@Owen-CH-Leung

If you'd like to take this up, all you have to do is creating a PR and link to this issue!

Thanks!

@Owen-CH-Leung

@Owen-CH-Leung assigned to you

@Owen-CH-Leung

@Owen-CH-Leung We are unassigning you from this issue as part of our updated assignment policy.

This is not meant to discourage your contribution — quite the opposite! You are still very welcome to work on this issue and submit a PR for it. Simply comment that you are working on it and open a PR when ready.

We found that formal assignments were not working well, as they often prevented others from contributing when the assignee was not actively working on the issue.

@mihirduvedi

I would like to take the design and implementation follow-up for this issue. I rechecked current main, this issue's timeline, and open PRs: #34048 is now in the Airflow Helm Chart 2.0.0 milestone, the chart itself is at 2.0.0, and I found no open PR implementing the recommended-label migration.

I did find #70205, which is actively changing object-versus-pod label plumbing on the same workload templates. Its goal is distinct from this issue, but I would sequence this work after or around that PR rather than duplicate or conflict with its labels/podLabels changes.

Before editing the chart-wide label surface, could a maintainer confirm which compatibility direction is intended for Chart 2.0?

Additive migration: add the five labels shown in the issue (app.kubernetes.io/part-of, app.kubernetes.io/component, app.kubernetes.io/instance, helm.sh/chart, and app.kubernetes.io/managed-by) while retaining the legacy labels and all current selector keys.
Replacement migration: replace the corresponding legacy labels and migrate workload, Service, PDB, NetworkPolicy, and affinity selectors as a Chart 2.0 breaking change.

There is one smaller scope question as well. The issue's example lists five labels and omits app.kubernetes.io/name and app.kubernetes.io/version. A closed 2023 attempt discussed adding name with distinct values for Airflow, Redis, PgBouncer, StatsD, and OTel, but that discussion never received a submitted maintainer review. Should this implementation include app.kubernetes.io/name, or follow the five-label example exactly? I would omit version in either case because the chart includes independently versioned applications and a single .Chart.AppVersion would be misleading for all of them.

My preference is the additive option. It gives tools the standard labels without changing immutable workload selectors or existing user queries. The implementation plan would be:

centralize the standard metadata and pod-label fragments, with label-specific 63-character handling and + to _ normalization for helm.sh/chart;
apply the five issue-specified labels to all chart-owned object metadata, and the applicable part-of/component/instance labels to generated pod templates and chart/files/pod-template-file.kubernetes-helm-yaml;
keep any approved name mapping and all component mappings explicit for Airflow, Redis, PgBouncer, StatsD, and OTel resources, and leave the external app: keda-operator selector untouched;
preserve existing user-label precedence and coordinate the merge semantics with Allow separate object and pod labels for chart components #70205;
add exhaustive rendered-object, job-template, KubernetesExecutor pod-template, long-name, normalization, selector-preservation, and override-precedence tests.

I have completed the current resource/selector inventory and have a clean baseline of 658 passing airflow_aux Helm tests. Is the additive direction welcome, and should implementation be based after #70205 lands?

Drafted-by: Codex (GPT-5); reviewed by @mihirduvedi before posting

I would like to take the design and implementation follow-up for this issue. I rechecked current main, this issue's timeline, and open PRs: #34048 is now in the Airflow Helm Chart 2.0.0 milestone, the chart itself is at 2.0.0, and I found no open PR implementing the recommended-label migration.

Unneeded restatement of the current state of things.

I did find #70205, which is actively changing object-versus-pod label plumbing on the same workload templates. Its goal is distinct from this issue, but I would sequence this work after or around that PR rather than duplicate or conflict with its labels/podLabels changes.

Unrelated.

And to the rest - it depends. You can just create a PR with your proposal.

For the future, please review what the agent wrote in more detail.

Navigation Menu

Repository navigation

Use Kubernetes-recommended labels for airflow helm chart #34048

Description

Use case/motivation

Related issues

Are you willing to submit a PR?

Code of Conduct

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	tier: airflow
	component: webserver
	release: {{ .Release.Name }}
	chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
	heritage: {{ .Release.Service }}

Use Kubernetes-recommended labels for airflow helm chart #34048

Description

Description

Use case/motivation

Related issues

Are you willing to submit a PR?

Code of Conduct

Activity

potiuk commented on Sep 3, 2023

potiuk commented on Sep 3, 2023

Owen-CH-Leung commented on Sep 18, 2023

kimminw00 commented on Sep 24, 2023

eladkal commented on Sep 24, 2023

potiuk commented on Mar 2, 2026

mihirduvedi commented on Aug 5, 2026

Miretpl commented on Aug 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions