That's correct, layers are not part of the spec. It's the caller's responsibility to setup the container bundle (manifest + one or more rootfs directories) so that runC can load it. How that is done is not the concern of runC.

This is by design: it turns out layers, as implemented by Docker, are not the only way to download or assemble a container. The appc specification uses a different, incompatible layer system. Many people like to "docker import" tarballs which bypasses layers entirely. The next version of Docker is gravitating towards pure content-addressable storage and transfer (a-la git), possibly eschewing layers entirely.

runC is not concerned by how you got a particular runnable object. It's only concerned with its final, runnable form. The result is a nicely layered design where different tools can worry about different levels of abstraction.

No expert here, but I would guess the important bit is the "root": value, which in the example points to rootfs. rootfs, I suppose, would be the directory on the host system containing the entire root filesystem that is to be mounted at /. This could be created using overlayfs, or a COW filesystem like btrfs, which would be how you'd achieve layers.

In this way, the notion of layers is external to the container spec.

Again I'm no expert, so corrections welcome.