コンテナランタイム 2026 完全ガイド - containerd · runc · Podman · CRI-O · Kata · gVisor · Firecracker · Wasm 深掘り

はじめに — 2026年5月、コンテナランタイムは「多層隔離の時代」へ

Docker がコンテナと同義だった時代は終わった。2026年5月時点で Kubernetes クラスタの 95% 以上は containerd または CRI-O で動いている。開発機では Podman と Docker Desktop がシェアを分け合い、サーバーレスのバックエンドは Firecracker が事実上の標準だ。そして Wasm ランタイムがコンテナの一部領域を侵食し始めた。WasmEdge と wasmtime が runwasi という containerd-shim で Kubernetes に直結する。

本稿はマーケティング比較ではなく「2026年の本番で、どのランタイムがどこに入っているか」を正直に書く。OCI イメージ仕様、CRI、低レベルランタイム、隔離強度、イメージビルド、レジストリ、署名、脆弱性スキャンまでフルスタックで触れる。

コンテナスタックの 5 層 — OCI イメージからカーネルまで

まず全体像を見よう。2026年の標準コンテナスタックは次の 5 層に分解できる。

1. OCI イメージフォーマット (image-spec): マニフェスト + 階層 tar + config JSON
2. レジストリ (distribution-spec): ECR、GAR、Harbor、Quay は同じ API
3. 高レベルランタイム (CRI/エンジン): containerd、CRI-O、Docker Engine、Podman
4. 低レベルランタイム (OCI runtime): runc、crun、youki、kata-runtime、runsc(gVisor)
5. 隔離メカニズム: namespaces + cgroups、マイクロ VM、ユーザー空間カーネル、Wasm サンドボックス

これらの層は OCI image-spec と OCI runtime-spec という 2 つの標準で繋がれている。どのビルダーで作ったイメージでも、どのランタイムでも動くことが約束されている。2026年時点でその約束はほぼ破られていない。

containerd — Kubernetes の既定 CRI

containerd は元々 Docker Engine から切り出されたデーモンで、2017年に CNCF を卒業し、その後 Kubernetes の事実上の標準 CRI 実装となった。EKS、GKE、AKS、OpenShift いずれも既定は containerd だ。Docker Desktop 内部でも containerd が動いている。

containerd の構造はシンプルだ。

• containerd デーモン: イメージ pull、ストレージ、ネットワーク、コンテナライフサイクル
• CRI プラグイン: kubelet と gRPC で通信
• OCI runtime shim: コンテナごとの小さな shim プロセスが runc を呼ぶ
• snapshotter: 階層ファイルシステム (overlayfs、native、btrfs、zfs、stargz)

containerd 2.0 (2025年末 GA) からは NRI (Node Resource Interface)、ユーザー空間 NRI プラグイン、Wasm shim (runwasi) 連携がファーストクラスになった。nerdctl は containerd の Docker 互換 CLI で、ほぼ同じコマンドが使える。

# nerdctl で containerd を直接操作
sudo nerdctl pull alpine:3.20
sudo nerdctl run --rm -it alpine:3.20 sh
sudo nerdctl images
sudo nerdctl ps -a

# CRI プラグインの状態確認
sudo crictl info | jq '.config.containerd'
sudo crictl ps

runc · crun · youki — OCI 低レベルランタイムの三つ巴

OCI runtime 仕様は「config.json と rootfs ディレクトリを受け取ってコンテナを起動せよ」というインタフェースだ。これを実装する低レベルランタイムが 3 つある。

• runc: Go で書かれた事実上のリファレンス。namespaces、cgroups、seccomp を適用して実行する。
• crun: C で書かれた OCI ランタイム。runc より起動が速くメモリ使用量も少ない。Red Hat が Podman・CRI-O の既定として採用。
• youki: Rust で再実装した runc 互換ランタイム。Container Plumbing Days でよく話題になり、一部のサンドボックスプロジェクトが採用している。

3 つとも OCI 仕様に従うため、containerd の runtimes 設定で差し替え可能だ。

# /etc/containerd/config.toml の一部
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.crun]
  runtime_type = "io.containerd.runc.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.crun.options]
    BinaryName = "/usr/bin/crun"

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.youki]
  runtime_type = "io.containerd.runc.v2"
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.youki.options]
    BinaryName = "/usr/local/bin/youki"

