Kubernetes / 运维笔记

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

Einic Yeo · 2月28日 · 2022年 · ·

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

容器引擎和运行时原理1:CRI接口

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接口

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: 一种基于系统调用拦截技术的轻量级安全容器实现。

OCI文件格式

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

容器生命周期管理命令

命令:容器生命周期管理命令、包括创建、启动、停止、删除等。

容器引擎和运行时原理3:runtime v2

目的:让运行时版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!更方便维护容器状态和生命周期,减少安全容器实现中,节点的进程数和资源调用。

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

容器生命周期管理命令

容器引擎和运行时原理4:RuntimeClass

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

RuntimeClass定义

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

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

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

业界主流容器运行时1:runc

Runc其实是最初Docker容器的实现,实际上它的容器就是一个进程,利用了Linux内核的特性对进程进行了许多限制,让进程看起来似乎运行在独立的环境中,主要有以下3种特性来对进程进行限制:

  • Namespace: 资源和信息的可见性隔离,通过namespace隔离,容器中的应用只能看到分配到该容器的资源、其他主机上的信息在容器中不可见。常用的namespace有PID(进程号)、MNT(挂载点)、NET(网络)、UTS(主机名)和IPC(跨进程通信)等
  • Cgroups:资源使用量的隔离,通过cgroup、限制了容器使用的资源量,通过不同的子系统,限制不同的资源。包括CPU、内存、io带宽、大页、fd数等等
  • Capability: 权限限制, 通过对进程的capability定义,限制容器中的进程调用某些系统调用,以达到容器进程无法逃逸到主机的目的, 比如容器中的进程是不具有以下capability版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!的:SYS_ADMIN/MKNOD/SYS_RESOURCE/SYS_MODULES …

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

业界主流容器运行时2:kata containers

kata containers是基于虚拟化来做的容器隔离,虚拟化隔离是指每个K8s pod都运行在一个独立的虚拟机中,提供虚拟化接口对接不同的虚拟化实现,包括qemu、cloud hypervisor、firecracker等等 。为了达到和容器近似的使用体验,需要对各组件进行裁剪,达到轻量化和启动加速的目的,对于hypervisor,去除通用虚拟化的各种不必要的设备、总线等。对于guest kernel,也裁剪了大量不需要的驱动和文件系统模块。而运行在虚拟机中的1号进程(一般为kata-agen版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!t),资源占用可小于1MB。

主机资源访问:通过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 turbo(CCE增强版)

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

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

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

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

附:容器运行技术原理相关参考链接

[1]https://kubernetes.io/docs/setup/production-environment/container-ru版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!ntimes/

[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.de版权声明:本文遵循 CC 4.0 BY-SA 版权协议,若要转载请务必附上原文出处链接及本声明,谢谢合作!v/
[9]https://www.huaweicloud.com/product/cce.html
[10]https://www.huaweicloud.com/product/cci.html
0 条回应