-
Notifications
You must be signed in to change notification settings - Fork 373
Not using native diff for overlay2 #1429
Comments
@devimc they are using devicemapper |
@egernst ok, then why they are sharing |
At least we should a look and see why the "DinK" (docker in kata) setup has Native Overlay Diff disabled, then. They are sharing so they can utilize the docker socket (they are doing docker-in-docker). I need to better understand the flow for DiD wrt what is done with the docker socket from the host, but I'm assuming build context is moving from guest -> host. If this is the case, we could consider an image that isn't exactly DinD, but instead Kata specific to use its own daemon instead of hosts. I'm not sure if the usage with runc leverages a build cache, or something, though... |
When performance is terrible, always look at 9p, even if you don't think you're using it. I could reproduce it, and have a suggested fix. After 8 minutes of still extracting, I gave up running a test docker image. With the fix, it finishes the build in ~2 minutes A few items: The fixNot particularly relevant, but here's the docker image I was testing to build inside DinD:
Here's the "original" yaml for dind (though I updated memory requirements for the pod, and utilize runtimeClass):
With this, when exec'd in, we see:
Terrible, terrible. By simply creating the volume explicitly for /var/lib/docker, and back it by a tmpfs, we avoid the issue. Updated yaml:
When exec'd in we see:
With this, /var/lib/docker is handled by a tmpfs instead of 9p. The tradeoff, now, is disk-space for memory, since the image building itself will be backed by RAM. In the example above, we specified 3GB memory for the pod to handle this overhead. Other considerations:When running your yaml as is, you are running unconstrained. So, if you do it with runc on a 96 core machine, your build and extractions will be parallel. With Kata default, you'll only run with a single CPU. Similar factors should be considered with respect to RAM. From discussions in the past, I understand that you have constraints dialed in pretty well, so I'm sure you're already very aware! Thanks to @mcastelino and @krsna1729 for the fun debug session! |
@cespo for a little more context you are trading memory for storage https://kubernetes.io/docs/concepts/storage/volumes/#emptydir
If you do not want to trade memory for storage or want to persist you may want to explore using raw block volumes. However in this case as you really want an ephemeral build using memory may not be too bad. https://kubernetes.io/blog/2019/03/07/raw-block-volume-support-to-beta/ We have verified that it works with kata /cc @amshinde |
Also once we add virtio-fs support via nemu to kata you no longer need to make this tradeoff. |
We don't really have to trade memory for storage in this case. The problem with 9pfs still stands here though because everything that is shared between containers is still super slow. Looking forward to seeing virtio-fs support landing in a official release. |
The target for an early support ( |
@cespo commenting that volume out will help solve the issue. However you will still be bound the size of the max size of devicemapper, which by default is configured to be 10GB. So if the build results in increasing the container growing to that limit, you may see failures. And this limit is a node level configuration (at least with docker it was). Just something to watch for. |
Hey @cespo - can this issue be closed, or are there still opens? |
Description of problem
Starting a
docker:dind
container with the kata-runtime, the 'Extracting' phase of the nested docker pull commands is very slow.In the logs I can find an error saying:
Expected result
Docker commands in kata-runtime to run at the same speed of non kata-runtime
Actual result
Docker commands in kata-runtime are very slow
From within the dind container:
Pod Spec
Kernel config file
I tried different configurations with
CONFIG_OVERLAY_FS_REDIRECT_DIR
andCONFIG_OVERLAY_FS_METACOPY
on/off as well as ALL the overlay_fs modules on. Same errorContainerd
I have built containerd from master to include
mxpv:devmapper
branchMeta details
Running
kata-collect-data.sh
version1.6.0 (commit 3c3d0fbf5345f6ca01bb32d81a2d3c73bd2edff0)
at2019-03-27.00:37:59.206079458+0000
.Runtime is
/opt/kata/bin/kata-runtime
.kata-env
Output of "
/opt/kata/bin/kata-runtime kata-env
":Runtime config files
Runtime default config files
Runtime config file contents
Output of "
cat "/etc/kata-containers/configuration.toml"
":Output of "
cat "/opt/kata/share/defaults/kata-containers/configuration.toml"
":Config file
/usr/share/defaults/kata-containers/configuration.toml
not foundKSM throttler
version
Output of "
--version
":systemd service
Image details
Initrd details
No initrd
Logfiles
Runtime logs
No recent runtime problems found in system journal.
Proxy logs
No recent proxy problems found in system journal.
Shim logs
No recent shim problems found in system journal.
Throttler logs
No recent throttler problems found in system journal.
Container manager details
Have
docker
Docker
Output of "
docker version
":Output of "
docker info
":Output of "
systemctl show docker
":No
kubectl
No
crio
Have
containerd
containerd
Output of "
containerd --version
":Output of "
systemctl show containerd
":Output of "
cat /etc/containerd/config.toml
":Packages
No
dpkg
No
rpm
The text was updated successfully, but these errors were encountered: