commonLabels applied to podAffinity labelSelector.matchLabels

[mshkrebtan]

I want to run an application (masterdata) on a host where Memcached is already running, hence I specify Affinity in the PodSpec.

I use kustomize version 3.1.0:

$ kustomize version
Version: {KustomizeVersion:3.1.0 GitCommit:95f3303493fdea243ae83b767978092396169baf BuildDate:2019-07-26T19:21:45+01:00 GoOs:darwin GoArch:amd64}

I build a configuration out of the following files:

kustomization.yaml:

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

commonLabels:
  app: common-label

resources:
 - deployment.yaml

deployment.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: masterdata
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchLabels:
                  app: memcached
              topologyKey: kubernetes.io/hostname
      containers:

When I run kustomize build, I get the following:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: common-label
  name: deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: common-label
  template:
    metadata:
      labels:
        app: common-label
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: common-label
            topologyKey: kubernetes.io/hostname
      containers:

Pay attention to the matchLabels map in the affinity block. It was altered by Kustomize.

So, as a workaround, I have to use the matchExpressions array in the labelSelector:

      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - memcached
              topologyKey: kubernetes.io/hostname

Then I get the output I need

$ kustomize build
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: common-label
  name: deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: common-label
  template:
    metadata:
      labels:
        app: common-label
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - memcached
            topologyKey: kubernetes.io/hostname
      containers:

In the docs here it's said:

commonLabels will also be applied both to Label Selector fields and Label fields in PodTemplates.

As seen now, it also affects affinity rules in a PodTemplate. So, is this a bug or a feature?

[litaxc]

just ran into the same situation

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[dan-j]

/remove-lifecycle rotten

[icoloma]

Can we agree that commonLabels should not affect matchLabels in general? I have the same issue with a Deployment, where I don't want a generic configuration overwriting matchLabels. That's scaling information for my ReplicaSet, not labeling information to extend. This issue has been reported in multiple places already.

[michaelkrupp]

It appears that maintainers are not paying any attention to this issue at all.

This bug has been repeatedly reported over the last 6 months now, with every single issue going rotten without any clear statement from any maintainer.

What are we supposed to do? Just sit there and wait for another year until we maybe get a reply? I'd happily implement the required changes, but I am not going to waste my time if we cannot even get a reply from anyone able to give us a direction here.

It's sad, but I think it's time to move on. There are enough alternatives out there.

(sorry for the rant, but this is really frustrating by now)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[Shell32-Natsu]

#2034 (comment)

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.