Ingress serviceSelector

[cmluciano]

redirecting kubernetes/kubernetes#17686

currently a service for an ingress-backend can only be selected by service-name (see https://github.com/kubernetes/kubernetes/blob/ba383bc/pkg/apis/extensions/v1beta1/types.go#L588-L595)

would it be possible to support service-selection by using a label-selector (similar to service.spec.selector)?

currently i have to write long descriptive service-names like that:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: projectX
spec:
  rules:
    - host: projectX.com
      http:
        paths:
          - path: /
            backend:
              serviceName: projectX-production-webFrontend
              servicePort: 80

i would like to do something like that:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: projectX
spec:
  rules:
    - host: projectX.com
      http:
        paths:
          - path: /
            backend:
              serviceSelector: 
                project: X
                environment: production
                component: webFrontend
              servicePort: 80

[aledbf]

@cmluciano that is not supported in the Ingress spec (this requires a change in core)

[pieterlange]

That also sounds a little bit convoluted... why aren't you using namespaces for this @cmluciano ?

[cmluciano]

I should have been a bit more clear when opening this. I am just transplanting kubernetes/kubernetes#17686 from the k8s/k8s repository. The origin author was @guybrush .

[guybrush]

The original issue is quite old, but still i think it would be a good idea. According to the docs namespaces should be used to divide cluster resources - which is kind of vague imho (since everything is basically a resource).

At least after using k8s on local-play-clusters it felt natural to me to use labels for targeting ingress-backends, and i was surprised it did not work that way. But it is not a feature i need for anything production (yet :D) - so feel free to close the issue!

[cmluciano]

@aledbf @nicksardo thoughts ^

[pieterlange]

I think the functionality described is perfectly served by the normal Service resource types. Project & lifecycle (production/test) namespacing can happen in the cluster functionality designed for it (namespaces!)

As an operator, this type of functionality (and API change) would just serve as another layer of confusion where pod selection might happen.

edit: if i'm completely mistaken here, i'd like to hear from people running different projects & product lifecycle stages in a single namespace and why they chose to structure it that way.

[aledbf]

As @pieterlange pointed a Service is the correct abstraction to use in Ingress.
We should not create a custom abstraction that do not behaves like a service (using a service must be equals to use ingress to reach a pod).

This is just my personal opinion.

[nicksardo]

I agree with the strong points dictated by @pieterlange and @aleb.