I've noticed that my user container takes a few seconds to start, including the entrypoint. It's not efficient to boot up a new pod every time a user starts working and mount their Persistent Volume Claim (PVC, specifically EBS) because it takes too long. I'm wondering if there's a way to dynamically mount a PVC in a sidecar container, triggered by the user, and then have that mount reflected in the main container. My plan is to pre-provision several pods for incoming users and only mount their data as needed. I'm also considering moving to a managed database and S3, but I'm curious if there are any new features in Kubernetes that could help me avoid that transition. Thanks for any insights!
4 Answers
Unfortunately, once a pod is running, you can't change its spec to add a new volume. A possible workaround could be mounting a network-based storage solution, like an NFS share or iSCSI. You could use different paths for each user to keep things organized. But your application needs to handle access control properly for each user's path.
Unfortunately, even with upcoming changes for sidecar lifecycle management, PVCs will still be pretty rigid once created. There are some creative but not entirely robust solutions that come to mind, though they might raise security issues. Can you elaborate on your specific use case?
You might want to look into using an init container that waits for the right conditions before starting. However, if you don't know the name of the user's PVC ahead of time, it might complicate things.
Do you really need a different PVC for each user? Usually, the person you're referring to is the end user of your app. Kubernetes doesn't allow changes at that level, so adding new mount points would mean creating a new pod. You might have to develop a new service to manage user-specific files instead.
Yes, that makes sense. I figured that might be the case. Thanks!
That's true, but figuring out the PVC names ahead of time can be tricky.