-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Images generated with kaniko are larger than images generated with docker #2261
Comments
I've managed to bring the image size down to basically the same size as the one obtained with plain This fixed it, right before the first line
|
I have the same issue and I am sure that my .git folder is not going to double the image size. |
I have been facing the same issue. The image size difference was huge for me. I also don't think it's the .git that is making the image size inflate. My guess it that the image built by kaniko is pushing layers from builder stage too. I had reported this issue separately over #2768 . Docker file
screenshot from image repository. First image is built by kaniko while the later one was built by docker. |
I have been facing the same issue too and I agree with @jaskeerat789 : Pretty sure it's related to multistage builds and pushing layers of builder stage. We're using Gitlab CI and cannot push artifact because .tar image is bigger than 1000MB. |
Yep, the same problem. Any changes here? |
We're having the same issue. Is there anything we could do about this? |
Same issue here. |
Running into this distributing a compiled and compressed binary package in a kaniko-in-docker CI environment. The binary is ~100MB. DetailsDuring a separate compilation stage in Gitlab's CI, I generate ~5GB of stuff. Then, a compressed binary archive is built, and all of the uncompressed binary material is removed. In the next stage, Kaniko is used to build an image containing only the package. The dockerfile copies the package into the build context, and sets the entry point. That is it. The total size in a pure docker local build is ~220MB = size(base_image) + size(package). However, the Kaniko image size is 1.49GB in the registry. Perhaps more revealing, when pulling the registry image down, a 5Gb layer is downloaded for some reason, which is approximately the size of the entire output of the compilation process. If I had to guess, Kaniko is somehow including layers outside the scope of the final image. Why I wound up hereI found I could not successfully perform a mutli-stage build in Kaniko. In the multi-stage build, I compiled the package in a build image, and copied only the compressed binary to the final image. Kaniko hit the OOM killer during the filesystem snapshot with 16GB of memory. This didn't make sense at the time, since I build the image locally with only 10GB. So I split it apart into a compile stage, and separate build stage. SummaryWhat it looks like from my perspective, with a grain of salt since I am new to Kaniko, is one or a few similar underlying bugs related to snapshotting and/or manifest inclusion might be causing the large image sizes in both multi-stage builds and single builds in a CI pipeline with prior work in a docker-managed filesystem (as in when you are building with Kaniko inside of a running docker container). I have a feeling if I could somehow spawn a fresh file system with only the binary in it during CI, and I could run Kaniko in a native system rather than in docker, Kaniko would build an image that was the expected size. |
the same problem. Any changes here? |
Hello everybody,
I've recently started using kaniko for my CI/CD pipelines and I've found that docker images generated with kaniko are larger (sometimes noticeably larger) than images generated with raw docker.
I've put together a small Dockerfile similar to some of the stuff we use: Ubuntu with a conda installation and a custom environment.
The docker image was built and pushed like this (where
$myregistry
is the URL to our local docker registry):The kaniko image was build and pushed like this within a
.gitlab-ci.yml
file. The--compressed-caching=false
flag is needed due to memory constraints:In the Gitlab web interface I can see that both images have different sizes:
dockerpoc
: 897.92 MiBkanikopoc
: 1005.27 MiBIf I download both images and save them to a tar file, I can still see local differences, but smaller:
For other images that we're using, that are considerably bigger, the difference is also larger:
I was wondering if this effect is caused by some internal kaniko mechanics. Otherwise, is there any flag I could enable on our side to make the final images smaller?
The files
Dockerfile-poc
andenvironment.yaml
can be found here: https://gist.github.com/rinze/0d78263d480526c8cb3ab90aa0fc3e6aTriage Notes for the Maintainers
--cache
flagThe text was updated successfully, but these errors were encountered: