容器进阶:OCI与容器运行时
什么是容器运行时(Container Runtime)
Kubernetes节点的底层由一个叫做容器运行时的软件进行支撑,它负责比如启停容器 这样的事情。最广为人知的容器运行时当属Docker,但它不是唯一的。
容器运行时分类
- 低级运行时:只负责利用Cgroups和Namespaces等管理容器;
- 高级运行时:负责额外实现管理镜像的API,包括镜像格式、镜像管理(构建、查询和删除等)和镜像共享等;
什么是OCI
OCI(Open Container Initiative,开放容器标准)的容器运行时规范设定的标准定义了容器运行状态的描述,以及运行时需要提供的容器管理功能,例如创建、删除和查看等操作。容器运行时规范不受上层结构绑定,不受限于任何特定操作系统、硬件、CPU架构或公有云等,从而允许任何人遵循该标准开发应用容器技术。
符合规范的容器运行时
- runc, docker默认的运行时,与宿主机共享内核,利用cgroup做资源隔离,安全性不是很高,由于内核共享,性能最好
- runv,基于hypervisor的容器运行时,有自己单独的内核,安全性好很多
- kata,被蚂蚁收了,号称“容器的速度,虚拟机的安全”,貌似是基于runv做的
- gvisor,谷歌搞的,比runc安全,比VM性能要好。有一个用户空间的内核,会拦截应用程序的系统调用,目前没有实现所有的系统调用,因此不是所有的应用都可以运行
OCI对Docker的影响
OCI项目启动后,Docker公司将2014年开源的libcontainer项目移交至OCI组织并进化为runC项目,成为第一个且目前接受度最广泛的遵循OCI规范的容器运行时实现。
为了兼容OCI规范,Docker项目自身也做了架构调整,自1.11.0版本起,Docker引擎由一个单一组件拆分成了Docker Engine(docker-daemon)、containerd、containerd-shim和runC等4个独立的项目,并把containerd捐赠给了CNCF。
也就是,目前的Docker不是以前的Docker,技术栈进行了分层:
Docker CLi -> Dockerd -> Containerd -> OCI Implementation