CRI-O — Kubernetes 専用の軽量 CRI

CRI-O は Red Hat 主導の Kubernetes 専用 CRI だ。Docker 互換機能を持たず、kubelet と OCI ランタイムをつなぐ橋に徹する。OpenShift の既定 CRI であり、ノード上のメモリ使用量と表面積が containerd より小さいという利点がある。

containerd と CRI-O のどちらを選ぶかは運用チームの慣れ次第になることが多い。EKS・GKE の既定をそのまま使うなら containerd、OpenShift 上なら CRI-O だ。2026年時点で両者の隔離強度や機能差はほぼない。

Docker Engine — デスクトップとレガシーサーバーに残る席

Docker Engine は 2026年も生きているが役割は狭まった。デスクトップ (Docker Desktop) と一部のレガシーサーバーで既定エンジンを務めるくらいで、Kubernetes ノードからはほぼ消えた。Docker Engine 自体も内部的に containerd を使う薄いラッパーに近い。

Docker が依然強いのは 開発者 UX だ。docker compose でマルチコンテナ開発環境を立ち上げる流れは圧倒的に普及しており、Buildx と Docker Build Cloud がビルド速度を押し上げた。そのため「本番は containerd、開発は Docker Desktop」という組み合わせは未だ多い。

Podman + Buildah + Skopeo — ルートレス・デーモンレスの三点セット

Podman は Docker 互換 CLI を提供しつつデーモンを持たない。コンテナそれぞれがユーザープロセスとして起動し、systemd がライフサイクルを管理する。デーモンがないため root 権限も不要 (ルートレス)。Fedora・RHEL・CentOS Stream の既定であり、Ubuntu LTS にも標準パッケージとして入った。

• Podman: コンテナ実行と pod 管理 (Kubernetes pod と同じ意味)
• Buildah: Dockerfile ビルドツール。デーモンなしで OCI イメージを生成
• Skopeo: イメージメタデータ参照・コピー・署名検証

3 つとも Red Hat 主導だが OCI 標準のみに従うので、他のランタイムやレジストリと自由に混ぜられる。

# Podman ルートレス
podman run --rm -it --userns=keep-id alpine:3.20 id

# Buildah によるデーモンレスビルド
buildah bud -t myapp:1.0 .
buildah push myapp:1.0 docker://registry.example.com/myapp:1.0

# Skopeo によるレジストリ間コピー
skopeo copy --src-creds user:pass --dest-creds user:pass \
  docker://docker.io/library/nginx:1.27 \
  docker://harbor.example.com/library/nginx:1.27

Kata Containers 3.x — 軽量 VM による強い隔離

Kata Containers はコンテナインタフェースの裏に軽量 VM を立ち上げてカーネルを分離する。ホストカーネルの CVE がコンテナ脱出に直結しないように防ぐ。3.x 系 (2024-2026) は QEMU、Firecracker、Cloud Hypervisor をハイパーバイザーとして選べ、起動時間が 1-2 秒台まで落ちた。

Kata は containerd の runtimes に kata-qemu、kata-fc、kata-clh として登録する。Kubernetes では RuntimeClass でワークロードごとに隔離レベルを分けられる。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-clh
handler: kata-clh
---
apiVersion: v1
kind: Pod
metadata:
  name: untrusted-workload
spec:
  runtimeClassName: kata-clh
  containers:
    - name: app
      image: registry.example.com/untrusted-app:1.0

gVisor — Google のユーザー空間カーネルサンドボックス

gVisor (runsc) は Google が作ったユーザー空間カーネル実装だ。ホストカーネル syscall をそのまま通さず、runsc 内部の自前カーネルで代行する。VM ではないので軽量だが、ホストカーネル表面積を極端に減らせる。

弱点は一部のワークロードでネットワークやファイル I/O が遅くなる点だ。そのため 信頼できないコード実行 (サーバーレス関数、CI ビルドランナー、AI 推論のユーザーコード) によく合い、DB のような I/O ヘビーなワークロードには合わない。Google Cloud Run や GKE Sandbox は内部で gVisor を使う。

# Docker に runsc を登録して実行
sudo runsc install
sudo systemctl restart docker
docker run --rm --runtime=runsc alpine:3.20 uname -a
# 出力のカーネルバージョンはホストではなく runsc が模倣する値になる

