컨테이너 런타임 대안 2026 완벽 가이드 - containerd · CRI-O · Podman · runc · gVisor · Kata Containers · youki · WasmEdge · Firecracker 심층 분석

프롤로그 — 2026년 런타임이 다시 흥미로워진 이유

2013년 dotCloud의 Solomon Hykes가 PyCon US에서 Docker를 공개한 뒤 십 년 동안, "컨테이너 = 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 스펙부터 low-level 런타임(runc · crun · youki), high-level 런타임(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월 현재 세 가지 핵심 스펙이 있다.

핵심 메시지 — OCI 이미지는 tar.gz·zstd·zstd-chunked로 압축된 레이어들의 모음이고, OCI 런타임은 config.json + rootfs를 입력받아 격리된 프로세스를 만드는 책임만 진다. 그 위에 어떤 high-level 런타임을 쓰든, 결국 가장 아래 단계는 OCI 런타임 바이너리(runc, crun, youki, runsc, kata-runtime 중 하나)다.

이 그림을 머리에 두면 나머지 챕터의 구분이 명확해진다.

2장 · 런타임 계층 — Low-level vs High-level

업계에서 "컨테이너 런타임"이라는 말은 두 가지 의미로 쓰인다.

                  kubelet (CRI 클라이언트)
                       │
                       ▼
        ┌──────────────────────────────┐
        │  High-level 런타임 (CRI)      │
        │  containerd · CRI-O · cri-dockerd │
        └──────────────┬───────────────┘
                       │ (OCI runtime API)
                       ▼
        ┌──────────────────────────────┐
        │  Low-level 런타임 (OCI)       │
        │  runc · crun · youki · runsc · kata-runtime │
        └──────────────────────────────┘

• High-level 런타임 — 이미지 pull, 레이어 unpack, 네트워크/볼륨 세팅, lifecycle 관리. 이게 kubelet의 CRI(Container Runtime Interface) 짝꿍이다.
• Low-level 런타임 — namespaces·cgroups·capabilities·seccomp·LSM 설정. config.json만 받아서 프로세스 fork한다.

containerd는 high-level인데 안에서 기본으로 runc를 호출한다. CRI-O는 high-level인데 기본은 crun이다. 사용자가 "런타임을 바꾼다"고 할 때 어느 층을 바꾸는 건지 늘 명시해야 혼선이 없다.

3장 · runc 1.2 — 레퍼런스 OCI 런타임

runc는 Docker가 2015년 6월 OCI에 기증한 reference low-level runtime이다. Go로 짜였고 libcontainer라는 라이브러리를 묶고 있다.

2026년 5월 stable은 1.2.5. 주요 변화는:

• 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보다 두 배 빠른

crun은 Red Hat이 2018년에 시작한 OCI 런타임. 핵심 차별점은 C로 짰다는 것 — Go 런타임 로딩 비용이 없다.

벤치마크 결과는 환경에 따라 다르지만 일반적으로:

• 컨테이너 시작 시간: runc 대비 약 50% 빠름.
• 메모리 풋프린트: 약 1/3.
• 의존성: glibc 정도만 있으면 됨, runc는 Go runtime 포함.

OpenShift와 Podman의 기본 OCI 런타임이고, CRI-O 1.31의 기본값이기도 하다. crun 1.20부터는 WebAssembly 핸들러를 통해 WasmEdge·Wasmtime을 직접 launching하는 기능도 들어갔다.

5장 · youki — Rust로 다시 짠 OCI 런타임

youki는 일본 NTT 데이터 엔지니어 Toru Komatsu가 2021년에 시작한 Rust 기반 OCI 런타임이다. 2026년 5월 stable은 0.4.x.

선택 이유는 보통 세 가지:

• Memory safety — Rust의 borrow checker로 buffer overflow 클래스 버그가 컴파일타임에 잡힌다.
• Performance — runc 대비 약 30% 빠른 시작.
• Embeddability — libcontainer 같은 Rust 라이브러리(libcontainer-rs)로 분리되어 있어 다른 도구에서 import 가능.

