Add labels field to kustomization

[Shell32-Natsu]

close #1009

ALLOW_MODULE_SPAN

[Shell32-Natsu]

/retest

[monopole]

Consider returning an error if labels collide.

Also, should probably add a note as to why this isn't done in PostUnmarshalling (because the edit commands only work with commonLabels, not labels`).

[Shell32-Natsu]

Added the check

[monopole]

/lgtm
thanks!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: monopole, Shell32-Natsu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Shell32-Natsu,monopole]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ChristianCiach]

This seems to be buggy with Kustomize 4.1.2, or I do not understand this correctly.

It seems like it makes no difference weather I specify includeSelectors as true or false.

This is part of my kustomization:

labels:
  - pairs:
      app.kubernetes.io/name: 'foo'
    includeSelectors: false
  - pairs:
      app.kubernetes.io/version: 'bar'
    includeSelectors: true

My service.yaml, which doesn't specify any selectors at all...:

apiVersion: v1
kind: Service
metadata:
  name: dashboard
spec:
  ports:
    - port: 8080
      name: frontend
    - port: 8100
      name: backend

... still receives both labels as selectors after building with Kustomize:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: foo
    app.kubernetes.io/version: bar
  name: dashboard
spec:
  ports:
  - name: frontend
    port: 8080
  - name: backend
    port: 8100
  selector:
    app.kubernetes.io/name: foo
    app.kubernetes.io/version: bar

[Shell32-Natsu]

@ChristianCiach Please file an issue for it or a PR to add a test case.

[ChristianCiach]

I am hesitant to file an issue, because I am not sure if...

• this is actually an issue or a misunderstanding of the feature.
• this feature is already available in 4.1.2, because it isn't advertised or documented anywhere.

If you confirm that this does indeed look like an issue (and it is supposed to work in 4.1.2), then I will file an issue.

[ChristianCiach]

This looks like a bug, because with a minimal example it works like expected. Give me some time to check out what part of my kustomization makes this issue appear, then I will file a bug :)

[Shell32-Natsu]

Yes it looks like a bug. A good approach (and it's what we recommend) is creating a PR and add a test case for this situation in api/krusty.

[ChristianCiach]

Thanks for the pointer. Unfortunately, creating a PR is not so easy for me, because I am a professional Java programmer with almost no experience in Go :)

Please accept my issue posted as YAML examples. I am working on it. Thanks again for your quick reply!

[ChristianCiach]

So, turns out this is (probably) not an issue, just a little pitfall.

In my base-kustomization I have this:

commonLabels:
  app.kubernetes.io/name: 'dashboard'

In my overlay I have this:

labels:
  - pairs:
      app.kubernetes.io/name: 'foo'
    includeSelectors: false
  - pairs:
      app.kubernetes.io/version: 'bar'
    includeSelectors: true

The result is as shown above:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: foo
    app.kubernetes.io/version: bar
  name: dashboard
spec:
  ports:
  - name: frontend
    port: 8080
  - name: backend
    port: 8100
  selector:
    app.kubernetes.io/name: foo
    app.kubernetes.io/version: bar

So, app.kubernetes.io/name: 'foo' is used as a selector even though I specified includeSelectors: false, because the key app.kubernetes.io/name has been defined as commonLabels in the base.

This is probably working as expected, so I will not file an issue.