Firecracker — AWS のマイクロ VM

Firecracker は AWS が作った KVM ベースのマイクロ VM モニタだ。Lambda、Fargate、App Runner の隔離単位は Firecracker microVM である。VM 1 台が 5MB 未満のメモリオーバーヘッドで 125ms 以内に起動する。Rust で書かれ、デバイスモデルを可能な限り削ってセキュリティ表面を縮小している。

Firecracker は REST API で vCPU、メモリ、カーネルイメージ、rootfs、ネットワークインタフェースを設定してからインスタンスを起動する。

{
  "boot-source": {
    "kernel_image_path": "/var/lib/firecracker/vmlinux",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "path_on_host": "/var/lib/firecracker/rootfs.ext4",
      "is_root_device": true,
      "is_read_only": false
    }
  ],
  "machine-config": {
    "vcpu_count": 2,
    "mem_size_mib": 512,
    "smt": false
  }
}

Cloud Hypervisor — Intel・AWS・Microsoft 共同のマイクロ VM

Cloud Hypervisor は Intel が始め、AWS、Microsoft、Tencent などが加わった共同プロジェクトだ。Firecracker と同じく KVM ベースの VMM だが、より豊富なデバイスモデルと ARM・x86 両対応を持つ。Kata Containers の kata-clh バックエンド、Azure Confidential Containers、AWS の一部コンテナ隔離で採用されている。2026年のマイクロ VM 業界は Firecracker と Cloud Hypervisor が二分していると言ってよい。

Wasm ランタイム — Kubernetes に入ってきた新しい隔離単位

WebAssembly はコンテナの一部領域を急速に侵食している。WasmEdge、wasmtime、wasmer、lunatic などのランタイムは起動時間がマイクロ秒単位、メモリオーバーヘッドはコンテナより一桁小さい。CNCF は runwasi という containerd-shim を通じて Wasm を Kubernetes pod として直接実行する道を標準化した。

• WasmEdge: CNCF Incubation。Kubernetes 連携と AI 推論 (LLM、映像) に強み
• wasmtime: Bytecode Alliance のリファレンス実装。WASI 標準を牽引
• wasmer: 複数バックエンド (LLVM、Cranelift、Singlepass)
• lunatic: Erlang/BEAM 影響のアクター型ランタイム
• Spin (Fermyon): Wasm マイクロサービスフレームワーク
• wasmCloud: 分散 Wasm アクターシステム、CNCF Incubation

Kubernetes で Wasm ワークロードを動かす一般的な流れは、runwasi を containerd に登録して RuntimeClass で振り分けることだ。

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmedge
handler: wasmedge
---
apiVersion: v1
kind: Pod
metadata:
  name: hello-wasm
spec:
  runtimeClassName: wasmedge
  containers:
    - name: hello
      image: registry.example.com/hello-wasm:1.0
      command: ['/hello.wasm']

WASI · Wasm Component Model — 互換性の標準

Wasm をコンテナの代替たらしめる核は WASI (WebAssembly System Interface) だ。preview 1 から始まり、2024年に preview 2 が安定、2025年末には component model が GA に近づいた。component model は言語間の ABI を統一し、Rust 製の Wasm モジュールが Go・JS・Python ホストでそのまま動く。

2026年時点で WASI / component model が最も活発に使われているのは エッジコンピューティング (Cloudflare Workers、Fastly Compute)、プラグインシステム (Envoy、Open Policy Agent、Istio)、AI 推論 (WasmEdge + ONNX、GGUF) だ。

隔離強度の比較 — 何をいつ使うか

ランタイム選定の主軸は隔離強度と起動時間だ。2026年5月時点の代表的な組み合わせを整理する。

• runc/crun/youki: プロセス隔離、起動 50-200ms。信頼できるコード。大半の Kubernetes ワークロードの既定
• gVisor (runsc): ユーザー空間カーネル、起動 200-400ms。信頼できないユーザーコード、CI ランナー
• Kata Containers: 軽量 VM (QEMU/FC/CLH)、起動 1-2 秒。マルチテナント、コンプライアンス
• Firecracker microVM: KVM、起動 100-200ms。サーバーレス、短命
• Wasm (WasmEdge/wasmtime + runwasi): サンドボックス、起動 1-10ms。エッジ、プラグイン、AI

