Closed jiayoukun closed 1 month ago
dougbtv
commented
1 month ago This is a great discussion for the NPWG, you can find the connection info @ https://github.com/k8snetworkplumbingwg/community! Thanks, it'd be great to have you join to discuss it.
jiayoukun
commented
1 month ago Hello, my friend!
I previously proposed features in the community regarding:
"Add Pod's netns to annotations"
"Enhance CNI flexibility to read and write deviceInfo by removing the deviceID restriction"
Do you perhaps recall them?
In my work and business group, we utilize many components from the k8snetworkplumbingwg community, including multus-cni, sriov-cni, sriov-network-device-plugin, and ovs-cni. As a result, I have spent a significant amount of time researching the component code to extend our business capabilities. The two features mentioned above are what I believe to be quite effective for multus-cni. Previously, you invited me to participate in community meetings, but my spoken English and listening skills are very poor. I am Chinese, and most of my English communication at work comes from reading documents and replying to emails. However, I have indeed invested some time in researching the community components and wish to contribute to the community. Perhaps I should create a document introducing these two features and allow the NPWG maintainers to discuss whether they are feasible. Or maybe you have a better approach? I sincerely hope to receive your help!
------------------ 原始邮件 ------------------ 发件人: "k8snetworkplumbingwg/multus-cni" @.>; 发送时间: 2024年5月23日(星期四) 晚上10:04 @.>; @.**@.>; 主题: Re: [k8snetworkplumbingwg/multus-cni] Add Pod's netns to annotations (Issue #1285)
This is a great discussion for the NPWG, you can find the connection info @ https://github.com/k8snetworkplumbingwg/community! Thanks, it'd be great to have you join to discuss it.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
In traditional single-CNI Pods, there is only one network interface, and the network topology is relatively simple. However, when using multus-cni, multiple CNIs are typically used simultaneously, resulting in multiple overlay networks. In Kubernetes, the netns of a Pod object is not publicly exposed. As a component responsible for managing multiple CNIs, it should patch the netns to the Pod's annotations, providing developers with more flexibility to manage fine-grained dynamic routing across multiple CNIs. What do you think? I was originally planning to submit a PR with the code changes, but currently, multus-cni's handling of annotations depends on #network-attachment-definition-client.