Skip to content

Adopt the Kubernetes recommended labels: new installs use only them, older releases keep theirs - #203

Merged
wu-sheng merged 1 commit into
masterfrom
modernize-labels
Oct 13, 2026
Merged

wu-sheng merged 1 commit into
masterfrom
modernize-labels

Conversation

@wu-sheng

@wu-sheng wu-sheng commented Oct 13, 2026 •

Copy link
Copy Markdown
Member

Resolves the chart half of apache/skywalking#12296. The BanyanDB chart moved to the recommended labels in its 0.3 release.

Changed since the earlier approvals: a release installed with 5.1.0 or later now carries only the recommended labels and selects by them everywhere. The earlier revision kept the old labels on new installs too.

What changes

A release's labels depend on when it was first installed, because a Deployment's selector can never change after creation:

Installed with 5.1.0 or later Installed before 5.1.0
Labels on resources and pods The Kubernetes recommended labels only app, release, component, chart, heritage, plus the recommended labels
Deployment, Service and anti-affinity selectors Recommended labels app, release, component
OAP cluster discovery and dynamic config (SW_CLUSTER_K8S_LABEL), Satellite's OAP lookup Recommended labels app, release, component
Init Job's pod labels Recommended labels Unchanged from 5.0.0
  • The recommended labels are app.kubernetes.io/name (always the chart name, not nameOverride, because it is part of an immutable selector), app.kubernetes.io/instance, app.kubernetes.io/component, app.kubernetes.io/managed-by and helm.sh/chart. All label values are quoted and valid: the chart version is sanitized in both chart labels (+ becomes _), and component values are capped at 63 characters.
  • The style is release-wide and found with Helm lookup on the release's OAP, UI and Satellite Deployments, so helm upgrade needs no extra step, and a component enabled later follows the release. The new labelStyle value (auto | legacy | modern) overrides it.
  • Moving an older release to the new labels is optional: delete its three Deployments and upgrade.
  • The init Job's name hash leaves labelStyle out and adds the style for a new-style release. An older release hashes exactly what 5.0.0 hashed, so an upgrade with unchanged values relabels its Job in place; a move to the new labels renames the Job instead of patching its immutable pod template.
  • Fix: the Satellite Role and RoleBinding carried OAP's component label.

Docs: the 5.1.0 changelog, a new upgrade-guide section, the values reference, the init Job guide, the e2e guide, and the kubectl commands across the operate, install and troubleshooting pages. Those read the current init Job from the release's rendered manifest (helm get manifest; helm template | kubectl apply users run the same awk over their own render) and reach the pods through their Deployment's own selector, so they work for any chart version, either label style, and releases sharing a namespace.

