Proposal: Host-side Volume Discovery and Management Library

[leonwanghui]

As we all know, Kubernetes can be deployed anywhere, including various cloud platforms and bare metals. But as for storage resources, you have to choose specific storage backend according to the environment Kubernetes be deployed.

So we want to create a standalone project in Kubernetes that acts a library providing volume discovery and local management, aiming to break the limitation between storage systems and Kubernetes deployment environment, and to provide any storage backend regardless of deployment environment(cloud platforms and bare metals).

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.

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. I understand the commands that are listed here.

[leonwanghui]

Got my account verified now.

[cmluciano]

@kubernetes/sig-node-feature-requests @kubernetes/sig-storage-feature-requests

[leonwanghui]

@gnufied @saad-ali @jingxu97 @cantbewong

[cmluciano]

Adding #695 as related to some degree. This proposal is about mostly about pluggable hardware devices, but some of the ideas of discovery are similar.

[leonwanghui]

@cmluciano Hi, very thank you for your precious suggestion.

I had a look at this proposal and found that there are some differences between these two proposals:

1. Device plugin can and should be directly charged by kubelet, but volume discovery library is called and monitored by volume plugins (such as EBS, Cinder, iSCSI).
2. As for GPU, FPGA these stuffs, most of these hardware devices should be install locally on kubelet nodes, but storage devices can be attached remotely, which means you can deploy a storage array on a standalone node.

Plz speak freely if you have any thought.

[jsafrane]

@leonwanghui, there is a Container Storage Interface (CSI) being standardized right now at https://docs.google.com/document/d/1JMNVNP-ZHz8cGlnqckOnpJmHF-DNY7IYP-Di7iuVhQI/ and https://github.com/container-storage-interface/spec and which should address pluggable storage for Kubernetes, Mesos and Docker. Perhaps you should get involved there to make sure your use cases are included there.

[leonwanghui]

@jsafrane Hi, thank you for your suggestion.

Here are my thoughts of the connection between this proposal and CSI:

1. It has no doubt that CSI plugin will be the major caller of this library, otherwise we won't expect it as a library just like utils.
2. We find that some in-tree volume drivers don't support bare-metal scenario, and under this condition we want this proposal to cover the shortage and help these volume drivers provide bare-metal storage service as an optional solution.

Just my 2 cents : )

[vikaschoudhary16]

s/slove/solve

[k8s-github-robot]

This PR hasn't been active in 98 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review.

cc @calebamiles @leonwanghui @sarahnovotny

You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days