-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ILB mixed protocol backend #2733
ILB mixed protocol backend #2733
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: TortillaZHawaii The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hi @TortillaZHawaii. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Also injects EnableL4MixedProtocol feature flag to L4 ILB.
5f29091
to
422200b
Compare
/assign @mmamczur |
/ok-to-test |
// Otherwise prefer L3. | ||
// | ||
// See https://cloud.google.com/load-balancing/docs/internal#forwarding-rule-protocols | ||
func GetProtocol(svcPorts []api_v1.ServicePort, existingBS *composite.BackendService) string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's try to not use L3 by default
if we have non-mixed proto service then stick to the old behavior
if there is a mixed proto service then use L3
if service was single protocol but becomes multi protocol lets recreate the backend service
We can consider doing L3 Backend Services by default but only if we get 100% confirmation from the LB teams that there would be no limitations
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree.
I will mark it as in draft until we have confirmation.
/hold Waits for confirmation on feature differences between L3 and TCP/UDP backend services from L4 teams. |
Alternative solution that does not change how we handle single protocol backend services: #2739 |
Closed as we will pursue alternative solution #2739 that doesn't default to L3 Backend Service |
This PR allows the controller to create and migrate to L3 controllers.
backends.GetProtocol
will default to L3 protocol unless, there is already an existing service and ports that match the backend. For example if we have a running TCP backend and only services defined in the spec are TCP, it won't change protocol. However if we try to change from TCP to UDP, or mixed we will get L3. Once we are in L3 I don't think there is any reason to go out of it.pkg/backends/protocol_test.go
contains an exhaustive list of scenarios and expected behavior.In draft until the L4 Mixed Protocol feature flag is merged.Alternative that does not take into account existing services can be found here: #2739