Breaking changes

  • A release installed with 5.1.0 or later has no app, release, component, chart or heritage label. Selectors of your own (kubectl -l, NetworkPolicies, monitors) must use app.kubernetes.io/* for it.
  • lookup returns nothing when the chart is rendered without cluster access (helm template | kubectl apply, Argo CD, --dry-run=client). Such a setup must set labelStyle: legacy for a release installed before 5.1.0, or the Services switch to labels the running pods lack and OAP and the UI become unreachable until it is set. helm upgrade needs nothing.

Tests

New e2e coverage: e2e-upgrade.yaml installs the published 5.0.0 chart, upgrades it to the working tree with identical values and again setting only labelStyle, and checks the kept selectors, the relabelled pods, the init Job, and that a Job keeping its name keeps its pod template (rendered from 5.0.0 and the working tree for BanyanDB, Elasticsearch and PostgreSQL). It waits with kubectl, since Helm 3's --wait never ends on kind with the BanyanDB subchart's LoadBalancer Service. e2e-config-override.yaml checks that a fresh install carries only the recommended labels and selects by them.

Run locally on kind with Helm 3.22.0 (CI's major version), OAP from GHCR master with 2 replicas, Horizon 1.0.0, dynamic config enabled:

Scenario BanyanDB + Satellite Elasticsearch (ECK) PostgreSQL (external)
5.0.0 → this branch: old labels and selectors kept pass pass pass
… then moved to the new labels (Deployments deleted, upgrade) pass pass pass
Fresh install, then an upgrade that rolls OAP: new labels only pass pass pass

Every scenario checks the Deployment and Service selectors, pod labels, Service endpoints, that nothing is labelled release= on a new-style release, the SW_CLUSTER_K8S_LABEL value and that it matches the dynamic-config ConfigMap, OAP cluster membership (both nodes), Horizon login and OAP reachability, the init Job, and Satellite's discovered OAP addresses.

  • The upgrade cell's setup and all six queries, run verbatim with Helm 3, including the real helm pull of 5.0.0.
  • Object-level, with Helm 3 and Helm 4: helm template | kubectl apply on an older release (with labelStyle: legacy: no errors; without it: the documented Deployment rejections), Satellite enabled later on an older and on a new release, and helm rollback after a move.
  • The docs' kubectl commands, extracted verbatim, against: this branch with a second release in the namespace, chart 5.0.0, 5.0.0 upgraded to this branch, values A → B → A through Helm and through helm template | kubectl apply (stale Jobs left behind), and a release whose OAP Deployment name exceeds 40 characters.
  • Render checks: an older release renders exactly 5.0.0's objects plus the new labels, with the init Job's name and pod template unchanged; a new release renders no Helm 2 label or selector anywhere.
  • Reviewed with GPT-6 (Codex) at ultra effort, given these test results; its findings are addressed.

Found while testing, not changed here

  • With Helm 4, helm upgrade of an Elasticsearch-backed release fails even from 5.0.0 to 5.0.0: Helm's server-side apply conflicts with the ECK operator on the Elasticsearch resource's .spec.nodeSets. --server-side=false works.
  • The bundled PostgreSQL image, docker.io/bitnami/postgresql:15.1.0-debian-11-r0, is gone from Docker Hub's bitnami namespace and now lives under bitnamilegacy, so postgresql.enabled=true cannot pull it.
  • Outside this repo, OAP's runtime-rule cluster e2e (OAP_SELECTOR default) and two OAP docs pages select this chart's pods by the old labels; they need the recommended labels once they move to a 5.1.0 chart.

🤖 Generated with Claude Code

@wu-sheng wu-sheng added this to the 5.1.0 milestone Oct 13, 2026
@wu-sheng
wu-sheng requested a review from kezhenxu94 October 13, 2026 05:49
@wu-sheng wu-sheng added the enhancement New feature or request label Oct 13, 2026
@wu-sheng
wu-sheng requested a balanced review from Copilot October 13, 2026 05:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

Selector auto-detection can still mutate modern selectors, and the upgrade test leaves a key immutable-Job path unverified.

3 open findings
What changed in this PR

Adds Kubernetes-recommended labels while preserving upgrade compatibility for immutable Deployment selectors.

Changes:

  • Centralizes legacy and modern label helpers with automatic selector detection.
  • Adds upgrade and fresh-install E2E coverage.
  • Documents selector migration and render-only deployment requirements.
File Description
.github/​workflows/​e2e.ci.yaml Adds the upgrade E2E cell.
chart/​skywalking/​values.yaml Adds deploymentSelector.
chart/​skywalking/​templates/​_helpers.tpl Implements shared labels and selector detection.
chart/​skywalking/​templates/​oap-clusterrole.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-clusterrolebinding.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-cm-dynamic.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-cm-override.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-deployment.yaml Adds dual pod labels and adaptive selectors.
chart/​skywalking/​templates/​oap-init.job.yaml Labels the Job and excludes selector mode from its hash.
chart/​skywalking/​templates/​oap-role.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-rolebinding.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-serviceaccount.yaml Applies shared OAP labels.
chart/​skywalking/​templates/​oap-svc.yaml Applies shared labels while retaining legacy selection.
chart/​skywalking/​templates/​satellite-cm-override.yaml Applies shared Satellite labels.
chart/​skywalking/​templates/​satellite-deployment.yaml Adds dual pod labels and adaptive selectors.
chart/​skywalking/​templates/​satellite-role.yaml Corrects and modernizes component labels.
chart/​skywalking/​templates/​satellite-rolebinding.yaml Corrects and modernizes component labels.
chart/​skywalking/​templates/​satellite-serviceaccount.yaml Applies shared Satellite labels.
chart/​skywalking/​templates/​satellite-svc.yaml Retains legacy Service selection.
chart/​skywalking/​templates/​ui-configmap.yaml Applies shared UI labels.
chart/​skywalking/​templates/​ui-deployment.yaml Adds dual pod labels and adaptive selectors.
chart/​skywalking/​templates/​ui-ingress.yaml Applies shared UI labels.
chart/​skywalking/​templates/​ui-pvc.yaml Applies shared UI labels.
chart/​skywalking/​templates/​ui-svc.yaml Retains legacy Service selection.
docs/​changes/​changes.md Records labels, selectors, and compatibility notes.
docs/​contributing/​e2e-tests.md Documents the expanded E2E suite.
docs/​reference/​skywalking-chart-values.md Documents the new value.
docs/​upgrade/​upgrading.md Adds selector upgrade and migration guidance.
test/​e2e/​e2e-config-override.yaml Verifies modern selectors on fresh installs.
test/​e2e/​e2e-upgrade.yaml Exercises upgrades from chart 5.0.0.
test/​e2e/​expected/​fresh-selectors.yml Defines expected modern selectors.
test/​e2e/​expected/​upgrade-init-job.yml Defines init Job upgrade expectations.
test/​e2e/​expected/​upgrade-pods-relabelled.yml Defines expected pod components.
test/​e2e/​expected/​upgrade-selectors.yml Defines expected preserved legacy selectors.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread chart/skywalking/templates/_helpers.tpl Outdated
Comment thread test/e2e/e2e-upgrade.yaml Outdated
Comment thread chart/skywalking/templates/oap-init.job.yaml Outdated
@wu-sheng
wu-sheng force-pushed the modernize-labels branch 2 times, most recently from 94c7c29 to e88c56c Compare October 13, 2026 08:00
@wu-sheng wu-sheng changed the title Add the Kubernetes recommended labels, and select by them on new installs Adopt the Kubernetes recommended labels: new installs use only them, older releases keep theirs Oct 13, 2026
@wu-sheng
wu-sheng force-pushed the modernize-labels branch 3 times, most recently from 3e51a24 to bd6798e Compare October 13, 2026 08:27
@wu-sheng
wu-sheng requested a balanced review from Copilot October 13, 2026 08:35

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warning

Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.

Copilot review overview

5 open findings

🧠 Review effort: Lite

Comment thread chart/skywalking/templates/_helpers.tpl Outdated
Comment thread chart/skywalking/templates/oap-init.job.yaml
…older releases keep theirs

Resolves the chart half of apache/skywalking#12296; the BanyanDB chart moved in 0.3.

A release installed with 5.1.0 or later carries only the Kubernetes recommended labels:
app.kubernetes.io/name (always the chart name, never nameOverride), app.kubernetes.io/instance,
app.kubernetes.io/component, app.kubernetes.io/managed-by and helm.sh/chart. Every selector uses
them: the Deployments, the Services, pod anti-affinity, OAP cluster discovery and dynamic
configuration (SW_CLUSTER_K8S_LABEL), Satellite's OAP lookup, and the init Job's pod.

A release installed before 5.1.0 keeps its app/release/component/chart/heritage labels and its
selectors on them, because a Deployment's selector is immutable, and gains the recommended labels
next to them. The style is release-wide: skywalking.labelStyle looks up the release's OAP, UI and
Satellite Deployments, so `helm upgrade` needs no extra step, and a component enabled later follows
the release. `lookup` sees nothing without cluster access, so the new `labelStyle` value
(auto | legacy | modern) lets render-only setups keep an older release on the legacy style. Moving
an older release to the new labels is optional: delete its three Deployments and upgrade.

The init Job's name hash leaves `labelStyle` out and adds the style for a modern release: an older
release hashes exactly what 5.0.0 hashed, so an upgrade with unchanged values relabels its Job in
place, and a move to the new labels renames the Job instead of patching its immutable pod
template. All label values are quoted and valid: the chart version is sanitized in both chart
labels and component values are capped at 63 characters. The Satellite Role and RoleBinding no
longer carry OAP's component label.

Tests: e2e-upgrade.yaml installs the published 5.0.0 chart, upgrades it to the working tree with
identical values and again setting only labelStyle, and checks the kept selectors, the relabelled
pods, the init Job, and that a Job keeping its name keeps its pod template, rendered from 5.0.0 and
the working tree for each backend. It waits with kubectl, since Helm 3's --wait never ends on kind
with the BanyanDB subchart's LoadBalancer Service. e2e-config-override.yaml checks that a fresh
install carries only the recommended labels and selects by them.

Docs: the 5.1.0 changelog, an upgrade-guide section, the values reference, the init Job guide and
the e2e guide. The kubectl commands across the operate, install and troubleshooting pages read the
current init Job from the release's rendered manifest and reach the pods through their Deployment's
own selector, so they work for any chart version, either label style, and releases sharing a
namespace; `helm template | kubectl apply` users run the same awk over their own render.
@wu-sheng
wu-sheng merged commit d6d0344 into master Oct 13, 2026
6 checks passed
@wu-sheng
wu-sheng deleted the modernize-labels branch October 13, 2026 23:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants