[FEATURE] add a managed-by label to CRD

[ajaysundark]

Is your feature request related to a problem or existing issue? Please describe.

In a managed provider environment, the control-plane is hosted and node-readiness-controller if installed is invisible to the user. so controller itself is not visible to the end-users risking duplicate installation and two controllers competing to manage taints. Add guardrails / visibility into protecting this scenario.

Describe the solution you'd like

1. One simplest way to handle this to stamp our artifacts with a 'managed-by' label, ref: https://kubernetes.io/docs/reference/labels-annotations-taints/#app-kubernetes-io-managed-by.

And add clear documentation about it. A provider setup could handle this with a managed-by:<provider> label.

2. It should be added to CRD because it will be visible to any NRC install flows and available across namespaces.

3. Add a helm pre-install hook or similar so the chart installation will detect existing CRD and fail with guidance

Describe alternatives you've considered

1. implement a validation check in the controller itself as a start blocker, but the discovery is complicated and may require additional permissions
2. provide additional exclusive tooling for detecting if a controller exists

[ajaysundark]

overriding this as it's related - additionally we should review other recommended labels: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/#labels.

We already set some of them here:

node-readiness-controller/charts/node-readiness-controller/templates/_helpers.tpl

Lines 42 to 65 in e259c3f

	{{/*
	Common labels
	*/}}
	{{- define "node-readiness-controller.labels" -}}
	app.kubernetes.io/name: {{ include "node-readiness-controller.name" . }}
	helm.sh/chart: {{ include "node-readiness-controller.chart" . }}
	app.kubernetes.io/instance: {{ .Release.Name }}
	{{- if .Chart.AppVersion }}
	app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
	{{- end }}
	app.kubernetes.io/managed-by: {{ .Release.Service }}
	{{- if .Values.commonLabels}}
	{{ toYaml .Values.commonLabels }}
	{{- end }}
	{{- end -}}
	{{/*
	Selector labels
	*/}}
	{{- define "node-readiness-controller.selectorLabels" -}}
	app.kubernetes.io/name: {{ include "node-readiness-controller.name" . }}
	app.kubernetes.io/instance: {{ .Release.Name }}
	control-plane: controller-manager
	{{- end -}}

[yindia]

/assign @yindia

[yindia]

@ajaysundark Had a look at the approach.

For (1) and (2), controller-gen can stamp the CRD directly with +kubebuilder:metadata:labels=..., and that flows into config/crd/bases and dist/crds.yaml. verify-chart-drift.sh catches the chart's copy going stale, so it has to be synced alongside.

Worth knowing the label can't extend past the CRD: Helm 3 forcibly stamps app.kubernetes.io/managed-by: Helm on everything it owns, so a chart rendering node-readiness-controller ends up storing Helm in the cluster. The CRD is unaffected, since crds/ isn't templated.

For (3), lookup + fail in a template looks better than a pre-install hook. No ServiceAccount, ClusterRole or image needed, and it aborts before anything is applied. I'd key it on .Release.IsInstall plus CRD existence rather than the label value, so it still catches the case where nobody has overridden anything. Upgrades skip it naturally. One false positive to document: install → uninstall → reinstall, since Helm doesn't remove crds/ on uninstall.

One addition worth considering. The Helm guard only covers the Helm path. kubectl apply, Kustomize and the static-pod option all walk past it, and Helm isn't one of the three install options in our docs, so the recommended path is the unprotected one.

A startup check reading the CRD label and warning on mismatch would close that. I know alternative (1) rules this out as "discovery is complicated", but that reads as being about discovering other deployments; this is one get on one object by name. Worth reconsidering, or still a no?