首页/云/Kubernetes 速查/RuntimeClass 选择容器运行时
调度与资源52 条

RuntimeClass 选择容器运行时

RuntimeClass 把运行时抽象成名字(runc、gVisor、Kata 等):Pod 用 runtimeClassName 指定,兼顾隔离强度与性能取舍。

Kubernetes 速查云更新于 2026-10-13

RuntimeClass 是什么

RuntimeClass 把「用哪个容器运行时」抽象成一个名字:集群级定义一个类(例如 gvisor、kata),Pod 通过 spec.runtimeClassName 声明自己要用它。名字背后是节点上容器运行时注册的 runtime handler,不同的 handler 对应不同隔离强度:runc 是共享内核的常规容器,gVisor 用用户态内核拦截系统调用,Kata 给每个 Pod 起一台轻量虚拟机。隔离越强,启动与内存开销往往越大,选型就是在这条线上取平衡。

基本信息

所属 APInode.k8s.io/v1,集群级资源,v1.20 起 GA
关键字段metadata.name、handler(必填)、scheduling、overhead
Pod 侧引用Pod.spec.runtimeClassName 填 RuntimeClass 的名字
生效前提目标节点上的容器运行时已注册同名 runtime handler
overhead 记账podFixed 里的 cpu 与 memory 会并入 Pod 的资源请求,由调度器与 kubelet 计入

典型使用场景

  • 多租户环境下运行外部代码:用户提交的任务放进 gVisor,降低内核漏洞被利用后的影响面
  • 合规与强隔离要求:金融、医疗场景把敏感负载放进 Kata 这类带虚拟化边界的运行时
  • 同一集群内混跑不同信任等级的负载,用 runtimeClassName 区分,而不是只靠命名空间隔离
  • 排查运行时问题:临时把某个 Pod 切到指定运行时验证是否是运行时引起的异常
  • 性能对比测试:同一镜像在 runc 与沙箱运行时下跑基准,量化隔离带来的开销

声明与使用

声明与使用
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor        # 这个名字要与容器运行时注册的 handler 对应
handler: runsc
scheduling:
  nodeSelector:
    sandbox: gvisor   # 自动合并到 Pod,把负载限制在具备该运行时的节点
  tolerations:
    - key: sandbox
      operator: Exists
---
apiVersion: v1
kind: Pod
metadata:
  name: untrusted
spec:
  runtimeClassName: gvisor   # 仅这一行即可切换运行时
  containers:
    - name: worker
      image: registry.example.com/worker:1.0.0

核对运行时

核对运行时
kubectl get runtimeclass                     # 集群里定义了哪些运行时
kubectl get runtimeclass gvisor -o yaml      # 看 handler 与 scheduling 约束
kubectl get pod untrusted -o jsonpath='{.spec.runtimeClassName}{"\n"}'
crictl info                                  # 在节点上执行,查看容器运行时已注册的 runtime 名称
kubectl describe pod untrusted | sed -n '/Events/,$p'   # handler 缺失时事件里会直接说明

常见运行时取舍

运行时隔离方式性能与兼容性典型用途
runc共享宿主机内核的常规容器开销最小,内核逃逸风险最高普通业务负载
gVisor用户态内核拦截系统调用系统调用路径变长,启动更慢,兼容性受限多租户、运行不可信代码
Kata Containers每个 Pod 一台轻量虚拟机内存与启动开销最大,隔离最强强隔离与合规场景
scheduling.nodeSelector 会在 Pod 创建时合并进 Pod 的 nodeSelector,tolerations 同理,用来把负载限制在具备该运行时的节点上。这部分合并由 API Server 的 RuntimeClass 准入插件完成,具体开关与默认值以对应版本和发行版文档为准。
切换运行时不是零成本的兼容性操作:依赖 /proc 细节、内核模块、设备直通、特权容器或 eBPF 的负载在沙箱运行时下容易报系统调用错误。迁移前应在测试集群把核心链路(启动、读写、网络、探针)完整跑一遍。
不声明 overhead 会让节点资源账本偏乐观:调度器按不含运行时额外开销的请求数计算余量,节点更容易被压满并触发驱逐,这类问题通常在高水位时才显现。

易错点

  • 集群里有 RuntimeClass,但节点没注册对应 handler:Pod 卡在容器创建阶段,事件里直接说明运行时不可用,先到节点核对运行时配置
  • 漏配 scheduling.nodeSelector:使用该类的 Pod 可能落到没有对应运行时的节点上,表现为同样的负载时而成功时而失败
  • 把依赖特权、内核特性或 /proc 细节的应用直接塞进沙箱运行时:启动即报系统调用错误,必须先做兼容性验证
  • 不填 overhead:调度与驱逐的账没算上额外开销,节点被压满、Pod 被驱逐后才发现容量规划失真
  • 只换运行时却不收紧 Pod 权限:容器仍以 root 运行、仍挂载宿主目录时,隔离收益非常有限

数据来源与参考

  • Kubernetes 官方文档 · RuntimeClass
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