Skip to content

对比

CRI 主流方案对比

维度 containerd CRI-O gVisor kata-containers
类型 标准 CRI 标准 CRI 沙箱 runtime VM runtime
维护方 CNCF（社区 / AWS / IBM） Red Hat Google OpenInfra
K8s 默认 ✅（1.24+） ❌（OpenShift 默认） ❌ ❌
隔离强度 跟 runc 一致 跟 runc 一致 强（用户态内核） 最强（VM）
性能开销 ~0% ~0% +10–30% +5–10%
启动 ~100ms ~100ms ~200ms ~500ms–2s
内存占用 低 最低 中 高
KVM 需求 ❌ ❌ ❌ ✅
跑在大多数云上 ✅ ✅ ✅ ⚠️ 看云
兼容 runc n/a n/a 是 是
WASM ✅（runwasi） 实验性 ❌ ❌
适合多租户 弱 弱 强 最强

一句话定位

  • containerd：默认、稳、通用，生产首选
  • CRI-O：最轻，OpenShift / RHEL 生态
  • gVisor：不需 KVM 的强隔离，serverless / 多租户
  • kata-containers：VM 隔离，金融 / 机密计算

决策树

隔离需求？
  ├─ 标准 → containerd 或 CRI-O
  │       ├─ 通用 K8s（kubeadm / kOps） → containerd
  │       └─ OpenShift / RHEL → CRI-O
  ├─ 强隔离，不挑硬件 → gVisor
  └─ 强隔离 + 有 KVM → kata-containers

RuntimeClass 用法

# 1. 装好 runtime,声明 RuntimeClass
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc
---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata

# 2. Pod 指定
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  runtimeClassName: gvisor    # 或 kata
  containers:
  - name: app
    image: myapp:latest

性能参考

  • CPU 密集：runc / containerd ≈ kata > gVisor
  • IO 密集（文件 / 网络）：runc > kata > gVisor
  • 启动延迟：runc < containerd ≈ CRI-O < gVisor < kata
  • 内存开销：CRI-O < containerd < gVisor < kata

切换 runtime 注意事项

  • 切换 containerd ↔ CRI-O：drain node → 改 kubelet flag → restart kubelet → restart runtime → uncordon
  • 加 gVisor / kata：装好 runtime，配 RuntimeClass，节点级生效（同节点上只能装一种 sandbox runtime）

一句话选型

不知道选啥 → containerd；OpenShift → CRI-O；多租户 + 没 KVM → gVisor；金融 / 机密 → kata。