表面的な隔離強度ではマイクロ VM と Kata が最も強く、Wasm はそれより弱いがコンテナ脱出系の脅威モデル自体が異なる。runc が最も弱いが最速で最も互換性が高い。

OCI イメージビルダー — BuildKit · kaniko · buildah · jib · ko · Buildpacks

イメージを作る道具は 2026年でも豊富だ。どれを選ぶかは環境 (ビルダーに Docker デーモンがあるか、Kubernetes の中で作るか) と言語スタックに依る。

• BuildKit: Docker 製の次世代ビルダー。キャッシュマウント、シークレットマウント、マルチプラットフォームがファーストクラス。docker buildx がユーザーインタフェース。
• kaniko: Kubernetes pod 内で Docker デーモンなしに Dockerfile をビルド。GitLab CI と Argo Workflows で最も普及。
• buildah: Podman の兄弟。デーモンなしで OCI イメージをビルドし、ビルド工程をシェルスクリプトで書ける。
• img: BuildKit をデーモンなしで駆動するユーザー空間ビルダー。
• jib: Maven/Gradle プラグイン。Dockerfile なしで JVM アプリを OCI イメージにする。
• ko: Go 用。ko build で Go ソースから直接 OCI イメージを生成、Kubernetes に push。
• Bazel container_image rules / rules_oci: Bazel ビルドグラフからの決定論的イメージビルド。
• Cloud Native Buildpacks (Paketo): Dockerfile なしで heuristics がベースを選ぶ。Heroku・Pivotal の精神的後継。

BuildKit のキャッシュマウントを使った典型的なマルチステージ Dockerfile は次のとおり。

# syntax=docker/dockerfile:1.7
FROM golang:1.23 AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download
COPY . .
RUN --mount=type=cache,target=/root/.cache/go-build \
    --mount=type=cache,target=/go/pkg/mod \
    CGO_ENABLED=0 go build -o /out/app ./cmd/server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /out/app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

OCI イメージフォーマット · マニフェスト v2 · インデックス

OCI イメージ仕様は 3 つのオブジェクトから成る。マニフェスト (レイヤと config を参照)、config JSON (entrypoint、環境変数、history)、レイヤ (tar.gz または zstd 圧縮)。マルチアーキは イメージインデックス (マニフェストリスト) でまとめる。

2026年に入って標準化が進んだ変更には OCI image-spec 1.1 の zstd レイヤ、OCI artifacts (イメージ以外のデータも同フォーマットで push)、referrer API (OCI 1.1 dist-spec) がある。これにより cosign 署名、SBOM、attestation が同じレジストリに付随物として乗る。

OCI Distribution · レジストリフルスタック

レジストリも OCI distribution 仕様に統一された。どのクラウドレジストリでも同じ API が動く。

• Docker Hub: 公開イメージ中心。pull レート制限で本番直接 pull は減っている
• GitHub Container Registry (ghcr.io): GitHub Actions と統合、OSS に親和的
• GitLab Container Registry: セルフホスト GitLab と一体
• AWS ECR / ECR Public: IAM 統合、マルチリージョン、pull through キャッシュ
• Google Artifact Registry (GAR): 旧 GCR の統合後継、マルチフォーマット
• Azure Container Registry (ACR): 地理レプリケーション、Premium SKU では OCI artifact
• Harbor: CNCF Graduate。セルフホストの標準、レプリ・脆弱性スキャン・署名強制
• Quay: Red Hat。OpenShift と一体
• JFrog Artifactory: マルチパッケージマネージャ統合レジストリ
• DigitalOcean Container Registry: 小規模チーム向けの価格
• NVIDIA NGC: AI/HPC コンテナカタログ

イメージ署名 — cosign · notation (Notary v2)

イメージ出所保証は 2024年から標準化が進んだ。

• cosign: Sigstore プロジェクト。鍵なし署名 (OIDC + Fulcio + Rekor) で鍵管理負担が小さい。SLSA provenance、SBOM attestation も同じ道具で扱う。
• notation (Notary v2): CNCF Sandbox。X.509 ベース署名、エンタープライズ PKI と整合。Microsoft・IBM 主導。

Kubernetes では admission controller (Sigstore Policy Controller、Kyverno、OPA Gatekeeper) で未署名イメージのデプロイを止める。

# cosign 鍵なし署名と検証
cosign sign --yes registry.example.com/myapp:1.0
cosign verify \
  --certificate-identity-regexp 'https://github.com/myorg/.*' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  registry.example.com/myapp:1.0

脆弱性スキャン — Trivy · Grype · Snyk · Clair

ビルドや push の段階でイメージ脆弱性をスキャンする道具も標準化された。

• Trivy: Aqua Security 発、CNCF に寄贈。CVE、シークレット、IaC、Kubernetes ポリシーまで 1 バイナリ
• Grype: Anchore 発。SBOM ドリブンスキャン。Syft と一体
• Snyk Container: SaaS 優先、開発者 UX が強い
• Clair: Quay と一体、セルフホスト標準
• Docker Scout: Docker Desktop 統合、依存グラフとベースイメージ提案

2026年時点で最もよく見る組み合わせは、GitHub Actions/GitLab CI で Trivy が ビルドを止め、Harbor や ECR が push 後に自動スキャン、Kubernetes admission が cosign 署名 + Trivy レポートをまとめて検証する流れだ。

rootless · userns · cgroups v2 — 2026年の基本線

Linux ホスト水準の隔離基本線も整った。

• rootless: デーモン・ランタイムを一般ユーザー権限で実行。Podman は既定、containerd も rootlesskit で可能
• user namespaces remapping: コンテナ内 root をホストの一般ユーザーに割当て。Kubernetes 1.30 以降の user namespace 対応が beta から GA へ
• cgroups v2: メモリ・CPU・I/O コントローラ統合。2026年は主要ディストリ全てで既定
• seccomp: syscall ホワイトリスト。Kubernetes は既定プロファイルを推奨
• eBPF ベース LSM: Tetragon、Tracee がランタイム監視と遮断

Kubernetes RuntimeClass とマルチランタイムノード

Kubernetes RuntimeClass はノードに登録された複数ランタイムからワークロードごとに使うものを選ぶ標準 API だ。1 クラスタ内で信頼ワークロードは runc、ユーザーコード実行は gVisor、マルチテナントは Kata、エッジ関数は Wasm に分けるのがよくある絵になる。

ランタイムごとにノードプールを分けるのが運用的に単純だが、同じノードに複数ランタイムを登録して admission で振り分けるパターンも増えた。マネージド Kubernetes では GKE Sandbox (gVisor)、AKS Confidential Containers (Kata + Cloud Hypervisor)、EKS on Fargate (Firecracker) がそれぞれ独自の道を行く。

ビルドキャッシュと決定論的ビルド

2026年のビルドキャッシュは事実上必須だ。BuildKit と buildah はレジストリにキャッシュマニフェストを push する inline・registry キャッシュをサポートする。Bazel rules_oci、ko、jib は決定論的ビルド (同じ入力 → 同じダイジェスト) を保証する。決定論的ビルドは reproducible build 運動と SLSA 保証の土台だ。

CI で最も効くのは BuildKit のキャッシュマウントと外部キャッシュ (Buildx の --cache-to type=registry) を組み合わせて使うことだ。

韓国の事例 — Naver Container Engine と Coupang のランタイム遍歴

韓国は自前ランタイムを作るのではなく標準を深く使う方向で成熟した。

• Naver Container Engine (NCE): Naver Cloud Platform のマネージド Kubernetes。containerd ベースに自前 CNI、自前レジストリ、セキュリティツールを束ねた。
• Coupang: トラフィック急増期に Docker Engine から containerd に大規模移行したケースとして知られる。ビルドパイプラインは BuildKit と kaniko の混在、社内レジストリは Harbor と ECR を環境別に使い分けている。
• Kakao: 社内 PaaS で Kubernetes + containerd を標準化し、一部のユーザーコード実行に gVisor などの追加隔離を評価。
• Samsung SDS · LG CNS: エンタープライズ OpenShift (CRI-O) の導入事例が多く、マネージド Kubernetes は NCE・EKS・GKE 混用。

日本の事例 — Mercari の containerd 移行と LY Verda コンテナ

日本も OSS 標準を素早く採用した側だ。

• Mercari: 2019-2021年に Docker Engine から containerd へノード単位で移行し、社内 PaaS とビルドパイプラインを BuildKit + GAR に統一した事例をカンファレンスで共有している。
• LY (LINE + Yahoo! JAPAN) Verda: LY のプライベートクラウド。Kubernetes は containerd ベースで、一部ワークロードに Kata 評価、社内レジストリは Harbor フルスタックで運用。
• CyberAgent · DeNA: Kubernetes + containerd が標準で、信頼できないコード実行向けに gVisor・Firecracker の PoC が公開されている。
• NTT Communications: SmartCloud で OpenShift (CRI-O) マネージドを提供。

移行パターン — Docker Engine から containerd へ

レガシー環境で最もよくある移行は Docker Engine → containerd だ。Kubernetes 1.24 で dockershim が削除されて以降、EKS・GKE・AKS・OpenShift はすべて自動的に切り替わったが、自前運用の Kubernetes には依然移行が残っている。

移行の要点は (1) ノードのコンテナランタイム差し替え、(2) モニタリングとロギングエージェントのソケットパス変更 (/var/run/docker.sock → /run/containerd/containerd.sock)、(3) 社内ビルドパイプラインが Docker デーモンに依存しないよう BuildKit・kaniko・buildah に分離することだ。

コスト · 運用視点 — どの組み合わせを選ぶか

2026年5月時点で推奨される組み合わせはワークロードの性質によって次のようになる。

• 一般的な Kubernetes ワークロード: containerd + runc、ビルドは BuildKit、レジストリは ECR・GAR・Harbor のいずれか、署名は cosign、スキャンは Trivy
• 信頼できないユーザーコード: containerd + gVisor (runsc) または Kata。RuntimeClass で分離
• サーバーレス関数: Firecracker ベース (AWS Lambda、Fargate)。自前構築なら Firecracker + jailer
• エッジコンピューティング・プラグイン: WasmEdge または wasmtime + runwasi。コンテナより起動が速くメモリが軽い
• 開発機: Podman または Docker Desktop。macOS は Docker Desktop・OrbStack、Linux は Podman が自然

セキュリティのベストプラクティス — 2026年版チェックリスト

ランタイム単位ではなくフルスタックで押さえるべき項目だ。

• イメージ出所: cosign 鍵なし署名 + Sigstore Rekor 透明性ログ、SLSA L3 以上のビルド環境
• イメージ内容: 毎 push で Trivy/Grype スキャン、distroless・Chainguard・Wolfi のような slim ベース
• ノード隔離: ルートレスコンテナ、user namespace remapping、seccomp 既定プロファイル、AppArmor/SELinux
• Kubernetes admission: 署名検証、脆弱性ポリシー、ネットワークポリシー、Kyverno や OPA Gatekeeper
• ランタイム可視性: Falco、Tetragon、Tracee による eBPF ベースの syscall・ネットワーク異常検知
• 署名と SBOM 保全: イメージとともに SBOM (SPDX、CycloneDX) attestation を push し、全痕跡を保持

まとめ — コンテナの次の 10 年

コンテナは終わっていない。だが「Docker コンテナ」という単一モデルは終わった。2026年5月時点でコンテナインタフェースの裏には namespaces+cgroups からマイクロ VM、ユーザー空間カーネル、Wasm サンドボックスまで 5 種類以上の隔離メカニズムが入っている。OCI 標準がその多層を繋いでいる。

これからの 10 年の変化は 2 方向だ。1 つは Wasm がコンテナの一部領域を侵食し続けること。エッジ、プラグイン、AI 推論から始まり、一般バックエンドにも広がる可能性がある。2 つ目は コンフィデンシャルコンピューティング (AMD SEV-SNP、Intel TDX、ARM CCA) ベースの隔離がマルチテナントと規制ワークロードの標準になること。どちらの流れも OCI と Kubernetes 標準の上で起きる。標準を深く理解しているチームほど素早く適応できる。

References

• containerd
• runc — opencontainers/runc
• crun
• youki
• CRI-O
• Podman
• Buildah
• Skopeo
• nerdctl
• Kata Containers
• gVisor
• Firecracker
• Cloud Hypervisor
• WasmEdge
• wasmtime — bytecodealliance/wasmtime
• wasmer
• runwasi — containerd/runwasi
• Spin — Fermyon
• wasmCloud
• BuildKit — moby/buildkit
• kaniko
• jib
• ko — google/ko
• Cloud Native Buildpacks · Paketo
• Open Container Initiative
• Sigstore · cosign
• Notation — Notary v2
• Trivy
• Harbor