csi-proxy
csi-proxy copied to clipboard
kubernetes-csi
Now that the hostprocess container is stabilizing, can we abandon CSI proxy?
As the question suggests, can we abandon csi proxy and run csi plugin directly in hostprocess mode?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
CSI Proxy is a library of functions that are useful for CSI Drivers implementors who want to support Windows in their CSI Driver. The initial CSI Proxy design addressed the limitations about not being able to run privileged Pods in Windows with a client-server model, to do so, CSI Proxy is set up during the node bootstrap process and on its startup it creates named pipes in the host for CSI Drivers to use it, then the CSI Driver node plugin (usually the CSI Driver node DaemonSet) would have code to connect to the named pipes. Later, whenever it came time to do any privileged storage operations the CSI Driver node plugin would make an RPC call to the binary through the named piped.
After HostProcess containers, the CSI Driver node plugin can run the privileged operation on its own and doesn't need an extra binary (CSI Proxy) to do the calls, however CSI Proxy as mentioned before is a library of useful functions for CSI Drivers, therefore, CSI Proxy v2 will change the way it works moving from a client/server model to being a go library. With this in mind, CSI Proxy won't be abandoned.
The implementation is already complete in https://github.com/kubernetes-csi/csi-proxy/tree/library-development, we haven't reached the graduation criteria mentioned in https://github.com/kubernetes/enhancements/issues/3636 yet as we haven't seen many CSI Drivers adopt this new model.
As the question suggests, can we abandon csi proxy and run csi plugin directly in hostprocess mode?
Sure, you can copy the functions from the CSI Proxy codebase in your CSI Driver and that'd work just fine. CSI Proxy would still live as a common library that CSI Drivers could use.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Closing with the reason in https://github.com/kubernetes-csi/csi-proxy/issues/342#issuecomment-2405686952.