They don't even contain a kernel - Docker containers use the host kernel. Container runtimes based on VMs like Firecracker's firecracker-containerd typically supply the kernel themselves.

Do you happen to know how the scratch containers differ from googles distroless containers?

I’ve been using them (distroless) with great success for my Rust applications.

Scratch is blank. Distroless includes some Debian components that removes a bunch of "gotchas" that some people relying on scratch run into.

static has: ca-certificates, /etc/passwd, /tmp directory, tzdata

base has: glibc, libssl, openssl

https://github.com/GoogleContainerTools/distroless/tree/main...

distroless static (the smallest one, https://github.com/GoogleContainerTools/distroless/tree/main...)

is about 4 MB.

It contains things like:

   /usr/share/zoneinfo/<timezones>

   /etc/ssl/certs/ca-certificates.crt

   /etc/debian_version

... not much else really.

On the other hand, scratch is a special image that contains literally nothing, 0 bytes. Docker doesn't have to talk to the network to download it, it doesn't have to be built, it's just a tarball of nothing.

scratch is thus infinitely smaller than distroless since it has no size.

It's also not suitable for rust since rust applications will commonly link against openssl for tls, against a libc implementation for things like network operations and threads, and so on.

Rust can link to rustls instead of openssl, musl targets are very convenient (and can statically link musl), and https://crates.io/crates/trust-dns-resolver can be used instead of doing dns via libc

Because of such tooling / ecosystem, it's more convenient to use scratch from Rust than from most languages (including C)