AWS Bottlerocket이 일부 빌드에서 youki를 채택했고, 일본 라쿠텐과 한국 NHN Cloud에서도 실험적으로 도입한 사례가 있다. youki는 아직 production-ready를 외치진 않지만 SUSE Rancher 진영에서 적극 후원하는 중이다.

6장 · containerd 2.0 — CNCF Graduated 표준

containerd는 2017년 Docker가 CNCF에 기증한 high-level 런타임이다. 2024년 9월 2.0이 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로 등록해서 실행 가능.

containerd는 Kubernetes 1.24부터 dockershim이 제거되면서 사실상 디폴트가 됐다. 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 생태계의 3종 세트. 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는 Google이 2018년 KubeCon에서 공개한 "유저스페이스 커널" 기반 sandbox 런타임이다. 핵심 아이디어는 — 컨테이너 안의 syscall을 호스트 커널이 직접 처리하지 않고, gVisor 사용자 공간 프로세스가 가로채서 일부만 호스트로 전달한다.

   container app
        │ 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이 뜨고, 그 안에서 컨테이너 프로세스가 실행된다.

지원하는 hypervisor:

• Firecracker — AWS의 MicroVM, 가장 가벼움.
• Cloud Hypervisor — Intel/Cloud Hypervisor 커뮤니티의 Rust VMM.
• QEMU — 가장 호환성 좋음, 가장 무거움.

2026년 시점 Kata 3.x의 주요 기능:

• VFIO-AP — IBM s390x에서 암호화 카드 passthrough.
• Confidential Containers 통합 — AMD SEV-SNP·Intel TDX·IBM SE 지원.
• runD shim 통합 — Alibaba Cloud가 기여한 shim이 containerd에 들어옴.

쓰는 곳: Alibaba Cloud의 ECI 일부, 일본 야후재팬, Microsoft Azure Container Instances 일부, GKE Sandbox(gVisor 대신 Kata 선택지).

12장 · Firecracker 1.10 — AWS Lambda를 떠받치는 MicroVM

Firecracker는 AWS가 2018년 re:Invent에서 공개한 minimalist VMM이다. Rust로 짰고 KVM 위에서 동작한다. 2026년 5월 stable은 1.10.

설계 원칙:

• Minimal device model — virtio-net, virtio-block, virtio-vsock, serial console 정도만. PCI도 없다.
• 125ms 미만 부팅 — 5MB짜리 microVM 바이너리가 5MB 메모리로 부팅.
• REST API — 외부에서 fc-control plane이 microVM을 조작.

핵심 사용처:

• AWS Lambda 백엔드 — cold start의 빠른 부팅을 위해 사용.
• AWS Fargate 일부 워크로드.
• Fly.io Machines — 글로벌 엣지의 컨테이너를 microVM에 격리.
• Kata Containers hypervisor 옵션.
• Northflank, Koyeb 등 신생 PaaS의 격리 백엔드.

Firecracker는 직접 쓰기보다는 그 위에 wrapper(Kata, Ignite, Firepilot, Cloud Hypervisor 비교용)를 두는 게 일반적이다.

13장 · Cloud Hypervisor 42 — Rust 진영의 또 다른 VMM

Cloud Hypervisor는 Intel이 2018년 시작한 또 다른 Rust 기반 VMM이다. Firecracker와 비교했을 때 더 폭넓은 디바이스 모델을 지원한다. 2026년 5월 stable은 42.

Edera Protect — 2024년 etcd 출신이 시작한 스타트업이 만든 "GPU와 confidential computing을 함께 지원하는 sandbox 플랫폼"이 Cloud Hypervisor를 기반으로 만들어진다.

14장 · WebAssembly 런타임 — runwasi shim으로 K8s에 진입

2024년 containerd가 runwasi shim을 정식 지원하면서, WebAssembly 모듈이 OCI 이미지처럼 K8s에 배포 가능해졌다.

핵심 Wasm 런타임 세 가지 (2026.5 기준):

WebAssembly 컨테이너의 장점:

