Feature Request: Relax volume constraint to support more volume types

[dgerd]

In what area(s)?

/area API

/area autoscale /area build /area monitoring /area networking /area test-and-release

Describe the feature

We currently only allow for configmap and secret volumes to be mounted into the user container. This constraint is put in place as volumes are a source of state and can severely limit scaling. This feature request is to relax this constraint to allow a larger set of volumes to be mounted that work well with serverless functions.

I do not have a particular set of volume types in mind, but #4130 may be a good example.

[skonto]

Hi @boudo sorry for the late reply regarding:

I would like to know if read and write access is currently supported for PVCs in an InferenceService?

There is a flag kubernetes.podspec-persistent-volume-write that when set to true allows write pvc access in a ksvc : https://knative.dev/docs/serving/configuration/feature-flags/#kubernetes-persistentvolumeclaim-pvc. For Kserve you need to check what it allows at the moment.

[amarflybot]

+1 for hostPath support.

[skonto]

@amarflybot hi, could you provide your input here: https://github.com/knative/serving/issues/13690#issuecomment-1444055308. Also you can have hostpath via pvcs, have you tried that?

[amarflybot]

Yes, hostpath could be achieved via pvc. I tried that yesterday it's working great. Thanks

[zzuchen]

@gustavovalverde Thanks for sharing your use-case. This is something that is on the radar of the API Working Group, but we do not have someone actively working on this right now.

The "Binding" pattern as talked about in https://docs.google.com/document/d/1t5WVrj2KQZ2u5s0LvIUtfHnSonBv5Vcv8Gl2k5NXrCQ/edit#heading=h.lnql658xmg9p could be a potential workaround to inject these into the deployment that Knative creates while we work on getting this issue resolved. See https://github.com/mattmoor/bindings for examples.

cc @mattmoor

hello,the knative version currently used in our project is v0.23.0. We hope to mount nfs, and pvc is only supported after knative v1.2. However, upgrading the knative version is currently unrealistic for us. Is there any other method? Or do third-party components support us using nfs mounting on knative v0.23.0?

[zzuchen]

@gustavovalverde Thanks for sharing your use-case. This is something that is on the radar of the API Working Group, but we do not have someone actively working on this right now.

The "Binding" pattern as talked about in https://docs.google.com/document/d/1t5WVrj2KQZ2u5s0LvIUtfHnSonBv5Vcv8Gl2k5NXrCQ/edit#heading=h.lnql658xmg9p could be a potential workaround to inject these into the deployment that Knative creates while we work on getting this issue resolved. See https://github.com/mattmoor/bindings for examples.

cc @mattmoor

I have a very valid use case using Odoo, which saves all generated attachments on a NFS when using multi-tenant deployments, and this is being used on an actual k8s deployment with istio.

Knative can make things easier for us, but we can't drop the NFS (that's not even a source of state for us). There should be someway to accomplish this. If its not an issue with k8s it shouldn't be a constraint using Knative. That NFS should not impact a Knative deployment at all.

Dear gustavovalverde, could you please tell us how did you mount nfs on knative through odoo?

[secat]

Do you have any plan to add support for nfs volume source and for the future oci volume source (see KEP-4639: OCI VolumeSource)?

On our side we are mostly using a nfs volume to share ML models between pods and not mount them in container images. However, we need to create a PersistentVolumeClaim at the moment because of the "volume constraint" in knative service.

In the future, we aimed to use the new oci volume source which fulfill our need (see oci volume source's user story #3).