Restricting what's in your runtime container to precisely what's necessary for your app is a best practice employed by Google and other tech giants that have used containers in production for many years. It improves the signal to noise of scanners (e.g. CVE) and reduces the burden of establishing provenance to just what you need.
Distroless images are very small. The smallest distroless image, gcr.io/distroless/static-debian11, is around 2 MiB. That's about 50% of the size of alpine (~5 MiB), and less than 2% of the size of debian (124 MiB).
Additional information
Distroless image need tools like kubectl-debug to perform troubleshooting in the container. As a side effect, by separating the troubleshooting tools to the image of debug container, we have better toolchain maintainability.
Is there an existing issue for enhancement?
What would you like to be added ?
Why is this needed ?
This repository https://github.com/GoogleContainerTools/distroless elaborates the advantages of using distroless image. The takeaway is quoted below:
Additional information
Distroless image need tools like kubectl-debug to perform troubleshooting in the container. As a side effect, by separating the troubleshooting tools to the image of debug container, we have better toolchain maintainability.