Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Adding Windows Overlay support to Kube Proxy #70896
What type of PR is this?
What this PR does / why we need it:
Specifically, HNS needs additional configuration to allow Cluster IP connectivity. This is reflected in this PR by programming "service VIPs."
Currently HNS supports both DSR and non DSR for loadbalancing. This support is also reflected in this PR by adding support for both.
This PR also adds support for using HNS in V1 and V2. V2 is necessary for DSR and Overlay, but non DSR L2Bridge is supported in both.
Tests were also created to test HNS V1 and V2 implementations that were added in this PR.
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Hi @ksubrmnn. 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.
Nov 9, 2018
Can you please update the first comment in this PR to include more information? A lot more.
What does this do? Pretend I don't know anything about Windows.
Was there a design doc or KEP?
Is it considered Alpha or Beta or GA?
Where are the tests? That's a LOT of code to add with no tests.
What should the release notes say about this?
I can't do meaningful review of it because I really don't know what it is doing.
2 times, most recently
Jan 11, 2019
[APPROVALNOTIFIER] This PR is NOT APPROVED
If they are not already assigned, you can assign the PR to them by writing
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:
Approvers can indicate their approval by writing
@thockin Do we still need a feature flag if we are checking to see if the network they are providing Kube Proxy is overlay or not? In Windows, the a network needs to be created before kube-proxy is started. This network's type is checked, and based on that, we program for either l2bridge of overlay. Since we already have this check, maybe a feature flag is not needed? I included a commit that adds it anyway, but let me know if you think it's still necessary.
The same question applies to DSR, which is a new feature added in this PR. This is already default not enabled, and it is toggled on through the enable-dsr flag. As such, I don't think it needs a feature gate.