> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Container Runtime > Explains container runtimes and Docker run flow, detailing containerd, containerd-shim, runc, OCI bundles, and sandbox runtimes like gVisor and Kata Containers Now that we understand sandboxing technologies like gVisor and Kata Containers, this lesson explains how container runtimes are used when deploying containers and what happens under the hood. When you run a container (for example `docker run nginx`), several coordinated steps occur: the client checks for the image, pulls it if necessary, prepares the filesystem, and finally starts the container process using an OCI-compatible runtime. Example: pulling and starting NGINX with Docker ```bash theme={null} $ docker run -d nginx Unable to find image 'nginx:latest' locally latest: Pulling from library/nginx ac2522cc7269: Pull complete 09de04de3c75: Pull complete b0c8a51e6628: Pull complete 08b11a3d692c: Pull complete a0e0e6bcfd2c: Pull complete 4fcb23e29ba1: Pull complete Digest: sha256:b0ea179ab61c789ce759dbe491cc534e293428ad232d00df83ce44bf86261179 Status: Downloaded newer image for nginx:latest 7a4100de26b527713f0f1079308a6432d86fe91509315784d0f0dac109054995 ``` High-level flow when executing `docker run`: 1. The Docker CLI converts your command into a REST API request and sends it to the Docker daemon. 2. The Docker daemon checks whether the requested image exists locally. If not, it pulls the image from the configured registry (Docker Hub by default). 3. Once the image is available, the Docker daemon delegates lifecycle operations to containerd. 4. containerd handles image management, snapshotting, unpacking images, and preparing an OCI-compliant bundle for the container. 5. containerd interacts with a shim (commonly `containerd-shim`) that manages the container process lifecycle and keeps the container running independently of the containerd daemon. 6. The shim invokes an OCI-compliant runtime (default: `runc`) to create and start the container process. 7. The runtime (`runc`) uses kernel primitives such as namespaces and cgroups to create the isolated container environment. Concise conceptual diagram: * Docker CLI → Docker daemon → containerd → containerd-shim → runc → kernel (namespaces, cgroups) runc * `runc` is the reference implementation of the OCI runtime specification and is the default runtime used by containerd and many container engines to create container processes. * Important: `runc` operates on OCI bundles — a filesystem layout containing a `config.json` and a root filesystem. You cannot give an image directly to `runc`; tools like containerd or BuildKit unpack an image to a bundle before invoking `runc`. * Because `runc` adheres to OCI, many tools and runtimes use it by default for broad compatibility. Alternative OCI-compatible runtimes Sandbox-oriented runtimes implement the OCI runtime interface so container engines can select them instead of `runc`: * Kata Containers — typically uses `kata-runtime`. * gVisor — uses `runsc`. Since these runtimes implement the OCI runtime interface, engines like Docker can invoke them in place of `runc` (if the runtime is installed and registered). Examples: run a container with a specific runtime ```bash theme={null} # Run an NGINX container using Kata Containers runtime (name must match daemon config) $ docker run --runtime kata -d nginx # Run an NGINX container using gVisor's runsc (name must match daemon config) $ docker run --runtime runsc -d nginx ``` The `--runtime` option works only if the specified runtime is installed on the host and registered with the container engine (for Docker, configured in `daemon.json` under `runtimes`). If the runtime isn't configured, Docker will report an error. Technical clarifications * containerd is a long-running daemon that manages images, snapshots, and the container lifecycle. It coordinates with a runtime (such as `runc`) through shims. * The shim (`containerd-shim`) keeps the container process alive and provides a stable endpoint for I/O and exit status even if containerd crashes or restarts. * Container engines that orchestrate pull/unpack steps (for example, Docker) generally rely on containerd + an OCI runtime to start the container process. Quick reference table: components and responsibilities | Component | Primary responsibility | Example / notes | | -: | - | - | | Docker CLI | Converts commands to API requests | `docker run nginx` | | Docker daemon | Orchestrates image pull and delegates to containerd | Configured by `daemon.json` | | containerd | Image management, snapshotting, bundle preparation | Long-running daemon | | containerd-shim | Manages container process lifecycle independent of containerd | Keeps process alive on daemon restart | | OCI runtime | Creates the container process (namespaces, cgroups) | Examples: `runc`, `runsc`, `kata-runtime` | | OCI bundle | Filesystem layout with `config.json` and rootfs | Used by `runc` and other runtimes | Recap — example using a specific runtime ```bash theme={null} # Example: run a container with the Kata runtime (requires runtime installed and registered) $ docker run --runtime kata -d nginx 6d9994bf88bc3538f23db7aa4b01133e3d58dcbcb0e0d5d1a44c31a5ae06fad0 ``` What’s next We will cover how to install gVisor and configure it as a runtime for container engines in the next lesson. For background reading, see the OCI runtime specification and documentation for containerd, gVisor, and Kata Containers. Links and references * [Docker — Learn KodeKloud course page](https://learn.kodekloud.com/user/courses/docker-training-course-for-the-absolute-beginner) * OCI runtime specification: [https://github.com/opencontainers/runtime-spec](https://github.com/opencontainers/runtime-spec) * containerd: [https://containerd.io/](https://containerd.io/) * gVisor: [https://gvisor.dev/](https://gvisor.dev/) * Kata Containers: [https://katacontainers.io/](https://katacontainers.io/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.