/sig network

/triage unresolved

Comment /remove-triage unresolved when the issue is assessed and confirmed.

🤖 I am a bot run by vllry. 👩‍🔬

/remove-triage unresolved
/assign

On the sig-network meeting 2020-02-20 a work-around using a webhook was mentioned. I have a simpler work-around that may be tested; Define the service without a selector then no endpoints will be assigned by kubernetes. Then add the selector as an annotation so your custom endpoint controller can set the endpoints in it's own way. Example;

apiVersion: v1
kind: Service
metadata:
  name: mconnect
  labels:
    service.kubernetes.io/service-proxy-name: my-lb-setup
  annotations:
    example.com/selector: mconnect
spec:
  ipFamily: IPv4
  ports:
  - port: 5001

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

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.

@s1061123 As discussed on the network-plumbing meeting:

If the proposal in this issue was implemented a Multus service would look something like;

apiVersion: v1
kind: Service
metadata:
  name: multus-service
  labels:
    service.kubernetes.io/service-proxy-name: multus-proxy
    service.kubernetes.io/endpoint-controller-name: multus-endpoint-controller
  annotations:
    multus.kubernetes.io/network: macvlan         # (forgot the name of this in the presentation)
spec:
  selector:
    app: multus-app
  ports:
  - port: 6000

I.e, you already would have 2 labels and 1 annotation making this a special (but clearly understandable) service.

What I propose is that you skip the selector altogether and replace it with an annotation, like:

apiVersion: v1
kind: Service
metadata:
  name: multus-service
  labels:
    service.kubernetes.io/service-proxy-name: multus-proxy
  annotations:
    multus.kubernetes.io/network: macvlan         # (forgot the name of this in the presentation)
    multus.kubernetes.io/selector: "app: multus-app"
spec:
  ports:
  - port: 6000

The multus-endpoint-controller would watch only services with label "service.kubernetes.io/service-proxy-name: multus-proxy" and add endpoints for the selector in "multus.kubernetes.io/selector" instead of the normal selector.

Now instead of having 2 labels and 1 annotation, you have 1 label and 2 annotations. Not a big difference IMHO.

A problem may be if someone wants multiple selectors, but I think that is a rare case.

In this case, we need to make serialize selector into one line and it is not intuitive for user, and if it is for headless service, Kubernetes headless service has more feature as following, https://kubernetes.io/docs/concepts/services-networking/service/#headless-services hence we also need to care about it. It could need more time than I expect...

I have not seen any use of multiple selectors. A service request will the end in a random POD. The only use-case I can imagine is some canary test.

A records for any Endpoints that share a name with the Service, for all other types.

For headless services A records will be added for your added endpoints if they share the name with the service. Nothing more is needed from the multus-endpoint-controller.

I don't have any clear solution for that, cover all headless service with multus interface with certain feasibility. So let's discuss about it later. For now, headless service is not supported status, so we can discuss about it in npwg meeting https://github.com/k8snetworkplumbingwg/community#meetings

Ok. Thanks for a good presentation anyway 👍

BTW, I have a blog post about "kpng" which I hope will make life easier for proxy-builders, please check a pre-view at; https://github.com/Nordix/website/blob/kpng-1/content/en/blog/_posts/2021-00-00-kpng-specialized-proxiers.md

My idea was not new and is already used in danm; https://github.com/nokia/danm/blob/master/schema/DanmService.yaml#L20

hmm, I suppose your design does not conflict with my controller,so how about implement it as different controller?

I was merely suggesting a way of avoiding duplicated endpoints(-lices).

IMHO your proposal in this issue is sound and simple and no more "hackish" than the existing "service.kubernetes.io/service-proxy-name", in fact exactly the same. I am unsure why it was rejected, but I suppose nobody wants to touch anything while waiting for some future "class" field.

My focus is on load-balancing external traffic, but I found your approach in multus-service to make the load-balancing inside the PODs truly innovative 👍