GSoC Tracking Issue: CRI-based CSI image volume driver about cluster-addons HOT 14 CLOSED

Hello! I am interested in learning and contribute here but I am new to this platform. Please guide me from where I should start.

from cluster-addons.

@Ananya-1106
Hi, thank you for comment 🎉
Please see here for starting contribution.

from cluster-addons.

Hey @ecordell, one doubt here. What does this line mean. < The current driver is build around buildah>.
As per my understanding, Is buildah providing storage here or acting as a CSI plugin.

from cluster-addons.

@ecordell, In the above pod example. As per my understanding, it's ok to provide volume to the container using the CSI driver. But why mounting it with kfox1111/misc:test image.

from cluster-addons.

@ecordell , what is the benefits of mounting content of container image as a volume to a container.

from cluster-addons.

This is really cool! I am interested in this and will be applying.

from cluster-addons.

Interesting. Thanks for working on this issue.

There's another driver being worked on that does cri located here: https://github.com/warm-metal/csi-driver-image

Some discussion around the image-populator dirver and the image driver here: warm-metal/container-image-csi-driver#12

I think we all need to put our heads together for a bit and weigh the options.

I used buidah for the prototype implementation because it was portable and could use the image cache for multiple instances without consuming extra storage as well as being really simple to implement.

warm-metalcsi-driver-image used cri so that the cache could be used also, but shared with the runtime.

the cp variant described here would be portable too, but would not share any data with the image cache or between multiple instances.

I think the ideal solution would:

• share the underlying storage with the runtime and between instances of volumes
• works with any runtime
• supports writable volumes where only the changed files consume extra space
• would be best if it could be incorporated directly into k8s so it could be relied on always being there

from cluster-addons.

@viveksahu26 the the reason I think the image driver is very useful is two fold.

1. Its another way to distribute data other then a configmap/secret or bundling data with binaries. It lets you reuse all the container registry/mirroring/scanning/signing/etc tools for shipping data around just like the binaries.

For example, instead of building a container that starts with nginx, and adds your static website content to it, requiring a new container when nginx needs updating, you can deploy the nginx container directly,, then mount your content at /var/www/nginx/html. You can then update either container without updating the other. This is especially useful when you have something like rpm mirrors where you may want the host nginx container to support different architectures as the rpms inside.

Another example, nginx serving out rpm repos for different architectures. It would save needing to build many permutations like:
host arch / rpm arch
arm64 / arm64
arm64 / x86_64
x86_64 / arm64
x86_64 / x86_64

While if you had image volumes, youd nave: nginx for arm64, nginx for x86_64, and an rpm repo image for x86_64 and one for arm64. saving quite a bit of space.

2. A way to add additional modularity to assemble containers. For example, you could build a busybox image that has a statically linked binary. You could then mount that into any other container and use it without needing to change/extend the original container. This gives you more options to assemble things in pods without needing to build new containers.

from cluster-addons.

Totally agree with @kfox1111

I operate an internal cp solution with a large number of pods and it is not working well:

• Arranging to execute cp in the image means the image must be executable or you need to inject a statically linked binary. Both have annoying costs.
• cp consumes a lot of IOPS, so much so that our nodes became degraded during node rotation as many new pods were executing cp simultaneously.
• cp adds significant startup time (10-20 seconds for me) to pods compared to establishing a layer/snapshot on an image.
• cp wastes the full size of the image for each Volume when we either need no changes (read-only) or very few (read-write snapshot).

We are testing https://github.com/warm-metal/csi-driver-image and so far using it for Pod Ephemeral RW Volumes is working well.

from cluster-addons.

I also agree with @kfox1111 and @glennpratt. With no extra data duplication and runtime overhead is a requisite.

There is no standard location or directory structure for an image on-disk across CRI implementations. This means that once an image is on a node, there's no standard way to get its contents.

Though there is no unified location, we can still found the position through CRI API ImageService.ImageFsInfo, like my project bind-host did.

The directory structure is various because of different container runtimes and their storage drivers. If we want to use those images, we need to know which kind of container runtime is running and how it saves images. The good thing is that there is/will be not so much runtime. I think this requirement is not so common especially on sub-popular runtime. We need not make working with any runtime as a goal. Currently, we've already known how to implement such a plugin on both containerd and cri-o.

An opposite and hard way, that may be mentioned by @kfox1111 in warm-metal/container-image-csi-driver#12, is to define new APIs and help runtime implement them.

And, csi-driver-image is going to support cri-o.

from cluster-addons.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

from cluster-addons.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

from cluster-addons.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

from cluster-addons.

@k8s-triage-robot: Closing this issue.

from cluster-addons.