Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
sync CNI config in goroutine #74389
What type of PR is this?
What this PR does / why we need it:
This PR fixes #74388 .
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Hi @answer1991. 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.
Discussed with @squeed this morning. I think this is an acceptable workaround for now.
In the very near future we'd like to kill the periodic resync entirely and make the plugin choice more declarative, whether through a disk file or the kubelet ConfigMap (since dockershim doesn't have its own config options yet, they still go through Kubelet).
[APPROVALNOTIFIER] This PR is APPROVED
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
1 similar comment
Actually, we had already refactor CNI config using ConfigMap in our downstream K8S. But the implement has already broken the CNI specification. So this PR use this workaround to follow the CNI specification.
Please feel free to let me know if you need any help when you start to refactor these codes, me and @changyaowei would like to provide some helps.
@answer1991 I'm actually rethinking the ConfigMap bits; depending on the runtime you use (dockershim or crio or something else) kubelet may not be involved in the CNI decisions at all. So having any network plugin options in the kubelet config would be useless with a remote runtime like CRIO. Plus, dockershim is supposed to eventually also be a remote runtime and wouldn't use the kubelet options.
Which leads me to believe that perhaps the file-based approach is a better one for now, even if it isn't as "kubernetes-y".