kustomize: api group missing from label transformer config for core resources

Describe the bug If you use the commonLabels transformer and a CRD shares the same kind and version, but not the same group the labels are still applied and a given path might not exist.

The big offender is knative. It too uses Service for kind and conflicts with the core resource of the same name since it does not have spec/selector.

Is it possible to add the group here?? I’m not sure if that would be “core” or an empty string (or if the code needs modified to handle an empty string?)

Files that can reproduce the issue

# hello.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: docker.io/hello-world
# kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

commonLabels:
  foo: bar

resources:
  - hello.yaml

Expected output

Actual output

Kustomize version v3.8.4 but master doesn’t have the group specified and I looked in the release notes so I presume it’s still not working.

Platform MacOS and Linux

Additional context

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 15 (8 by maintainers)

Most upvoted comments

To get rid of this issue in knative, I added following patch between my overlays and base.

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

bases:
  - ../base

# This patch is required to remove the label selectors generated by kustomize for core
# "Service" object which are not supported by the knative "Service" object specification.
# More info available here: https://github.com/kubernetes-sigs/kustomize/issues/3414
patches:
  - patch: |-
      - op: remove
        path: /spec/selector
    target:
      group: serving.knative.dev
      version: v1
      kind: Service

The above file/directory references “base” directory as base and is referenced in my overlays as base, creating a 3-level kustomize chain. This works because the knative service objects in base are applied the label transformer first and then fed to child which removes the spec.selector field from them and then pass it to overlays. Kind of hacky but works well. The same patch can be added in overlay’s kustomize files but I added a new level to avoid repetition of same patch in each overlay.

P.S.: In my case the Service objects are all created in base and hence this works. If your service object is created in overlay, you might have to create a layer beneath overlays as putting the patch in same level as that of service object does not work because the LabelTransformer is applied after the PatchTransformer causing the patch to fail altogether.

mukundjalan on Feb 18, 2022

Best I can tell core will not work unless you modify this line to say group = "core" and modify all the builtins to say group: core:

https://github.com/kubernetes-sigs/kustomize/blob/64ffbcb15dd502dfd562bba7324b39c02a483e3c/api/filters/fieldspec/gvk.go#L36

I’d say this is something worth considering, knative is a hugely popular framework and this bug is stopping everyone from using kustomize.

Any thoughts on reopening?

dan-j on Oct 11, 2021