-
-
Notifications
You must be signed in to change notification settings - Fork 322
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
Flexvolume volume-plugin-dir is read-only on coreos #57
Comments
Agreed, the kubelet flag and mount could be added across platforms. I've had to set it manually to evaluate rook so it'd be nice to standardize it and shouldn't cause any downsides for those not using volume plugins. Calico and flannel have established a pattern where they use a sidecar pod to install needed binaries on hosts I'm a bit partial to continuing to use It might be a nice exercise to ensure it works for rook and some other popular flex volume plugin too, though I've only used rook myself (and torus back in the day). cc @barakmich |
I'd like to include #61 on bare-metal or maybe all platforms in the next release. I'm also not a heavy rook user at the moment, any chance you've looked at the change or have opinions? Which platform(s) are you seeking? |
lgtm, my use case at the moment is bare metal |
Added on bare-metal. I'll verify with rook soon, but these flags are working and sensible to always have enabled. |
This problem is not limited to bare-metal. For example, I want to use DigitalOcean block storage via |
In addition to that, DigitalOcean block storage plugin executable needs to be accessible by kube-controller-manager, it's possible to achieve that by for example mounting |
I have no objection to providing the I'm not yet familiar with Digital Ocean's plugin so that'd be more of an exploration. |
Thanks. And what's the correct way of modifying mounts in the |
(many flexvolume plugins need to be run not only by kubelet but also by kube-controller-manager, and the plugin from external-storage project that handles DigitalOcean volumes is an example of such situation) |
You may propose mount changes to the controller manager manifest in upstream bootkube and Typhoon's terraform-render-bootkube. Any changes should be generally applicable and agnostic to platform and plugin. Plugin vendors must document any control-plane modifications they require and provide appropriate sidecars for installing the plugins. To experiment, you may use At the moment, I'm not sure which Digital Ocean plugin you're referring to. It may be helpful to link what you're trying to use / talking about. Quality of flexvolume plugins varies. |
I mean this plugin. As of adding mounts to the controller-manager deployment via |
If I want to use the DigitalOcean storage provisioner, is it enough to modify it to use |
To answer my own question, it does look as if the controller manager also needs to be modified as @ivan4th says, since persistent volumes fail to mount:
How should I modify the controller manager? I'm not so familiar with the internals of Kubernetes. |
@aknuds1 Please see kubernetes-retired/external-storage#531, it should contain all the required steps. |
@klausenbusk Thanks! I can't figure out the exact steps from reading that issue though :/ Sorry if I'm missing the obvious. From what I can tell there are two steps:
How should I implement the two above steps with Typhoon? |
Regard the flexvolume change, pleaae see kubernetes-retired/external-storage#571. |
@klausenbusk Ah OK, I could add |
|
@klausenbusk OK thanks! I've edited the kube-controller-manager deployment now however, mounting /etc/kubernetes/kubelet-plugins/volume/ to /etc/kubernetes/kubelet-plugins/volume in the containers and adding the flag |
|
@klausenbusk I was able to make it work! I realized I had copied the wrong host volume plugins path from the 571 issue :/ I am still very much interested in taking the next step though and modifying Typhoon (and/or Bootkube) so that this will be automated. Do you know how this could be done? |
I know The easiest option is probably patching |
@poseidon Would it make sense to create a DigitalOcean provisioner addon or include it as default? |
@klausenbusk Could it complicate things that DigitalOcean are developing their own controller manager which is supposed to implement storage provisioning in the future? I.e., once the latter implements storage provisioning, I think it would be preferable. |
I don't think that is gonna happen in the near-future, so we need something else for the time being. The controller manager is also currently blocked on kubernetes/kubernetes#55633, so we can't include it.
digitalocean/digitalocean-cloud-controller-manager#19 is worth reading. |
I see, you clearly have more insight into this issue than I have 🙂 Would
there be an easy migration path from the storage provisioner to
DigitalOcean's official solution once that arrives you think?
…On Fri, Apr 6, 2018, 16:03 Kristian Klausen ***@***.***> wrote:
Could it complicate things that DigitalOcean are developing their own
controller manager which is supposed to implement storage provisioning in
the future?
I don't think that is gonna happen in the near-future, so we need
something else for the time being. The controller manager is also currently
blocked on kubernetes/kubernetes#55633
<kubernetes/kubernetes#55633>, so we can't
include it.
I.e., once the latter implements storage provisioning, I think it would be
preferable
digitalocean/digitalocean-cloud-controller-manager#19
<digitalocean/digitalocean-cloud-controller-manager#19>
is worth reading.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#57 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARK1_JI-ipPAto6kkxK_UrHwY1Juq7Lks5tl3W1gaJpZM4QXCSp>
.
|
It should be easy to script a solution. Worst case we let k8s create new PV and copy the data from the old DigitalOcean provisioner PV. |
@klausenbusk OK great! I would be all for including the storage provisioner then with Typhoon, either as an add-on or built in. It's very useful! |
Oh, they are already working on it: https://github.com/digitalocean/digitalocean-cloud-controller-manager/pulls?utf8=%E2%9C%93&q=csi . I didn't expect that. But we are still blocked on kubernetes/kubernetes#55633 sadly :/ |
coreos/docs#1172
This affects things like rook
https://rook.github.io/docs/rook/master/k8s-pre-reqs.html
The text was updated successfully, but these errors were encountered: