필사 모드: コンテナランタイム代替 2026 完全ガイド - containerd・CRI-O・Podman・runc・gVisor・Kata Containers・youki・WasmEdge・Firecracker 詳細解説

プロローグ — 2026 年のランタイムが再び面白い理由

2013 年に dotCloud の Solomon Hykes が PyCon US で Docker を発表してから約 10 年間、「コンテナ = Docker」という等式はほぼ疑われなかった。しかし 2020 年 12 月に Kubernetes が 1.20 から dockershim deprecation を予告し、2022 年 4 月の 1.24 で実際に削除すると風景は変わった。

2026 年 5 月現在、大規模クラスタの既定ランタイムは containerd 2.0 もしくは CRI-O 1.31 であり、ローカル開発でも Podman 5 と Orbstack が Docker Desktop のシェアを急速に奪っている。マルチテナント SaaS とサーバーレス領域では gVisor・Kata Containers・Firecracker MicroVM が標準的な隔離手段として定着し、WebAssembly ランタイムは runwasi shim を通じて Kubernetes に正式に入り込んだ。

本稿は OCI 1.2 仕様から、低レベルランタイム(runc・crun・youki)、高レベルランタイム(containerd・CRI-O)、デーモンレス(Podman・Buildah・Skopeo)、強隔離(gVisor・Kata・Firecracker・Cloud Hypervisor)、そして Wasm ランタイム(WasmEdge・Wasmtime・Wasmer・Spin・WasmCloud)までの地図を描き、誰がどの問題を解いているのか、どのワークロードにどのランタイムを選ぶべきかを一望する。

1. OCI 仕様 — すべてのランタイムの共通基盤

Open Container Initiative(OCI)は、コンテナフォーマットを標準化するために 2015 年 6 月に Docker が Linux Foundation 配下に寄贈したプロジェクトである。2026 年 5 月時点の中核仕様は次の 3 つ。

| 仕様 | バージョン(2026.5) | 何を定義するか |

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

| image-spec | 1.1 + 1.2 RC | イメージマニフェスト、config、レイヤー形式 |

| runtime-spec | 1.2.0 | config.json、ライフサイクル、ops |

| distribution-spec | 1.1.1 | レジストリ HTTP API |

要点 — **OCI イメージは tar.gz・zstd・zstd-chunked で圧縮されたレイヤーの集合に過ぎず、OCI ランタイムの役目は config.json と rootfs を受け取って隔離されたプロセスを生成することだけ。** どんな高レベルランタイムを使っても、最下層は runc・crun・youki・runsc・kata-runtime のいずれかである。

この絵を頭に置けば、以降の章の住み分けが明確になる。

2. ランタイム階層 — 低レベルと高レベル

業界で「コンテナランタイム」と言うとき、二つの意味で使われる。

kubelet (CRI クライアント)

│

▼

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

│ 高レベルランタイム (CRI) │

│ containerd / CRI-O / cri-dockerd │

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

│ (OCI runtime API)

▼

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

│ 低レベルランタイム (OCI) │

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

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

- **高レベルランタイム** — イメージ pull、レイヤー unpack、ネットワーク・ボリュームのセットアップ、ライフサイクル管理。kubelet が CRI(Container Runtime Interface)で対話する相手はこれ。

- **低レベルランタイム** — namespaces・cgroups・capabilities・seccomp・LSM の設定。config.json を受け取りプロセスを fork する。

containerd は高レベルだが既定で runc を呼ぶ。CRI-O は高レベルで既定は crun。誰かが「ランタイムを切り替える」と言うときは、どの階層を切り替えるのかを必ず明示してほしい。

3. runc 1.2 — リファレンスとなる OCI ランタイム

runc は、2015 年 6 月に Docker が OCI に寄贈したリファレンス低レベルランタイムである。Go で書かれ、libcontainer というライブラリを内包する。

2026 年 5 月の stable は 1.2.5。この 2 年の主な変更点。

- **CRIU integration** の安定化 — チェックポイント・復元がより滑らかに。

- **idmapped mounts** の既定有効化 — rootless コンテナ互換性が向上。

- **systemd cgroup v2** の完全サポート。

- **scheduling policy** オプション追加 — SCHED_DEADLINE のようなリアルタイムスケジューラを指定可能。

runc は依然として最も広く使われている OCI ランタイムであり、Kubernetes ディストリビューションの大多数が既定値とする。ただし Go ランタイム起動コストのためコンテナ起動に 50〜80ms かかる点が欠点として頻繁に挙げられる。Function-as-a-Service ではこの 50ms も無視できない。

4. crun — Red Hat の C 実装、runc の約 2 倍速

crun は Red Hat が 2018 年に開始した OCI ランタイム。差別点は **C で書かれていること** — Go ランタイムの起動コストがない。

ベンチマークは環境次第だが、一般的には次の傾向がある。

- コンテナ起動時間:runc 比で約 50% 高速。

- メモリフットプリント:約 1/3。

- 依存:glibc 程度で済む。runc は Go ランタイムを含む。

OpenShift と Podman の既定 OCI ランタイムであり、CRI-O 1.31 の既定でもある。crun 1.20 以降は WebAssembly ハンドラを通じて WasmEdge・Wasmtime を直接起動する機能も入った。

5. youki — Rust で書き直された OCI ランタイム

youki は、日本の NTT データのエンジニア小松渉が 2021 年に開始した Rust ベースの OCI ランタイムである。2026 年 5 月の stable は 0.4.x。

採用理由は通常次の三つ。

- **メモリ安全性** — Rust の borrow checker により、バッファオーバーフロー類のバグがコンパイル時に捕まる。

- **性能** — runc 比で約 30% 高速な起動。

- **組み込み可能** — libcontainer-rs として Rust ライブラリ化されており、他ツールから import 可能。

AWS Bottlerocket は一部ビルドで youki を採用し、日本の楽天や韓国の NHN Cloud でも実験的導入事例がある。youki はまだ自身を production-ready とは謳っていないが、SUSE Rancher 陣営が積極的にスポンサーしている。

6. containerd 2.0 — CNCF Graduated の標準

containerd は、Docker が 2017 年に CNCF に寄贈した高レベルランタイム。2.0 は 2024 年 9 月に GA、2026 年 5 月の stable は 2.1。

主な変化(2.0 基準)。

- **Image Transfer Service** — イメージ pull/push を別サービスに分離し、リトライと進捗監視が単純化。

- **NRI(Node Resource Interface)2.0** — プラグインがコンテナ生成時点で hook を挟み、GPU・CPU pinning を動的に調整可能。

- **Sandbox API** が stable — Kata Containers や gVisor のような sandbox ランタイムの統合が標準 API として定着。

- **runwasi shim** を正式サポート — WebAssembly モジュールを runtime class として登録し実行可能。

Kubernetes 1.24 で dockershim が削除されてから、containerd は事実上のデフォルトになった。AWS EKS、Google GKE、Azure AKS、NHN Cloud K8s、KT Cloud K-PaaS-TA はいずれも containerd を既定とする。

7. CRI-O 1.31 — Kubernetes 専用の軽量ランタイム

CRI-O は、2016 年に Red Hat が開始した「Kubernetes のためだけの OCI ランタイム」である。2026 年 5 月の stable は 1.31。

containerd と比較するとポジショニングが異なる。

- containerd は Docker 用・K8s 用の両方を狙う。CRI-O は K8s CRI のみ。

- CRI-O は Kubernetes のマイナーバージョン(1.x)と 1 対 1 でリリースされる。K8s 1.31 → CRI-O 1.31。

- メモリフットプリントが小さく依存グラフが単純なため、OpenShift の既定値となっている。

2026 年に入った興味深い変更点。

- **stream isolation** — コンテナのログ・exec ストリームを別プロセスに分離し、OOM の波及を遮断。

- **userns auto-mode** — rootless コンテナ用の UID マッピングの自動化。

- **WebAssembly runtime class** の正式サポート。

Red Hat OpenShift 4.16 から既定は CRI-O であり、韓国の SK テレコム 5G MEC や日本の NTT ドコモのクラスタの一部も CRI-O を採用している。

8. Podman 5 — デーモンレス、ルートレス、そして Pod

