It should not consume system reserved computational resources

[everpeace]

I understand this CSI driver launches mountpoint-s3(FUSE) process in host's systemd.

In normal kubernetes node, cluster administrator configured appropriate reserved computing resource for system components (non-kubernetes components running in host). (https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/).

Launching fuse processes in host's systemd makes it difficult to manage computational resources and its reservation in the node, doesn't it? Particularly, when many pods using this csi driver are scheduled on the node, the situation could be worse.

When using the csi driver in kubernetes, how to manage node's computational resource as cluster administrator?? Are there any recommendation??

[jjkr]

That is correct, the CSI driver will launch the mountpoint fuse process in the host's systemd under system.slice, so using the system-reserved configuration that you linked is the only option for resource limits on the fuse driver itself at this time. Giving more fine grained control here is an enhancement we are looking at, however there is not a specific timeline I can share right now.

If there is any additional detail you would like to share that can help inform the design and prioritization of this feature, we'd be happy to hear it.

[everpeace]

Giving more fine grained control here is an enhancement we are looking at, however there is not a specific timeline I can share right now.

Thanks, I got it. But, consuming system-reservation would not be good idea. I expect so many cluster admins don't want it. I hope this would be fixed soon.

If there is any additional detail you would like to share that can help inform the design and prioritization of this feature, we'd be happy to hear it.

As I posted here, I think:

• FUSE process should be running in sidecar container in user pod because of computational resource management perspective
• But, as a platform engineer, it would be difficult to allow privilege for the fuse sidecars but only for CSI driver containers. So, fuse sidecar without privilege would be nice.

There are several OSS that support this:

• https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver
  • FUSE process runs in non-privilege sidecar container in user pod
  • Only csi driver daemonset pod requires privilege
  • CSI driver just mount and the passed opened descriptor to sidecar container
  • Sidecar container just runs gcsfuse against the received already opened file descriptor
• https://github.com/pfnet-research/meta-fuse-csi-plugin
  • Almost the same technique with gcs-fuse-csi-driver
  • Additionally, they support fusermount3-proxy approach that can support existing FUSE implementation using libfuse3 without any modification. fusermount3-proxy mimics fusermount3 command but it delegates mount execution to CSI driver pod(privileged) via unix domain socket. So fuse sidecars don't need privilege.

[jjkr]

Thank you for the input. We are aware of this alternative design option and the advantages it brings for resource management in particular. The use of sidecars as they exist today also comes with some drawbacks, mostly related to the fact that the sidecar starts in parallel with the application container, so the mount is potentially not available to applications at startup and is not available to init containers at all.

The new native sidecars feature looks like a promising solution here and is something we're looking at. So again thank you for the request and the input and we'll share updates as soon as we can.

[javydekoning]

I think running as a side-car would also help support a broad range of OS'es and potentially resolve #154 and #168

[everpeace]

I think running as a side-car

As stated here, normally running FUSE process in a container would require privilege permission. It would arise security concern from kubernetes cluster admin perspective. So, running as side-car without any privilege would be great 🙇

[muddyfish]

Requires Mountpoint to have improved memory control: awslabs/mountpoint-s3#987

[M4t7e]

Removing the systemd dependency would enable compatibility with specialized Kubernetes operating systems like Talos, which do not use systemd. Currently, this integration appears infeasible (see #213).