GEP-1911 - Backend Protocol Selection

[dprotaso]

What type of PR is this?

/kind gep

What this PR does / why we need it:

This PR flushes out how app developers can specify that their application supports different protocols

Which issue(s) this PR fixes:

Fixes: #1911 (Backend Protocol GEP)
Fixes: #205 (Websocket Support)

Does this PR introduce a user-facing change?:

Allow end-users to specify backend protocols

[arkodg]

+1 for adding an API / API field to be explicit about backend/upstream protocol

since this PR suggests a HOW , will share my preference, which would be to keep it close to the
backendRef

protocols: []Protocol

e.g.

- backendRefs:
    - name: foo-v1
      port: 8080
      protocols:
      - HTTP
      - PROXYPROTOCOL
      weight: 90

relates to envoyproxy/gateway#1328

[dprotaso]

since this PR suggests a HOW , will share my preference, which would be to keep it close to the
backendRef

The only thing with the list of protocol strings is that it doesn't enable the goal I set out - Extensible - additional protocol specific fields should be easy to add in the future

This is why rather than having an h2c constant I added a Cleartext field under HTTP2PortProtocol.

I'm not super opinionated about this and welcome discussion.

[arkodg]

since this PR suggests a HOW , will share my preference, which would be to keep it close to the
backendRef

The only thing with the list of protocol strings is that it doesn't enable the goal I set out - Extensible - additional protocol specific fields should be easy to add in the future

This is why rather than having an h2c constant I added a Cleartext field under HTTP2PortProtocol.

I'm not super opinionated about this and welcome discussion.

good point, a struct is better if we are envisioning customizing the backend protocol functionality.
I was taking the concept of upstream protocol https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.ProtocolType, converting it into a list and reusing it here

[robscott]

@dprotaso We discussed this at the community meeting yesterday. Here are some rough notes:

1. I think we should really consider the list of AppProtocols proposed for upstream Kubernetes as a solution to this specific problem
2. If/when Service includes a list of AppProtocols, that would likely be propagated to ServiceImport since that API is just mirroring Service.

@LiorLieberman has been working on the upstream AppProtocol changes and has also been commenting here. Would be helpful to understand what we'd still be missing if AppProtocol became a list on the Service API.

[youngnick]

Some thoughts on the table caveats, but aside from that this looks pretty good to me.

I've specifically not addressed the open questions at this time because I think we should all take a bit and think about them before doing anything. Let's get this merged at Provisional first.

[robscott]

Thanks for all the work on this @dprotaso!

[robscott]

Thanks @dprotaso, didn't go all the way through it, but I think I saw most of your updates.

[dprotaso]

@youngnick @robscott Can you take another look? 🙇

[youngnick]

/lgtm

/hold

for @robscott's review though.

[robscott]

Thanks @dprotaso! One non-blocking nit. Feel free to remove hold and catch this in a follow up.

/lgtm

[robscott]

/lgtm
/hold cancel