Podman は、Red Hat が 2018 年に発表した「デーモンなしの Docker 代替」である。2026 年 5 月の stable は 5.4。

差別点。

- **デーモンなし** — `podman run` は fork-exec でコンテナを起動する。デーモンクラッシュのような単一障害点がない。

- **ルートレス既定** — 一般ユーザ権限でコンテナ実行。user namespace + slirp4netns + fuse-overlayfs の組合せ。

- **Pod 概念** — Kubernetes の Pod のように複数コンテナを束ねて単一の IP・ボリュームを共有。

- **Docker CLI 互換** — `alias docker=podman` がほぼそのまま動く。

- **podman kube generate** — 実行中の Pod を Kubernetes YAML として export。

Buildah(ビルド専用)、Skopeo(イメージ検査・コピー)と合わせて Red Hat 生態系の三点セット。2026 年時点で Fedora・RHEL・Rocky Linux の既定コンテナツールは完全に Podman へ移行した。

Mac/Windows では Podman Desktop がシェアを急伸中。Docker Desktop の有料化に反発した企業ユーザの移行が多い。

9. Docker 27 — 依然として開発者ワークステーション 1 位

Docker Inc. は 2022 年 1 月から大企業向けに有料化を進めているが、開発者ワークステーションのシェアは依然最大である。2026 年 5 月の stable は Docker Engine 27.5、Docker Desktop 4.40。

2024〜2026 の主な変化。

- **BuildKit 0.18** — 既定のビルダとして統合。キャッシュ・並列・remote builder のサポートが標準化。

- **Docker Compose v2** — Python 実装の v1 を完全に置き換え。Go で再実装され `docker compose` サブコマンド。

- **Docker Init** — 新規プロジェクトの Dockerfile・compose・.dockerignore を自動生成。

- **Wasm ランタイム統合(Tech Preview)** — Wasmtime・WasmEdge を OCI 互換で実行。

- **Docker Hub Personal/Pro/Team** の分離 — pull rate limit がより厳格に。

大企業ユーザは Docker Desktop のライセンス費用を理由に Podman Desktop・Rancher Desktop・Orbstack(Mac)へ移行する例が多いが、個人開発者やスタートアップでは依然として Docker が 1 位だ。

10. gVisor — Google のユーザ空間カーネル

gVisor は、2018 年に KubeCon で Google が発表した「ユーザ空間カーネル」ベースの sandbox ランタイムである。核となる発想は — **コンテナ内の syscall をホストカーネルが直接処理せず、Sentry というユーザ空間プロセスが横取りして必要分だけホストへ転送する。**

コンテナアプリ

│ syscall

▼

Sentry (gVisor ユーザ空間カーネル, Go)

│ filtered subset

▼

ホスト Linux カーネル

長所。

- **攻撃面の縮小** — コンテナ脱出 1-day が見つかっても Sentry が遮断する。

- **OCI 互換** — runsc バイナリが OCI ランタイムインターフェースをそのまま実装。

- **Linux 互換性** — 多くの syscall を模倣するため ELF バイナリがほぼそのまま動く。

短所。

- **性能オーバーヘッド** — syscall heavy なワークロードでは 20〜50% 遅い。CPU bound にはほぼ影響なし。

- **一部 syscall 未実装** — io_uring のような新しい syscall は fallback が必要。

Google Cloud Run、App Engine Flexible、GKE Sandbox はいずれも gVisor 基盤。Fly.io Machines の一部ワークロードや、韓国の Naver Cloud のマルチテナント関数サービスでも採用されている。

11. Kata Containers 3 — VM 隔離・コンテナ UX

Kata Containers は、2017 年に Intel Clear Containers と Hyper.sh runV を統合して始まったプロジェクトである。2026 年 5 月の stable は 3.6。

要点 — **見た目はコンテナでも中身は本物の軽量仮想マシン。** Pod またはコンテナごとに別の KVM VM が立ち上がり、その中でコンテナプロセスが動く。

対応ハイパーバイザ。

- **Firecracker** — AWS の MicroVM、最も軽量。

- **Cloud Hypervisor** — Intel/Cloud Hypervisor コミュニティの Rust VMM。

