-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Ensure the KUBE-MARK-DROP chain in kube-proxy mode=ipvs #82214
Conversation
Hi @uablrek. 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/test-infra repository. |
mostly by analogy with But yes, there is a race, and it makes sense for the proxy to create the chains it needs (but to leave kubelet to fill in the rules). /lgtm |
/test pull-kubernetes-bazel-build |
/lgtm |
/approve |
/ok-to-test |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andrewsykim, uablrek 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 |
@uablrek can you update release notes please? |
@danwinship Thanks for the ref to #82125, a very good compilation of facts! I am sorry I missed it. But I disagree with the proposal. IMO all binaries that uses any chain should ensure it's existence. The name "EnsureChain" is very good. The agreement should be what binary that shall remove it. There is a PR that I can't find that make sure the chain is not removed by |
I don't know how, but I am willing to learn 😄 @khenidak helped with the release note. |
/priority important-soon |
@uablrek So, yes, as I said above, it's good for kube-proxy to ensure that the chain exists (since they can't write out rules jumping to it otherwise), but there has to be only a single place where we add the rules to those chains, because those rules are configurable, and can change between releases, and we don't have a good way to ensure that kubelet and kube-proxy get configured the same way, and we're not guaranteed to always be running the same versions of kubelet and kube-proxy during a cluster upgrade. |
/milestone v1.16 |
/lgtm |
What type of PR is this?
/kind bug
/sig network
/area ipvs
What this PR does / why we need it:
The
kube-proxy
expects theKUBE-MARK-DROP
to exist. This chain is created bykubelet
, it works but creates an unnecessary race. Ensuring the chain in bothkube-proxy
andkubelet
removes the race without affecting the function.Also in dual-stack the
KUBE-MARK-DROP
is only created for the "cluster default" family bykubelet
so dual-stack operation fails forkube-proxy
unless the chain is created by other means, e.g with;Which issue(s) this PR fixes:
Fixes #80462
Special notes for your reviewer:
Nobody seem to remember why the
KUBE-MARK-DROP
is created bykubelet
.Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: