一、容器引擎和运行时机制原理剖析
容器引擎和运行时原理1:CRI接口

CRI接口: kubelet调用容器运行时的grpc接口
dockershim:kubernetes对接d
CRI-containerd: 通过containerd中的CRI插件实现了CRI接口,让containerd可直接对接containerd启动容器,无需调用docker api。当前使用最广泛的CRI接口接口实现。
CRI-O:专注于在kubernetes运行容器的轻量级CRI接口实现(不关注开发态)。

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

OCI组织: Linux基金会于2015年6月成立OCI(Open Container Initiative)组织,旨在围绕容器格式和运行时制定一个开放的工业化标准。目前主要有两个标准文档:容器运行时标准 (runtime spec)和 容器镜像标准(image spec)
Runtime spec:容器运行时标准,定义了容器状态和配置文件格式,容器生命周期管理命令格式和参数等。
runc: docker捐献给OCI社区的一个runtime spec的参考实现,docker容器也是基于runc创建的。
Kata-runtime:一种基于虚拟化的安全隔离的OCI runtime spec的实现。
gVisor: 一种基于系统调用拦截技术的轻量级安全容器实现。

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

命令:容器生命周期管理命令、包括创建、启动、停止、删除等。
容器引擎和运行时原理3:runtime v2
目的:让运行时更方便维护容器状态和生命周期,减少安全容器实现中,节点的进程数和资源调用。

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

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

Runtime Plugin: containerd中的runtime插件配置,定义了runtime名称、二进制路径、传递的annotation、特权容器模式等等。
runtimeClassName:pod的中的字段,通过该字段决定用那种运行时启动容器。
二、业界主流容器运行时技术架构剖析
业界主流容器运行时1:runc
Runc其实是最初Docker容器的实现,实际上它的容器就是一个进程,利用了Linux内核的特性对进程进行了许多限制,让进程看起来似乎运行在独立的环境中,主要有以下3种特性来对进程进行限制:
- Namespace:&
版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作! nbsp;资源和信息的可见性隔离,通过namespace隔离,容器中的应用只能看到分配到该容器的资源、其他主机上的信息在容器中不可见。常用的namespace有PID(进程号)、MNT(挂载点)、NET(网络)、UTS(主机名)和IPC(跨进程通信)等 - Cgroups:资源使用量的隔离,通过cgroup、限制了容器使用的资源量,通过不同的子系统,限制不同的资源。包括CPU、内存、io带宽、大页、fd数等等
- Capability: 权限限制, 通过对进程的capability定义,限制容器中的进程调用某些系统调用,以达到容器进程无法逃逸到主机的目的, 比如容器中的进程是不具有以下capability的:SYS_ADMIN/MKNOD/SYS_RESOURCE/SYS_MODULES …

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

业界主流容器运行时2:kata containers
kata containers是基于虚拟化来做的容器隔离,虚拟化隔离是指每个K8s pod都运行在一个独立的虚拟机中,提供虚拟化接口对接不同的虚拟化实现,包括qemu、cloud

主机资源访问:通过virtio、vfio等方式访问主机资源,如virtio-blk(块设备)、virtio-fs(文件)、virtio-net(网络)、vfio(物理设备)、vhost-user(用户态网络或存储)
如下为kata containers运行时主机或容器的情况:

业界主流容器运行时3:gVisor
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 tu
华为云中启动容器后的情况:

四、容器运行时技术的发展方向
容器运行时技术的发展方向:更轻量、更安全
- 通过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/c版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作! ce.html
[10]https://www.huaweicloud.com/product/cci.html