- **QEMU** — 互換性が最も高く、最も重い。

2026 年時点の Kata 3.x の主な機能。

- **VFIO-AP** — IBM s390x で暗号カードのパススルー。

- **Confidential Containers** 統合 — AMD SEV-SNP・Intel TDX・IBM SE をサポート。

- **runD shim** 統合 — Alibaba Cloud が貢献した shim が containerd に取り込まれた。

採用先:Alibaba Cloud の ECI の一部、Yahoo! Japan、Microsoft Azure Container Instances の一部、GKE Sandbox(gVisor の代わりに Kata を選択可能)。

12. Firecracker 1.10 — AWS Lambda を支える MicroVM

Firecracker は、AWS が 2018 年の re:Invent で発表したミニマリスト VMM である。Rust で書かれ、KVM 上で動く。2026 年 5 月の stable は 1.10。

設計原則。

- **最小限のデバイスモデル** — virtio-net、virtio-block、virtio-vsock、シリアルコンソールのみ。PCI もない。

- **125ms 未満の起動** — 5MB の microVM バイナリが 5MB のメモリで起動。

- **REST API** — 外部の fc-control plane が microVM を操作。

主な用途。

- **AWS Lambda** バックエンド — cold start を抑えるため。

- **AWS Fargate** の一部ワークロード。

- **Fly.io Machines** — グローバルエッジのコンテナを microVM で隔離。

- **Kata Containers** のハイパーバイザ選択肢。

- **Northflank**、**Koyeb** など新興 PaaS の隔離バックエンド。

Firecracker は直接使うより、その上に wrapper(Kata、Ignite、Firepilot)を載せるのが一般的である。

13. Cloud Hypervisor 42 — Rust 陣営のもう一つの VMM

Cloud Hypervisor は、Intel が 2018 年に開始したもう一つの Rust ベース VMM である。Firecracker と比べてより幅広いデバイスモデルをサポートする。2026 年 5 月の stable は 42。

| 項目 | Firecracker | Cloud Hypervisor |

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

| 設計目標 | 最小起動時間 | 汎用 VM、より豊富なデバイス |

| デバイス | virtio コアのみ | virtio + VFIO + GPU パススルー |

| Live migration | 非対応 | 対応 |

| 採用先 | Lambda、Fly | Kata オプション、Edera Protect、Intel TDX |

Edera Protect — 2024 年に etcd 出身者が立ち上げたスタートアップ — は「GPU と confidential computing を同時にサポートする sandbox プラットフォーム」を Cloud Hypervisor 上に構築している。

14. WebAssembly ランタイム — runwasi shim で K8s に進入

2024 年に containerd が runwasi shim を正式サポートして以降、WebAssembly モジュールも OCI イメージとして Kubernetes にデプロイ可能になった。

代表的な Wasm ランタイム 3 つ(2026.5)。

| ランタイム | 開発元 | 強み |

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

| WasmEdge 0.14 | CNCF Sandbox | LLM・テンソル拡張、K8s 統合を優先 |

| Wasmtime 27 | Bytecode Alliance | 最も広範な WASI サポート、参照実装 |

| Wasmer 5.x | Wasmer Inc. | edge first、AOT コンパイル |

WebAssembly コンテナの長所。

- **起動時間 < 1ms** — 真の cold start が 1 ミリ秒未満。

- **メモリ < 1MB** — 関数あたり数十 KB。

- **言語非依存ポータビリティ** — Rust・Go・C・Python(Pyodide)すべて可能。

短所。

- **WASI 標準がまだ進化中** — ネットワーク・ファイルシステムがコンテナほど豊富でない。

- **GPU・ハードウェアアクセス制限** — WASI-NN で推論はできるが、学習は困難。

Spin(Fermyon)・WasmCloud・Wasmer Edge のような Wasm-first PaaS がこの上で育っている。

15. Confidential Containers — メモリまで暗号化

Confidential Containers(CoCo)は、2022 年に開始した CNCF Sandbox プロジェクトで、2026 年後半に GA 予定。核心は — **ホストカーネルやハイパーバイザですらコンテナメモリを読めない。**

基盤ハードウェア。

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