• 부팅 시간 < 1ms — 진짜 cold start 1ms 미만.
• 메모리 < 1MB — 함수 하나에 수십 KB.
• 언어 무관 portability — Rust·Go·C·Python(파이오딘) 모두 가능.

단점:

• WASI 표준이 아직 진화 중 — networking, filesystem이 컨테이너만큼 풍부하지 않다.
• GPU/하드웨어 접근 제한 — WASI-NN으로 추론 정도는 가능하지만 학습은 어려움.

Spin(Fermyon)·WasmCloud·Wasmer Edge 같은 Wasm-first PaaS가 이 위에서 자라고 있다.

15장 · Confidential Containers — 메모리까지 암호화

Confidential Containers(CoCo)는 CNCF Sandbox 프로젝트로 2022년 출발해 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를 띄울 때 hypervisor가 SEV-SNP 또는 TDX VM을 만든다.
2. attestation server가 부팅 측정값을 검증.
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 비교

Mac 개발자 사이에서 2025년부터 가장 많이 들리는 이름은 Orbstack. 자체 작성한 경량 hypervisor로 Docker Desktop 대비 메모리 1/3, 시작 시간 1/5을 자랑한다.

리눅스 개발자는 굳이 Desktop 도구가 필요 없다 — 네이티브로 Podman이나 Docker Engine을 깔면 된다.

18장 · CI 환경 — Sysbox, DinD, Kaniko

CI에서 컨테이너를 빌드하거나 실행할 때 호스트 권한 노출이 늘 골치다.

• Docker-in-Docker (DinD) — docker:dind 이미지를 sidecar로 띄움. 가장 간단하지만 privileged 컨테이너 필요.
• Kaniko — Google이 만든 빌드 도구. Dockerfile을 root 권한 없이 빌드하고 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

서버리스/edge 진영의 격리 백엔드 매핑:

서버리스의 격리 모델은 점점 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 도입 계획.
• 삼성SDS — 사내 Brity Container Platform이 containerd + Kata 옵션.

일본

• NTT Data / NTT Communications — 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) or Firecracker
  ├─ 장기 실행 서비스 → 일반 컨테이너 (containerd + runc)
  ├─ 데이터 인텐시브 → 일반 컨테이너, syscall 많으면 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 호환성"의 삼각형이다. 한 가지 답은 없다. 다만 이 글에 그린 지도를 들고 들어가면, 어느 꼭짓점으로 가야 할지 다섯 번째 질문쯤에서 결정할 수 있을 것이다.

참고 자료 (References)

1. Open Container Initiative — https://opencontainers.org/
2. OCI Runtime Specification — https://github.com/opencontainers/runtime-spec
3. OCI Image Specification — https://github.com/opencontainers/image-spec
4. OCI Distribution Specification — https://github.com/opencontainers/distribution-spec
5. runc — https://github.com/opencontainers/runc
6. crun — https://github.com/containers/crun
7. youki — https://github.com/youki-dev/youki
8. containerd — https://containerd.io/
9. CRI-O — https://cri-o.io/
10. Podman — https://podman.io/
11. Buildah — https://buildah.io/
12. Skopeo — https://github.com/containers/skopeo
13. Docker — https://www.docker.com/
14. BuildKit — https://github.com/moby/buildkit
15. gVisor — https://gvisor.dev/
16. Kata Containers — https://katacontainers.io/
17. Firecracker — https://firecracker-microvm.github.io/
18. Cloud Hypervisor — https://www.cloudhypervisor.org/
19. WasmEdge — https://wasmedge.org/
20. Wasmtime — https://wasmtime.dev/
21. Wasmer — https://wasmer.io/
22. runwasi — https://github.com/containerd/runwasi
23. Spin (Fermyon) — https://www.fermyon.com/spin
24. WasmCloud — https://wasmcloud.com/
25. Confidential Containers — https://github.com/confidential-containers
26. Edera Protect — https://edera.dev/
27. Kubernetes CRI — https://kubernetes.io/docs/concepts/architecture/cri/
28. Orbstack — https://orbstack.dev/
29. Rancher Desktop — https://rancherdesktop.io/
30. Sysbox — https://github.com/nestybox/sysbox