Without using systemd-run, the fuse process will end up running as a
child of kubelet (kubelet > glfs-subvol > mount > fuse). In the event
that kubelet crashes or is otherwise restarted by systemd, all of the
child processes (incl fuse) will be killed. This results in pods using
the mountpoint to receive "transport endpoint not connected". Further,
once the pod is deleted, kubelet attempts to ensure the volumes are
unmounted, but it does not understand the ENOTCONN error, so it is
unable to unmount. This results in the pod getting stuck in the
"terminating" state indefinitely.
This commit uses systemd-run to move the fuse process to its own scope
so that it does not get killed if kubelet is restarted.
It does not fix the unmounting problem if fuse were to exit for some
other reason. This is only an issue for subvol because of the subdir
bind mount. Normally, auto_unmount would be sufficient to handle the
unmount, but this does not propagate to the bind mount, leaving that
mounted (and inoperative).
Without using systemd-run, the fuse process will end up running as a child of kubelet (kubelet > glfs-subvol > mount > fuse). In the event that kubelet crashes or is otherwise restarted by systemd, all of the child processes (incl fuse) will be killed. This results in pods using the mountpoint to receive "transport endpoint not connected". Further, once the pod is deleted, kubelet attempts to ensure the volumes are unmounted, but it does not understand the ENOTCONN error, so it is unable to unmount. This results in the pod getting stuck in the "terminating" state indefinitely.
This commit uses systemd-run to move the fuse process to its own scope so that it does not get killed if kubelet is restarted.
It does not fix the unmounting problem if fuse were to exit for some other reason. This is only an issue for subvol because of the subdir bind mount. Normally, auto_unmount would be sufficient to handle the unmount, but this does not propagate to the bind mount, leaving that mounted (and inoperative).
Related to #34