enhancements
enhancements copied to clipboard
Standard Application Protocols
Enhancement Description
-
One-line enhancement description (can be used as a release note): declaring standard Kubernetes application protocols for common protocols that are not IANA service names.
-
Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/pull/3727
-
Discussion Link: sig-net agenda
-
Primary contact (assignee): @LiorLieberman
-
Responsible SIGs: SIG-Network
-
Enhancement target (which target equals to which milestone):
- Stable release target (1.27):
-
[ ] Stable
- [ ] KEP (
k/enhancements) update PR(s): - [ ] Code (
k/k) update PR(s): - [ ] Docs (
k/website) update(s):
- [ ] KEP (
Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.
/sig network
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
What's the next step? This has no gates and is already GA - should we close it as complete?
I spoke with @aojea offline, it looks like this was not tracked for the release for some reason, and I missed updating the docs. (my bad, it was my first KEP 😕).
I opened https://github.com/kubernetes/website/pull/40881 for updating the doc and converted a draft PR I had opened to update the KEP according to what we merged.
You could either mark it as complete or I will ping you here again when the docs PR is merged.
Come back here and close it when docs are in.
Are we going to revisit GRPC?
Will do.
Probably will bring up the idea of changing appProtocol to a list to one of the sig meetings before revisiting GRPC standard name.
Probably will bring up the idea of changing
appProtocolto a list to one of the sig meetings before revisiting GRPC standard name.
one advice if you want to introduce the topic in the meeting, is to bring examples of the existing API and the proposal on how it will look like,
Curious if people here think it's possible to address GRPC without requiring appProtocol to support a list?
I don't deny the use case for multiple appProtocols - since you could have servers multiplexing protocols on the same port.
It would be just great to see if we could decouple adding protocol constants from changing the K8s API.
Docs PR merged today. Still waiting for https://github.com/kubernetes/enhancements/pull/3912 to have @johnbelamaric approval but this is just an update of the KEP based on whats already merged upstream.
Closing the issue.