Define labels selector with crds

[gaetanars]

Eschewed features

• [X] This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

When we use CRDs in our base, if we add some labels selectors in our kustomization overlay, with includeSelectors: true, this labels is not reported to the CRDs selector.

For example : base/test/podmonitor.yaml :

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: pm
spec:
  jobLabel: app.kubernetes.io/name
  podMetricsEndpoints:
    - path: /my/metrics/path
      port: metrics

PodMonitor use selector like spec/selector/matchLabels to target pod that need to be scraper

overlays/test/kustomization.yaml :

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

namespace: mynamespace

namePrefix: myprefix-

labels:
  - includeSelectors: true
    pairs:
      app.kubernetes.io/name: myname

resources:
  - ../../base/test/podmonitor.yaml

If we build this, my app.kubernetes.io/name: myname label is not put in PodMonitor spec/selector/matchLabels, we need to find a way to configure Kustomize that this is a selector.

The documentation about transformerconfig use commonLabels to achieve this, but commonLabels is deprecated, and I have not find the same things with labels.

An another way to achieve that is to add fields block in all our overlay like this :

labels:
  - includeSelectors: true
    pairs:
      app.kubernetes.io/name: myname
   fields:
      - kind: PodMonitor
        path: spec/selector/matchLabels
        create: true

But this way is to tedious.

Why is this needed?

We must find a way to configure Kustomize to use labels selector with CRDs.

Can you accomplish the motivating task without this feature, and if so, how?

Use of fields in overlay is to tedious

What other solutions have you considered?

Like in description :

• commonLabels : but is it deprecated
• fields in all our overlays : but is it tedious

Anything else we should know?

No response

Feature ownership

• [ ] I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mvanini]

Hi @gaetanars, I've just tested with the transformerconfig you mentioned and it's working, even if you use labels instead of commonLabels which is deprecated as you mention.

In our case we want to add pod selector to a CRD (CiliumNetworkPolicy) and we created a transformerconfig.yaml like this:

commonLabels:
- path: spec/endpointSelectors/matchLabels
  create: true
  kind: CiliumNetworkPolicy

then in the kustomization of the overlay:

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

resources:
  - ../base
  - network-policy.yaml

configurations:
  - config.yaml

labels:
  - pairs:
      my.custom.label: value1
      my.other.custom.label: value2
    includeSelectors: true
  - pairs:
      non-selector.custom.label: whatever
    includeSelectors: false
    includeTemplates: true

The resulting stream (truncated) is with desired custom labels:

[...]
---
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  labels:
    non-selector.custom.label: whatever
    my.custom.label: value1
    my.other.custom.label: value2
  name: console-pog-cnp
  namespace: pog-dev
spec:
  endpointSelectors:
    matchLabels:
      my.custom.label: value1
      my.other.custom.label: value2
[...]

For commodity we have put the transformerconfig in a component centralized, already referenced by all overlays so you don't have to add configurations section in all kustomization.yaml.

Hope this helps ;)