Kustomize: commonLabels adds selector to headless service without selector

Created on 13 Aug 2018  路  17Comments  路  Source: kubernetes-sigs/kustomize

https://kubernetes.io/docs/concepts/services-networking/service/#headless-services

Sometimes you want to specifically create a service without any selectors.

external-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  ports:
    - protocol: TCP
      port: 80
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-service
subsets:
  - addresses:
      - ip: 192.168.60.1
      - ip: 192.168.60.2
    ports:
      - port: 80

kustomization.yaml

commonLabels:
  environment: "staging"

resources:
  - external-service.yaml
~/test % kustomize build .
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    environment: staging
  name: external-service
subsets:
- addresses:
  - ip: 192.168.60.1
  - ip: 192.168.60.2
  ports:
  - port: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    environment: staging
  name: external-service
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    environment: staging

The transformed service has a selector with only the commonLabel effectively making the service backed by every pod.

Most helpful comment

Can we agree this is not a feature? ie: this is a bug.

All 17 comments

A general way to avoid applying a commonLabel to everything is to have the top level kustomization that is just an overlay that specifies multiple bases.

One of the bases has a kustomization that applies a commonLabel to its resources. The other doesn't, and that's where the headless service could sit.

Would that work?

I'm facing the same issue. Is there a reason why setting a commonLabel results in setting service selectors as well as the label for services? Is this a feature or a bug?

Sure, the folder structure along with kustomization.yaml files can be organized to avoid this, but ideally things would work as expected?

In other aspects, the tool does everything I expect it to (and more! eg: hash configmaps and secrets).

Is this a feature or a bug?
I have the same question; I was not expecting 'commonLabels' to add/create a matching selector.
Adding labels and applying a label to selector are two different things in my opinion.

A general way to avoid applying a commonLabel to everything is to have the top level kustomization that is just an overlay that specifies multiple bases.

One of the bases has a kustomization that applies a commonLabel to its resources. The other doesn't, and that's where the headless service could sit.

Would that work?

That's what we have done. Works fine for now.

I must say that I do not find this to be a very clean solution, I would rather have an option to exclude it somehow.

Thanks for the suggestion though

I agree with @mark-visser, the proposed work-around gets very messy. Would it be hard to implement automatic removal of the selector from a Service object when it has a matching Endpoints object (with the same name and namespace)?

For now, I'm using the patch below to remove the selector. For my project, this is far less intrusive than adding several extra overlays.

- op: remove
  path: /spec/selector

Can we agree this is not a feature? ie: this is a bug.

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

I agree with @mark-visser, the proposed work-around gets very messy. Would it be hard to implement automatic removal of the selector from a Service object when it has a matching Endpoints object (with the same name and namespace)?

For now, I'm using the patch below to remove the selector. For my project, this is far less intrusive than adding several extra overlays.

- op: remove
  path: /spec/selector

This workaround breaks in kustomize 3.0.3 when using the new extended patches (i.e. invoking this patch from patches: rather than patchesJson6902:)

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

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

@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.

/reopen

@houz42: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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.

/remove-lifecycle rotten

This bug is absolutely still a problem. Why is a selector affected by commonLabels!?

Alright, since it's hard to figure out from this issue, and Google may land you here, here's the real fix:

Basically, switch from commonLabels to LabelTransformer. Here's an example: https://github.com/onepanelio/manifests/pull/17/files

You'll see it's a separate YAML file, and the YAML file specifies which fieldSpecs get affected. As long as you don't put the path to the selector in there, it shouldn't muck around with your selectors. It's a lot more work than commonLabels but at least it'll solve the issue!

Sorry for the late of response. @NuckChorris Here is the documentation about another method. https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs#labels-transformer

/close

Was this page helpful?
0 / 5 - 0 ratings