第1课：容器运行时技术深度剖析

一、容器引擎和运行时机制原理剖析

CRI接口: kubelet调用容器运行时的grpc接口

dockershim：kubernetes对接docker api的CRI接口适配器，kubernetes 1.21版本已经将其标注为废弃接口。

CRI-containerd： 通过containerd中的CRI插件实现了CRI接口，让containerd可直接对接containerd启动容器，无需调用docker api。当前使用最广泛的CRI接口接口实现。

CRI-O：专注于在kubernetes运行容器的轻量级CRI接口实现(不关注开发态)。

CRI接口主要包括RuntimeService和ImageService，RuntimeService主要负责容器运行时的一些接口， 包括负责容器的生命周期管理，包括容器创建，启动、停止、日志和性能采集等接口；ImageService负责容器镜像的管理，包括显示镜像、拉取镜像、删除镜像等接口。

OCI组织: Linux基金会于2015年6月成立OCI（Open Container Initiative）组织，旨在围绕容器格式和运行时制定一个开放的工业化标准。目前主要有两个标准文档：容器运行时标准 （runtime spec）和 容器镜像标准（image spec）

Runtime spec：容器运行时标准，定义了容器状态和配置文件格式，容器生命周期管理命令格式和参数等。

run版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！c： docker捐献给OCI社区的一个runtime spec的参考实现，docker容器也是基于runc创建的。

Kata-runtime：一种基于虚拟化的安全隔离的OCI runtime spec的实现。

gVisor： 一种基于系统调用拦截技术的轻量级安全容器实现。

config.json：定义容器运行所需要的所有信息，包括rootfs、mounts、进程、cgroups、namespaces、caps等。

命令：容器生命版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！周期管理命令、包括创建、启动、停止、删除等。

目的：让运行时更方便维护容器状态和生命周期，减少安全容器实现中，节点的进程数和资源调用。

shimv2: 新的容器运行时接口，基于ttrpc通信。

RuntimeClass: kubernetes中的对象类型，定义了在集群中的某种运行时，并且可以通过overhead和nodeSelector定制某种运行时的资源和调度行为。

Runtime Plugin： containerd中的runtime插件配置，定义了runtime名称、二进制路径、传递的annotation、特权容器模式等等。

runtimeClassName：pod的中的字段，通过该字段决定用那种运行时启动容器。

二、业界主流容器运行时技术架构剖析

Runc其实是最初Docker容器的实现，实际上它的容器就是版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！一个进程，利用了Linux内核的特性对进程进行了许多限制，让进程看起来似乎运行在独立的环境中，主要有以下3种特性来对进程进行限制：

• Namespace: 资源和信息的可见性隔离，通过namespace隔离，容器中的应用只能看到分配到该容器的资源、其他主机上的信息在容器中不可见。常用的namespace有PID（进程号）、MNT（挂载点）、NET（网络）、UTS（主机名）和IPC（跨进程通信）等
• Cgroups：资源使用量的隔离，通过cgroup、限制了容器使用的资源量，通过不同的子系统，限制不同的资源。包括CPU、内存、io带宽、大页、fd数等等
• Capability： 权限限制, 通过对进程的capability定义，限制容器中的进程调用某些系统调用，以达到容器进程无法逃逸到主机的目的， 比如容器中的进程是不具有以下capability的：SYS_ADMIN/MKNOD/SYS_RESOURCE/SYS_MODULES …

Runc在主机或容器运行时如下图：

kata containers是基于虚拟化来做的容器隔离，虚拟化隔离是指每个K8s pod都运行在一个独立的虚拟机中，提供虚拟化接口对接不同的虚拟化实现，包括qemu、cloud hypervisor、firecracker等等 。为了达到和容器近似的使用体验，需要对各组件进行裁剪，达到轻量化和启动加速的目的，对于hypervisor，去除通用虚拟化的各种不必要的设备、总线等。对于guest kernel，也裁剪了大量不需要的驱动和文件系统模块。而运行在虚拟机中的1号进程(一般为kata-agent)，资源占用可小于1MB。

主机资源访问：通过virtio、vfio等方式访问主机资源，如virtio-blk（块设备）、virtio-fs（版权声明：本文遵循 CC 4.0 BY-SA 版权协议，若要转载请务必附上原文出处链接及本声明，谢谢合作！文件）、virtio-net（网络）、vfio（物理设备）、vhost-user（用户态网络或存储）

如下为kata containers运行时主机或容器的情况：

gVisor是通过拦截进程的系统调用来实现比runc更强的隔离，比kata更轻量。其拦截系统调用的方式有两种，ptrace和kvm

优点：额外内存消耗小，容器启动速度快

缺点：系统调用慢，导致IO、网络等性能差，由于是模拟内核，有POSIX兼容性问题

如下为gVisor运行时主机或容器的效果：

三、华为云容器运行时技术架构剖析

华为云中的容器运行时：Enhanced Kata Containers

轻量化：hypervisor采用华为云自研的qemu-microvm， guest kernel采用裁剪EulerOS内核、主机shimv2采用rust语言重写。

丰富的硬件支持： GPU、nvlink、Ascend、IB、SDI

华为云基础设施融合：evs（块设备）、obs（对象存储）、sfs（文件存储）、vpc（华为云VPC网络）

产品形态：CCI（全托管的云容器实例）、CCE turbo（CCE增强版）

华为云中启动容器后的情况：

四、容器运行时技术的发展方向

容器运行时技术的发展方向：更轻量、更安全

• 通过rust改写，减少host进程，进一步轻量化hypervisor等方式实现更加轻量级的安全容器
• 结合机密计算技术，实现更加安全的容器技术

[1]https://kubernetes.io/docs/setup/production-environment/container-runtimes/

[2]https://kubernetes.io/docs/concepts/containers/runtime-class/
[3]https://github.com/opencontainers/runtime-spec/blob/master/spec.md
[4]https://github.com/containerd/containerd#cri
[5]https://cri-o.io/
[6]https://github.com/opencontainers/runc
[7]https://katacontainers.io/
[8]https://gvisor.dev/
[9]https://www.huaweicloud.com/product/cce.html
[10]https://www.huaweicloud.com/product/cci.html