- **Intel TDX** — Trust Domain Extensions、2024 年の Xeon 第 5 世代から本格化。

- **Arm CCA** — Confidential Compute Architecture、2025 年の Neoverse V3 で一部対応。

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

流れ。

1. Kata Container を起動する際、ハイパーバイザが SEV-SNP または TDX VM を作成。

2. attestation サーバが起動時の測定値を検証。

3. 検証通過後に secret を注入。

採用先:Azure Confidential Containers、IBM Cloud Hyper Protect、そして韓国・日本の金融コンプライアンスワークロード。Edera Protect は GPU ノードまで confidential 化する野心で進行中。

16. イメージ形式 — OCI v1.1 と zstd-chunked

2026 年 5 月時点のコンテナイメージ形式の主な進化。

- **OCI image-spec 1.1** — 2024 年 GA。artifact manifest が正式サポートされ、Helm chart・SBOM・署名を同じレジストリに格納可能。

- **OCI image-spec 1.2 RC** — 圧縮アルゴリズム交渉を標準化、zstd-chunked を明示。

- **zstd-chunked** — Red Hat が貢献。partial pull が可能になり大規模イメージで大きな効果。1GB のイメージから変更された 80MB のみを受け取るシナリオが現実的に。

- **ORAS(OCI Registry As Storage)** — コンテナイメージ以外の任意ファイルも OCI レジストリに格納。Helm chart、Tekton task、AI モデル weights を docker.io や ghcr.io に push 可能。

Docker v2.2(legacy)イメージは deprecated 表示済みで、2026 年内に多くのレジストリで新規 push が遮断される予定。

17. ローカル開発 — Docker Desktop・Podman Desktop・Rancher Desktop・Orbstack 比較

| ツール | バックエンド | ライセンス | 強み | 弱み |

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

| Docker Desktop | dockerd + Linux VM | 有料(大企業) | 最広範な互換性 | 重く高価 |

| Podman Desktop | Podman + Linux VM | オープンソース | デーモンレス、マルチエンジン | UI が後発 |

| Rancher Desktop | containerd/dockerd + Lima | オープンソース | K8s 内蔵 | メモリ消費が大きい |

| Orbstack (Mac only) | containerd + 独自仮想化 | 有料(個人無料) | 非常に高速で軽量 | macOS 限定 |

| Colima | Lima + containerd/dockerd | オープンソース | CLI フレンドリ | UI なし |

Mac 開発者のあいだで 2025 年から最もよく聞かれる名前は Orbstack。独自実装の軽量ハイパーバイザにより、Docker Desktop 比でメモリ 1/3、起動時間 1/5 を謳う。

Linux 開発者には Desktop ツールは特に不要 — ネイティブで Podman または Docker Engine を入れれば済む。

18. CI 環境 — Sysbox・DinD・Kaniko

CI でコンテナをビルド・実行するときの「ホスト権限の露出」は長年の悩み。

- **Docker-in-Docker(DinD)** — docker:dind イメージを sidecar として立てる。最も簡単だが privileged コンテナが必要。

- **Kaniko** — Google 製のビルドツール。root 権限なしで Dockerfile をビルドして push。

- **Buildah / podman build** — rootless ビルドの標準。

- **Sysbox** — Nestybox(2022 年 Docker 買収)製のランタイム。コンテナ内で systemd・Docker を安全に動かせる。2026 年に Apache 2.0 でオープンソース化。

- **BuildKit + rootless** — 最も一般的な組合せ。

GitHub Actions・GitLab CI・Jenkins・Tekton のすべてが 2026 年に rootless ビルドを既定推奨へ移行した。

19. サーバーレス — Lambda Firecracker・Fly Machines・Cloud Run gVisor

サーバーレス/エッジ陣営の隔離バックエンドマッピング。

| サービス | 隔離方式 | 起動時間 |

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

| AWS Lambda | Firecracker MicroVM | 100〜300ms (cold) |

| AWS Fargate | Firecracker または EC2 | 数秒 |

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

| GCP App Engine Flexible | gVisor | 数秒 |

| Azure Container Instances | Hyper-V Container または Kata | 数秒 |

