Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

Prologue — Why runtimes are interesting again in 2026

For about ten years after dotCloud's Solomon Hykes unveiled Docker at PyCon US in 2013, the equation "container equals Docker" went mostly unchallenged. That changed in December 2020 when Kubernetes announced dockershim deprecation for 1.20 and then actually removed it in 1.24 in April 2022.

As of May 2026, the default runtime on large clusters is either containerd 2.0 or CRI-O 1.31, and on developer machines Podman 5 and Orbstack are quickly eating into Docker Desktop's share. Meanwhile in multi-tenant SaaS and serverless, gVisor, Kata Containers, and Firecracker MicroVMs have become the standard isolation primitives, and WebAssembly runtimes have entered Kubernetes properly through the runwasi shim.

This guide maps the territory — from the OCI 1.2 specs down through low-level runtimes (runc, crun, youki), high-level runtimes (containerd, CRI-O), daemonless tools (Podman, Buildah, Skopeo), hardened isolation (gVisor, Kata, Firecracker, Cloud Hypervisor), and Wasm runtimes (WasmEdge, Wasmtime, Wasmer, Spin, WasmCloud). It explains who solves which problem and which runtime to choose for which workload.

1. The OCI specs — common ground for every runtime

The Open Container Initiative (OCI) was donated by Docker to the Linux Foundation in June 2015 to standardize the container format. As of May 2026 there are three core specs.

| Spec | Version (May 2026) | What it defines |

| --- | --- | --- |

| image-spec | 1.1 + 1.2 RC | image manifest, config, layer format |

| runtime-spec | 1.2.0 | config.json, lifecycle, ops |

| distribution-spec | 1.1.1 | registry HTTP API |

The key idea — **an OCI image is just a bundle of layers compressed with tar.gz, zstd, or zstd-chunked, and an OCI runtime's only job is to take a config.json plus a root filesystem and produce an isolated process.** Whatever high-level runtime you use, the bottom layer is one of runc, crun, youki, runsc, or kata-runtime.

Keep that picture in mind and the rest of the chapters fall into place.

2. Runtime layers — low-level vs high-level

"Container runtime" gets used in two senses across the industry.

kubelet (CRI client)

│

▼

┌──────────────────────────────┐

│ High-level runtime (CRI) │

│ containerd / CRI-O / cri-dockerd │

└──────────────┬───────────────┘

│ (OCI runtime API)

▼

┌──────────────────────────────┐

│ Low-level runtime (OCI) │

│ runc / crun / youki / runsc / kata-runtime │

└──────────────────────────────┘

- **High-level runtime** — pulls images, unpacks layers, sets up networking and volumes, manages lifecycle. This is what kubelet talks to via the CRI (Container Runtime Interface).

- **Low-level runtime** — configures namespaces, cgroups, capabilities, seccomp, LSMs. It takes a config.json and forks the process.

containerd is high-level and by default calls runc. CRI-O is high-level and defaults to crun. Whenever someone says "we are switching runtimes," always ask which layer they mean.

3. runc 1.2 — the reference OCI runtime

runc is the reference low-level runtime Docker donated to OCI in June 2015. It is written in Go and bundles a library called libcontainer.

The May 2026 stable is 1.2.5. Notable additions over the past two years:

- **CRIU integration** stabilized — checkpoint and restore work more smoothly.

- **idmapped mounts** enabled by default — better rootless container compatibility.

- **systemd cgroup v2** fully supported.

- **Scheduling policy** options — you can request SCHED_DEADLINE and other real-time policies.

runc remains the most widely used OCI runtime and the default in nearly every Kubernetes distribution. The common complaint is that the Go runtime makes startup take 50 to 80 ms per container — for Function-as-a-Service that matters.

4. crun — Red Hat's C implementation, roughly twice as fast

crun is an OCI runtime that Red Hat started in 2018. Its differentiator is that it is **written in C** — no Go runtime startup cost.

Benchmarks vary by environment but typically show:

- Container start time: about 50 percent faster than runc.

- Memory footprint: roughly one third.

- Dependencies: only glibc, vs Go runtime for runc.

crun is the default OCI runtime under OpenShift and Podman, and also the default for CRI-O 1.31. Since crun 1.20 there is a WebAssembly handler that can launch WasmEdge or Wasmtime directly.

5. youki — an OCI runtime rewritten in Rust

youki was started in 2021 by Toru Komatsu, an NTT Data engineer in Japan. It is a Rust-based OCI runtime, with the May 2026 stable at 0.4.x.

People pick it for three reasons:

- **Memory safety** — Rust's borrow checker catches a class of buffer overflow bugs at compile time.

- **Performance** — about 30 percent faster start than runc in typical workloads.

- **Embeddability** — packaged as the libcontainer-rs library, importable by other Rust tooling.

AWS Bottlerocket has shipped builds using youki, and a handful of clouds (Rakuten in Japan, NHN Cloud in Korea) have experimented with it. youki is still not declaring itself production-ready, but the SUSE Rancher side is actively sponsoring development.

6. containerd 2.0 — the CNCF Graduated standard

containerd is the high-level runtime Docker donated to CNCF in 2017. Version 2.0 went GA in September 2024, and the May 2026 stable is 2.1.

Highlights since 2.0:

- **Image Transfer Service** — image pull and push moved into a separate service, so retries and progress reporting are simpler.

- **NRI (Node Resource Interface) 2.0** — plugins can hook into container creation to tweak GPU or CPU pinning dynamically.

- **Sandbox API** is stable — sandbox runtimes like Kata Containers and gVisor integrate through this standard API.

- **runwasi shim** officially supported — WebAssembly modules can be registered as a runtime class.

containerd became the de facto default once Kubernetes 1.24 removed dockershim. AWS EKS, Google GKE, Azure AKS, NHN Cloud Kubernetes, and KT Cloud K-PaaS-TA all default to containerd.

7. CRI-O 1.31 — a lightweight Kubernetes-only runtime

CRI-O is the "OCI runtime for Kubernetes and only Kubernetes" that Red Hat started in 2016. The May 2026 stable is 1.31.

Compared to containerd the positioning is different:

- containerd targets both Docker and Kubernetes users. CRI-O targets only the K8s CRI.

- CRI-O releases match the Kubernetes minor version one-to-one. K8s 1.31 means CRI-O 1.31.

- It has a small memory footprint and simple dependency graph, which is why it is the OpenShift default.

Interesting changes that landed in 2026:

- **Stream isolation** — container log and exec streams run in a separate process so an OOM event does not take everything down.

- **userns auto-mode** — automatic UID mapping for rootless containers.

- **WebAssembly runtime class** officially supported.

Red Hat OpenShift 4.16 ships CRI-O by default, and parts of SK Telecom's 5G MEC and NTT Docomo's clusters run CRI-O too.

8. Podman 5 — daemonless, rootless, and pods

Podman is the "Docker alternative without a daemon" that Red Hat released in 2018. The May 2026 stable is 5.4.

Differentiators:

- **No daemon** — `podman run` fork-execs the container. There is no single-daemon failure mode.

- **Rootless by default** — runs containers with ordinary user privileges using user namespaces plus slirp4netns plus fuse-overlayfs.

- **Pod concept** — multiple containers share an IP and volumes, the same shape as a Kubernetes Pod.

- **Docker CLI compatible** — `alias docker=podman` works for most workflows.

- **podman kube generate** — export a running Pod as Kubernetes YAML.

Combined with Buildah (build only) and Skopeo (inspect and copy images), it forms Red Hat's three-piece set. By 2026 Fedora, RHEL, and Rocky Linux have moved entirely to Podman as the default container tool.

On Mac and Windows, Podman Desktop is gaining share fast — a lot of enterprise users have moved off Docker Desktop because of its paid policy.

9. Docker 27 — still number one on developer machines

Docker Inc. has been charging enterprises since January 2022, yet its share on developer workstations remains the highest. May 2026 stable versions are Docker Engine 27.5 and Docker Desktop 4.40.

Major changes between 2024 and 2026:

- **BuildKit 0.18** — became the default builder. Cache, parallelism, and remote builder support are now standard.

- **Docker Compose v2** — fully replaced the Python v1. Rewritten in Go as the `docker compose` subcommand.

- **Docker Init** — generates Dockerfile, compose, and .dockerignore for a new project.

- **Wasm runtime integration (Tech Preview)** — runs Wasmtime and WasmEdge in an OCI-compatible way.

- **Docker Hub Personal/Pro/Team** tiers — pull rate limits are stricter.

Enterprise users have moved away because of Docker Desktop licensing — over to Podman Desktop, Rancher Desktop, or Orbstack on Mac — but for individual developers and small startups Docker is still number one.

10. gVisor — Google's user-space kernel

gVisor is the user-space kernel sandbox runtime Google announced at KubeCon 2018. The core idea — **the host kernel does not handle syscalls from the container directly. A user-space process called Sentry intercepts them and forwards only a filtered subset.**

container app

│ syscall

▼

Sentry (gVisor user-space kernel, Go)

│ filtered subset

▼

host Linux kernel

Pros:

- **Reduced attack surface** — even if a container-escape 1-day appears, Sentry blocks it.

- **OCI compatible** — the runsc binary implements the OCI runtime interface.

- **Linux compatibility** — most syscalls are simulated so ELF binaries run unchanged.

Cons:

- **Performance overhead** — syscall-heavy workloads are 20 to 50 percent slower. CPU-bound code is largely unaffected.

- **Some syscalls unimplemented** — newer ones like io_uring need a fallback.

Google Cloud Run, App Engine Flexible, and GKE Sandbox are all built on gVisor. Fly.io Machines uses it for some workloads, and Korea's Naver Cloud chose gVisor for multi-tenant function services.

11. Kata Containers 3 — VM-level isolation with container UX

Kata Containers began in 2017 by merging Intel Clear Containers and Hyper.sh runV. The May 2026 stable is 3.6.

The point — **it looks like a container but inside is a real lightweight virtual machine.** Each Pod or container runs in its own KVM VM, and the container process executes inside it.

Supported hypervisors:

- **Firecracker** — AWS's MicroVM, the lightest.

- **Cloud Hypervisor** — the Intel/Cloud Hypervisor community's Rust VMM.

- **QEMU** — most compatible, also the heaviest.

Notable Kata 3.x features:

- **VFIO-AP** — pass through crypto cards on IBM s390x.

- **Confidential Containers** integration — AMD SEV-SNP, Intel TDX, IBM SE.

- **runD shim** integration — a shim contributed by Alibaba Cloud, now in containerd.

Users: parts of Alibaba Cloud's ECI, Yahoo! Japan, parts of Azure Container Instances, and GKE Sandbox (you can pick Kata instead of gVisor).

12. Firecracker 1.10 — the MicroVM behind AWS Lambda

Firecracker is the minimalist VMM AWS unveiled at re:Invent 2018. It is written in Rust and runs on KVM. The May 2026 stable is 1.10.

Design principles:

- **Minimal device model** — virtio-net, virtio-block, virtio-vsock, serial console. No PCI.

- **Sub-125 ms boot** — a 5 MB microVM binary boots into 5 MB of memory.

- **REST API** — an external fc-control plane drives the microVM.

Where it is used:

- **AWS Lambda** backend — used to keep cold starts low.

- **AWS Fargate** for parts of the workload.

- **Fly.io Machines** — global edge containers isolated in microVMs.

- **Kata Containers** as a hypervisor choice.

- **Northflank**, **Koyeb**, and other young PaaS isolate workloads on it.

Most people do not use Firecracker directly — they put a wrapper (Kata, Ignite, Firepilot) on top.

13. Cloud Hypervisor 42 — the other Rust VMM

Cloud Hypervisor is the other Rust VMM Intel started in 2018. Compared to Firecracker it supports a richer device model. The May 2026 stable is 42.

| Item | Firecracker | Cloud Hypervisor |

| --- | --- | --- |

| Goal | minimal boot time | general-purpose VM with richer devices |

| Devices | virtio core only | virtio plus VFIO plus GPU passthrough |

| Live migration | no | yes |

| Used by | Lambda, Fly | Kata option, Edera Protect, Intel TDX |

Edera Protect — a startup founded in 2024 by former etcd maintainers — builds a "sandbox platform that supports both GPU and confidential computing" on top of Cloud Hypervisor.

14. WebAssembly runtimes — entering K8s via runwasi shim

When containerd added official support for the runwasi shim in 2024, WebAssembly modules became deployable as OCI images on Kubernetes.

The three main Wasm runtimes (May 2026):

| Runtime | Owner | Strengths |

| --- | --- | --- |

| WasmEdge 0.14 | CNCF Sandbox | LLM and tensor extensions, K8s integration first |

| Wasmtime 27 | Bytecode Alliance | broadest WASI coverage, reference implementation |

| Wasmer 5.x | Wasmer Inc. | edge first, AOT compile |

Why containers for Wasm:

- **Boot time under 1 ms** — true cold start in sub-millisecond range.

- **Memory under 1 MB** — tens of KB per function.

- **Language-agnostic portability** — Rust, Go, C, Python via Pyodide.

Limitations:

- **WASI is still evolving** — networking and filesystem are not as rich as containers.

- **GPU and hardware access limited** — WASI-NN gives you inference, training is hard.

Wasm-first PaaS like Spin (Fermyon), WasmCloud, and Wasmer Edge are growing on top of this.

15. Confidential Containers — even memory is encrypted

Confidential Containers (CoCo) is a CNCF Sandbox project that started in 2022 and is on track for GA in late 2026. The key idea — **not even the host kernel or hypervisor can read container memory.**

Underlying hardware:

- **AMD SEV-SNP** — Secure Encrypted Virtualization with Secure Nested Paging.

- **Intel TDX** — Trust Domain Extensions, broadly available on 5th-gen Xeons in 2024.

- **Arm CCA** — Confidential Compute Architecture, partial support on Neoverse V3 in 2025.

- **IBM Z SE** — Secure Execution.

Flow:

1. When a Kata Container is launched, the hypervisor creates an SEV-SNP or TDX VM.

2. An attestation server validates the boot measurement.

3. Once validation passes, secrets are injected.

Where it is used: Azure Confidential Containers, IBM Cloud Hyper Protect, and financial-sector compliance workloads in Korea and Japan. Edera Protect aims to extend confidentiality to GPU nodes.

16. Image formats — OCI v1.1 and zstd-chunked

Notable changes to the container image format as of May 2026:

- **OCI image-spec 1.1** — GA in 2024. Artifact manifests are official, so Helm charts, SBOMs, and signatures can live in the same registry.

- **OCI image-spec 1.2 RC** — standardizes compression algorithm negotiation, names zstd-chunked.

- **zstd-chunked** — contributed by Red Hat. Enables partial pulls, with a big payoff for large images. Pulling only the changed 80 MB out of a 1 GB image is now realistic.

- **ORAS (OCI Registry As Storage)** — store arbitrary files, not just container images, in an OCI registry. Push Helm charts, Tekton tasks, AI model weights to docker.io or ghcr.io.

Docker v2.2 (legacy) images are flagged deprecated and most registries will block new pushes within 2026.

17. Local development — Docker Desktop, Podman Desktop, Rancher Desktop, Orbstack

| --- | --- | --- | --- | --- |

Among Mac developers the name that has been heard most often since 2025 is Orbstack. With its own lightweight hypervisor it claims one third the memory and one fifth the startup time of Docker Desktop.

Linux developers do not really need a Desktop tool — install Podman or Docker Engine natively.

18. CI environments — Sysbox, DinD, Kaniko

Exposing host privileges in CI builds and runs is a long-standing headache.

- **Docker-in-Docker (DinD)** — sidecar with the docker:dind image. Simplest, but needs a privileged container.

- **Kaniko** — Google's build tool. Builds a Dockerfile without root and pushes.

- **Buildah / podman build** — the rootless build standard.

- **Sysbox** — runtime from Nestybox (acquired by Docker in 2022). Lets you run systemd and Docker safely inside a container. Open sourced under Apache 2.0 in 2026.

- **BuildKit plus rootless** — the most common combination.

GitHub Actions, GitLab CI, Jenkins, and Tekton have all defaulted to rootless builds as the recommendation in 2026.

19. Serverless — Lambda Firecracker, Fly Machines, Cloud Run gVisor

Isolation backends across the serverless and edge landscape:

| Service | Isolation | Boot time |

| --- | --- | --- |

| AWS Lambda | Firecracker MicroVM | 100 to 300 ms cold |

| AWS Fargate | Firecracker or EC2 | seconds |

| GCP Cloud Run | gVisor | 200 to 500 ms |

| GCP App Engine Flexible | gVisor | seconds |

| Azure Container Instances | Hyper-V Container or Kata | seconds |

| Fly.io Machines | Firecracker | hundreds of ms |

| Northflank | Firecracker plus Cloud Hypervisor | hundreds of ms |

| Koyeb | Firecracker | hundreds of ms |

| Vercel Functions | V8 isolate or AWS Lambda | tens of ms |

| Cloudflare Workers | V8 isolate | 5 ms |

Serverless isolation is converging on two camps — microVMs and V8 isolates. Containers are too heavy, while V8 isolates restrict you to Node.js or Wasm.

20. Korea and Japan — who uses what

**Korea**

- **NHN Cloud** — containerd by default, youki experiments on some nodes. CoCo PoC in progress.

- **KT Cloud** — containerd on top of K-PaaS-TA. CRI-O offered as an option.

- **Naver Cloud** — its own Naver Container Service runs on containerd, with gVisor for multi-tenant functions.

- **SK Telecom** — CRI-O on some 5G MEC nodes, CoCo on the roadmap.

- **Samsung SDS** — Brity Container Platform uses containerd with a Kata option.

**Japan**

- **NTT Data and NTT Communications** — sponsor youki, some CRI-O adoption.

- **Rakuten** — containerd plus Kata for mobile RAN containers.

- **CyberAgent** — containerd in AKE (Adtech Container Engine).

- **Yahoo! Japan and LINE** — Kata for parts of multi-tenant workloads.

- **AWS Tokyo, GCP Tokyo, Azure Tokyo** — same stack as the global regions.

Notably, youki is a Japanese-origin project, which is why Japanese cloud companies sponsor it more visibly.

21. Which runtime to choose — a decision tree

Question 1. What environment?

├─ Kubernetes cluster

│ ├─ Red Hat ecosystem? → CRI-O plus crun

│ └─ otherwise → containerd plus runc

├─ Local dev (Mac)

│ ├─ speed matters → Orbstack

│ ├─ open source first → Podman Desktop

│ └─ maximum compatibility → Docker Desktop

└─ Local dev (Linux) → Podman or Docker Engine

Question 2. How strong does isolation need to be?

├─ general isolation → runc or crun (namespaces plus cgroups)

├─ multi-tenant SaaS → gVisor or Kata

├─ memory protected too → Confidential Containers (Kata plus SEV-SNP/TDX)

└─ fastest boot → Firecracker MicroVM or Wasm

Question 3. Workload shape?

├─ FaaS / short functions → Wasm (WasmEdge, Spin) or Firecracker

├─ long-running services → regular containers (containerd plus runc)

├─ data intensive → regular containers, avoid gVisor if syscall-heavy

└─ AI/ML inference → regular containers plus GPU operator

22. Closing — the runtime landscape in 2026

To summarize as of May 2026:

1. **Cluster default is containerd 2.0** — the default in nearly every Kubernetes distribution.

2. **Red Hat ecosystem is CRI-O plus crun plus Podman** — coherent picks for OpenShift users.

3. **Local dev has diversified** — Docker Desktop, Podman Desktop, Rancher Desktop, and Orbstack coexist.

4. **Multi-tenant goes gVisor or Kata** — depends on the cloud provider.

5. **Serverless goes Firecracker MicroVM or V8 isolate** — containers are too heavy.

6. **Wasm is here for real** — runwasi shim lets it ride the Kubernetes rails.

7. **Confidential Containers should hit GA late 2026** — AMD SEV-SNP and Intel TDX are now mature enough.

8. **Alternative OCI runtimes like youki and crun are growing** — the Rust and C camps are shaking runc from the bottom.

Runtime choice is a triangle of "performance, isolation, compatibility." There is no single right answer. But armed with the map drawn here, you should be able to pin down a corner by the fifth question.

References

1. Open Container Initiative — [https://opencontainers.org/](https://opencontainers.org/)

2. OCI Runtime Specification — [https://github.com/opencontainers/runtime-spec](https://github.com/opencontainers/runtime-spec)

3. OCI Image Specification — [https://github.com/opencontainers/image-spec](https://github.com/opencontainers/image-spec)

4. OCI Distribution Specification — [https://github.com/opencontainers/distribution-spec](https://github.com/opencontainers/distribution-spec)

5. runc — [https://github.com/opencontainers/runc](https://github.com/opencontainers/runc)

6. crun — [https://github.com/containers/crun](https://github.com/containers/crun)

7. youki — [https://github.com/youki-dev/youki](https://github.com/youki-dev/youki)

8. containerd — [https://containerd.io/](https://containerd.io/)

9. CRI-O — [https://cri-o.io/](https://cri-o.io/)

10. Podman — [https://podman.io/](https://podman.io/)

11. Buildah — [https://buildah.io/](https://buildah.io/)

12. Skopeo — [https://github.com/containers/skopeo](https://github.com/containers/skopeo)

13. Docker — [https://www.docker.com/](https://www.docker.com/)

14. BuildKit — [https://github.com/moby/buildkit](https://github.com/moby/buildkit)

15. gVisor — [https://gvisor.dev/](https://gvisor.dev/)

16. Kata Containers — [https://katacontainers.io/](https://katacontainers.io/)

17. Firecracker — [https://firecracker-microvm.github.io/](https://firecracker-microvm.github.io/)

18. Cloud Hypervisor — [https://www.cloudhypervisor.org/](https://www.cloudhypervisor.org/)

19. WasmEdge — [https://wasmedge.org/](https://wasmedge.org/)

20. Wasmtime — [https://wasmtime.dev/](https://wasmtime.dev/)

21. Wasmer — [https://wasmer.io/](https://wasmer.io/)

22. runwasi — [https://github.com/containerd/runwasi](https://github.com/containerd/runwasi)

23. Spin (Fermyon) — [https://www.fermyon.com/spin](https://www.fermyon.com/spin)

24. WasmCloud — [https://wasmcloud.com/](https://wasmcloud.com/)

25. Confidential Containers — [https://github.com/confidential-containers](https://github.com/confidential-containers)

26. Edera Protect — [https://edera.dev/](https://edera.dev/)

27. Kubernetes CRI — [https://kubernetes.io/docs/concepts/architecture/cri/](https://kubernetes.io/docs/concepts/architecture/cri/)

28. Orbstack — [https://orbstack.dev/](https://orbstack.dev/)

29. Rancher Desktop — [https://rancherdesktop.io/](https://rancherdesktop.io/)

30. Sysbox — [https://github.com/nestybox/sysbox](https://github.com/nestybox/sysbox)