KEP-4020: Unknown Version Interoperability Proxy

[richabanker]

• One-line PR description: Adds a KEP

• Issue link: Unknown Version Interoperability Proxy #4020

• Other comments: Taken over from [WIP] KEP-3903: Unknown Version Interoperability Proxy #3903

[linux-foundation-easycla]

• ✅ login: lavalamp / name: Daniel Smith (00a2cf7, 0b4ebf4, a9a98bd, 6ce7c55, a134f0f, 11b36e8, 649d8b0, 91de7a5)
• ✅ login: logicalhan / name: Han Kang (2759e2e, 8cd8369, 59ee6ce)
• ✅ login: Richabanker / name: Richa Banker (1ba3572, ec889db, 252d5ba, 9485874, f9442d3, 0e699f7, f0d90bd, cde58c3, 48374b7)
• ❌ The email address for the commit (252d5ba, 9485874, 0e699f7, f0d90bd) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

[enj]

Had a discussion with Joe earlier today and wanted to write down some thoughts from that here.

We should be make sure that this feature (as it moves to GA) remains useful to folks who decide to opt out of the proxying aspect. So consider a future where the storage version API and this feature are all GA but the admin has opt-ed out of allowing API servers to communicate to each other (however that ends up being expressed - and it should be something that can be expressed - there needs to be way to opt out of attempting the network calls to begin with instead of trying them and having them fail).

We should make is so that the new handler is still active in that case, and when it sees a request for an API that it does not know about, before returning a 404 for it, it would check to see if any other API servers could serve that API via the information it has about them per the SV API. If other API servers could serve it, it would instead return a 503 directly since it is not allowed to proxy to them. Since there would be no proxying attempted in this case, I do believe that this would introduce another race condition per this earlier thread #4015 (comment) though I am unsure of how to resolve that.

[jpbetz]

This is an implementation detail, but I'll mention it here so I don't forget-- To determine if the local apiserver can handle a GVK, I'd prefer check the apiserver's already available in-memory registry of available GVKs directly than to check the data loaded in from StorageVersion API. This will be fast and low risk.

[jpbetz]

Added some minor comments and naming nits. LGTM once those are reviewed.

@deads2k: PRR also looks good to me for alpha.

[deads2k]

Content and PRR lgtm.

/approve

approving and leaving lgtm with @jpbetz

/hold

holding so this doesn't merge without Joe's ack. @jpbetz feel free to remove when ready.

[aojea]

LGTM from the networking pov

[jpbetz]

/lgtm
/approve
/hold cancel

Thank you @richabanker!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, jpbetz, Richabanker

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• keps/prod-readiness/OWNERS [deads2k]
• keps/sig-api-machinery/OWNERS [deads2k,jpbetz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[richabanker]

Sorry for the delay in getting to the nits. Sending those out in a separate PR. Thanks all for the review!