-
Notifications
You must be signed in to change notification settings - Fork 10
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
Build new notebook container images by snapshotting an interactively created prototype notebook #35
Comments
/label kind/enhancement project/notebooks-v2 |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@jiridanek: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There are a couple of problems with your proposed approach (but they might be acceptable):
|
They will stick around, but they need not continue running. They can be in Terminated state if a way is found to terminate them after the work is done, at which point they only takes up screenspace in |
Also interestingly, Kubernetes 1.31 added a new volume type for OCI images, which might help us do this more efficiently: https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/ |
We're trying to explore multiple possibilities for user-friendly notebook container building. One approach proposed at 2024-08-15 meeting is to let users snapshot the filesystem of their running notebook pods, upload the result into container registry as a new image, and then many new notebook instances can be created from this image.
My preferred implementation idea follows what Kaniko does (https://github.com/GoogleContainerTools/kaniko/blob/main/docs/designdoc.md). The main difference is that we can (should) use multiple containers in the pod, as we don't need to run any additional commands in the container that's being snapshotted.
/proc/$PID/root
, compute diff between the base image and user's image filesystems using the naive approach described in kaniko design doc, build a tar layer from the changed files, and either upload that directly, or combine it with the original base image to form a new ready-to-be-deployed image.Skip the same directories that kaniko skips (/proc, ..., also skip any volume mounts).
Kubernetes itself is capable of "checkpointing" of running containers. https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/ this is also an avenue to explore, but it seems to require being a privileged user to perform this operation.
The text was updated successfully, but these errors were encountered: