support for common labels that don't get set on selectors

[pwittrock]

certain labels such as version shouldn't be propagated to selectors, but are common to the entire app.

[monopole]

@rcomanne in retrospect, we have a flaw in the API and we're stuck with it. We can add fields, but changing the meaning of fields and imposing migration work on users isn't practical

[monopole]

We can, as noted above, do a v2 on the kustomization file. But lets gather up some other changes first, not just the labels change. We also want to deprecate the vars field.

[bluebrown]

I just tested it and it works. Since this pr got merged https://github.com/kubernetes-sigs/kustomize/pull/3743/files

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
labels:
  - includeSelectors: true
    pairs:
      app.kubernetes.io/name: myapp
  - includeSelectors: false
    pairs:
      app.kubernetes.io/verion: v0.1.0

[yassinebelmamoun]

Is there a viable solution available to apply a "common" label to all Kubernetes resources, including templates - such as Deployment labels and the pod template of Deployments - while excluding the application of this label to the Deployment's selectors?

I found the following solution and I believe that it is valuable for other people who would be confronted to the same question:

apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Kustomization

commonLabels:
  my-label: my-value

labels:
  - includeSelectors: false
    includeTemplates: true
    pairs:
      my-changing-label: my-changing-value

Documentation reference: Labels - Official documentation - Kustomize

[jdmulloy]

Ah, since commonLabels directive adds labels to spec.selector.matchLabels, I have to add another patch to remove it.

- op: remove
  path: /spec/selector/matchLabels/<mylabel>
- op: remove
  path: /spec/template/metadata/labels/<mylabel>

And in kustomization.yaml

patchesJson6902:
# this is hacky because of https://github.com/kubernetes-sigs/kustomize/issues/1009
- target:
    group: apps
    version: v1
    kind: Deployment
    name: git-apply
  path: patches/rm-deploy-common-label-in-selector.yaml

Honestly, I don't like the behavior to apply common labels to spec.selector at all, it makes the adoption harder(manage an existing deployment via kustomize) since those fields are immutable which is very annoying.

This doesn't work for me in v5.1.0 if I try to use the new patches because patchesJson6902 is deprecated. The patch works for other labels that aren't added with commonLabels so I'm guessing the new patches are applied before commonLabels.

[nickjj]

I've tried everything listed in this thread unsuccessfully for a specific use case, any suggestions on how to get this working?

I'll start with a brief code sample and then describe the use case.

Code sample

Imagine having this in your kustomization.yaml:

commonLabels:
  app.kubernetes.io/name: "hello-app"

# ...

# This works but I'd like to use `patches` instead.
patchesJson6902:
- path: "patch-deployment-worker-common-labels.yaml"
  target:
    kind: "Deployment"
    name: "worker-app"

Then you have patch-deployment-worker-common-labels.yaml:

---
- op: "replace"
  path: "/metadata/labels/app.kubernetes.io~1name"
  value: "hello-worker-app"
- op: "replace"
  path: "/spec/selector/matchLabels/app.kubernetes.io~1name"
  value: "hello-worker-app"
- op: "replace"
  path: "/spec/template/metadata/labels/app.kubernetes.io~1name"
  value: "hello-worker-app"

Use case

You have the usual K8s configs to deploy a web app (deployment, service, ingress, configmap, job, cronjob, etc.) and you want hello-app to be applied as a label and selector to everything so you use commonLabels. You also have 8 different applications using the same "web" base and each of those 8 app's kustomization.yaml file uses a different commonLabel such as hello-app and world-app.

You have both a web and worker deployment and it's critically important that the worker deployment doesn't have the same label as the web deployment because your load balancer will attach a readiness gate to a deployment that matches a service's selector with the same name so the worker will always fail that check since it's not a web app.

To get around that you patch the common label and selector of the worker. Using patchesJson6902 works fine but trying to change that to patches fails with missing value.

This is stopping me from being able to use inline Kustomize patches with Argo CD for preview environments since it only supports patches. Any thoughts on an alternative strategy?