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.
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
selectorfrom aServiceobject when it has a matchingEndpointsobject (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
Most helpful comment
Can we agree this is not a feature? ie: this is a bug.