Skip to content
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

Make SRIOV network device plugin independent of CNI #549

Open
aojea opened this issue Apr 8, 2024 · 8 comments
Open

Make SRIOV network device plugin independent of CNI #549

aojea opened this issue Apr 8, 2024 · 8 comments

Comments

@aojea
Copy link

aojea commented Apr 8, 2024

What would you like to be added?

Remove the dependency on CNI plugins using CDI devices https://github.com/k8snetworkplumbingwg/sriov-network-device-plugin/blob/master/deployments/cdi/README.md

What is the use case for this feature / enhancement?

Depending on CNI adds complexity, since SRIOV plugin already controls the whole lifecycle of the devices it can use CDI devices and its own APIs to handle the attachment of the additional devices to the Pods

I've presented and demoed how to use CDIDevices to add network interfaces to pod in https://docs.google.com/presentation/d/1pjDCtpdbCSWaqCbBYWgzTxAewOVbMf6rUS5SbjAJAe8/edit#slide=id.g2c2d4de4b62_1_323

https://github.com/aojea/network-device-plugin

Happy to sync on this if there is interest , also to work on an implementation

@aojea aojea changed the title Make SRIOV operator independent of CNI Make SRIOV network device plugin independent of CNI Apr 8, 2024
@SchSeba
Copy link
Collaborator

SchSeba commented Apr 11, 2024

Hi @aojea, Thanks for this really interesting topic!

I check the presentation also video and the code.

there is only one point that I was not able to find about the deletion of the pod are we able to run some work in that case? for example change the internal name back/mac address/remove IP address and other stuff

@aojea
Copy link
Author

aojea commented Apr 11, 2024

Good question, let me figure that out

@aojea
Copy link
Author

aojea commented Apr 11, 2024

@SchSeba https://github.com/opencontainers/runtime-spec/blob/main/config.md#poststop

The demo and code is just for PoC and feasibility purposes, as I said, I'm happy to collaborate on this , feel free to reach out in slack kubernetes @aojea or via email

@SchSeba
Copy link
Collaborator

SchSeba commented Apr 16, 2024

This is really nice!

will you be able to talk about it on our next community meeting?
you can find it in the k8smeet@gmail.com calendar its the "K8s Network & Resource Management WG Tech discussion" meeting

@zshi-redhat
Copy link
Collaborator

zshi-redhat commented Apr 30, 2024

@aojea Is the goal here to eliminate the use of sriov-cni or just handle the movement of sriov interface to container namespace in sriov device plugin (still use sriov-cni for interface configurations, such as IP/MAC/spoofCheck/linkAuto etc)?

@aojea
Copy link
Author

aojea commented Apr 30, 2024

@aojea Is the goal here to eliminate the use of sriov-cni or just handle the movement of sriov interface to container namespace in sriov device plugin (still use sriov-cni for interface configurations, such as IP/MAC/spoofCheck/linkAuto etc)?

I'm looking for improvements on the user experience and reduce the complexity of the existing solutions, not familiar with all the SRIOV use cases , but my feeling is that you can define this configurations in one place and avoid spreading the responsibilities over different components ... this will turn out in a better UX and improve troubleshooting and supportability

@zshi-redhat
Copy link
Collaborator

@aojea Is the goal here to eliminate the use of sriov-cni or just handle the movement of sriov interface to container namespace in sriov device plugin (still use sriov-cni for interface configurations, such as IP/MAC/spoofCheck/linkAuto etc)?

I'm looking for improvements on the user experience and reduce the complexity of the existing solutions, not familiar with all the SRIOV use cases , but my feeling is that you can define this configurations in one place and avoid spreading the responsibilities over different components ...

I assume it is in align with the network device proposal here: opencontainers/runtime-spec#1239, which provides the capacity of adding a network device to the namespace without explicit or implicit interactions with CNI, but not to configure its networking parameters (e.g. IP allocation and management).

@aojea
Copy link
Author

aojea commented Apr 30, 2024

yep, exactly, decoupling interface management of interface configuration I think allow to have much cleaner implementations ... right now CNI is "abused" for "everything networking goes there"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants