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

PVC mover #346

Open
leoluk opened this issue Sep 3, 2024 · 1 comment
Open

PVC mover #346

leoluk opened this issue Sep 3, 2024 · 1 comment
Assignees

Comments

@leoluk
Copy link
Member

leoluk commented Sep 3, 2024

We want a simple way of moving PVCs elsewhere when draining a node.

@lorenz
Copy link
Contributor

lorenz commented Sep 3, 2024

The moving part itself is not too hard, we can basically push a tar or similar over an mTLS connection. Serialization/deserialization of most things is relatively easy, special attention needs to be paid to xattrs, sparse files and hard links. Reflinks are a pain though, the best approach to reliably serialize them is hope that the underlying filesystem supports FIEMAP and keeping track of all the mappings which can consume non-trivial amounts of memory.

Also block positions are accessible to userspace and will expose that there was a filesystem move. On the other hand this mechanism supports migrating between very different PV implementations as it sits on the VFS layer.

The most complicated part is figuring out when to move and what decides that. K8s can do it, but will do it gratuitously as PV affinity can only be hard (required), a preference for the same node cannot be expressed. Advantage of having K8s do it is we do not need to become involved in scheduling decisions. If we do it, we need to decide where to move the PV, hope that the pod can schedule onto that node and then update the affinity, which is a bit painful.

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

No branches or pull requests

2 participants