| Fly.io Machines | Firecracker | 数百ms |

| Northflank | Firecracker + Cloud Hypervisor | 数百ms |

| Koyeb | Firecracker | 数百ms |

| Vercel Functions | V8 isolate または AWS Lambda | 数十ms |

| Cloudflare Workers | V8 isolate | 5ms |

サーバーレスの隔離モデルは microVM と V8 isolate の二陣営に収束しつつある。コンテナは重すぎ、V8 isolate は Node.js・WASM に制限される、というトレードオフ。

20. 韓国・日本陣営 — 誰が何を使っているか

**韓国**

- **NHN Cloud** — containerd を既定、一部ノードで youki 実験。Confidential Container の PoC が進行中。

- **KT Cloud** — K-PaaS-TA 上で containerd。CRI-O オプションも提供。

- **Naver Cloud** — 独自コンテナサービス NCS に containerd、マルチテナント関数には gVisor。

- **SK テレコム** — 5G MEC の一部ノードで CRI-O、Confidential Container 導入計画。

- **Samsung SDS** — 社内 Brity Container Platform が containerd と Kata オプション。

**日本**

- **NTT データ / NTT コミュニケーションズ** — youki をスポンサー、CRI-O も一部導入。

- **楽天** — モバイル RAN のコンテナに containerd + Kata。

- **サイバーエージェント** — AKE(Adtech Container Engine)で containerd。

- **ヤフー / LINE** — マルチテナントの一部で Kata。

- **AWS 東京 / GCP 東京 / Azure 東京** — グローバルと同一スタック。

注目すべきは youki が日本発のプロジェクトであり、日本のクラウド企業によるスポンサーが手厚いという点だ。

21. どのランタイムを選ぶか — 意思決定ツリー

質問 1. どの環境?

├─ Kubernetes クラスタ

│ ├─ Red Hat 生態系? → CRI-O + crun

│ └─ それ以外 → containerd + runc

├─ ローカル開発 (Mac)

│ ├─ 速さ重視 → Orbstack

│ ├─ オープンソース優先 → Podman Desktop

│ └─ 互換性最優先 → Docker Desktop

└─ ローカル開発 (Linux) → Podman または Docker Engine

質問 2. 隔離はどれくらい強く?

├─ 一般的な隔離 → runc / crun (namespaces + cgroups)

├─ マルチテナント SaaS → gVisor または Kata

├─ メモリも保護 → Confidential Containers (Kata + SEV-SNP/TDX)

└─ 最速起動 → Firecracker MicroVM または Wasm

質問 3. ワークロード特性?

├─ FaaS / 短命関数 → Wasm (WasmEdge, Spin) または Firecracker

├─ 長時間稼働サービス → 通常コンテナ (containerd + runc)

├─ データ集約 → 通常コンテナ、syscall heavy なら gVisor を避ける

└─ AI/ML 推論 → 通常コンテナ + GPU operator

22. むすび — 2026 年のランタイム風景

2026 年 5 月時点を整理すると次のとおり。

1. **クラスタ標準は containerd 2.0** — Kubernetes ディストリビューション大多数の既定。

2. **Red Hat 生態系は CRI-O + crun + Podman** — OpenShift ユーザにとって一貫した選択。

3. **ローカル開発は多様化** — Docker Desktop、Podman Desktop、Rancher Desktop、Orbstack が並走。

4. **マルチテナントは gVisor または Kata** — クラウド事業者によって異なる。

5. **サーバーレスは Firecracker MicroVM または V8 isolate** — コンテナは重すぎる。

6. **Wasm が本格進入を開始** — runwasi shim のおかげで K8s に正規ルートで入れる。

7. **Confidential Containers は 2026 年後半に GA 見込み** — AMD SEV-SNP・Intel TDX が十分成熟。

8. **youki・crun のような代替 OCI ランタイムが育ち中** — Rust・C 陣営が下から runc を揺さぶる。

ランタイム選択は「性能 vs 隔離 vs 互換性」の三角形である。唯一の答えはない。しかし本稿の地図を持っていけば、どの頂点に向かうかを 5 番目の質問あたりで決められるはずだ。

参考資料 (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)