Schedule pod where workload is?

[jamesharr]

I'm excited to finally spot this CSI, because it's been something I've been wanting for a while. At first glance it seems to cover most use-cases we need for persistent storage, plus some.

One thing we've been playing with is TopoLVM to schedule Pods where the volumes exist. This could be useful when a workload handles its own data replication & integrity. It seems like the Proxmox-CSI expects to move the volume to where the workload is, but for workloads where the volume might be several terabytes, this seems like it might wind up causing more data migration than is necessary. An example is maintenance work where a node is drained, Pods using local storage on that node are shutdown (or left to fail), and when the node is returned to service, the Pods simply restart where the data is.

Is this something that the Proxmox-CSI is planning to support in addition to data-migration within a cluster?

[betmasterci]

Hi, the scheduler has metrics to check if there is enough free disk space for allocation. It will then choose the appropriate Proxmox node.

You can move a block device (PVC/PV) to another Proxmox node only manually. CSI/Kubernetes cannot move a PV to another proxmox node automatically. The pod will remain on a single Proxmox node but can migrate between VMs on the same Proxmox node.

You can maintain the VM with minimal POD downtime (the pod will launch on a neighboring VM).

[jamesharr]

Oh ok. Is this still the case even if the volume is on a Ceph block device where all nodes have access to that Ceph pool?

[sergelogvinov]

Hi, yeah previous comment for local storages only (lvm,zfs,folder)
Ceph pool - PV/PVC can migrate between all nodes.

[jamesharr]

cool cool - that makes sense. After I get a bit to play with this project, I'll see if I have any extra questions.