OCI、runc、containerd

参考文献:
https://www.jianshu.com/p/1ac4e1fa7c11

1、OCI(开放容器协议)

Docker公司推出了第一个OCI标准的容器运行时runc。
runc作为第一个oci标准运行时(runtime),只是一个参考实现

2、runc 作用?

仅仅承担容器与主机之间的交互

3、容器运行时,一些必要的功能?

  • 容器运行状态检查、
  • 监控,
  • 容器生命期管理,
  • io管理、
  • 信号传递

等一些列容器运行必不可少的功能

4、containerd

Container d作为一个生产环境可用的Oci 实现,它利用了OCI 运行时和镜像格式;

image

可以看到Containerd作为PaaS工具的通用容器运行时适配层,它利用已有的oci运行时(Containerd使用runc作为运行时,在windows上则是hcsshim),屏蔽底层操作系统的差异;
为Paas提供通用的容器支撑。从这个图可以看到Containerd计划支持所有现有应用广泛的Paas平台工具

4.1 containerd的架构

image

从此架构图可以清楚的看到Containerd对上提供grpc接口方式的api,而Metric api是度量功能使用的。
所有的编排工具容器适配层都可以使用grpc api作为containerd的客户端,使用containerd操作容器。

  • Distribution
    • 用于容器镜像的pull和push动作(这部分出现在Containerd中完全是因为oci v1标准推出Docker公司将自己镜像格式贡献了出去,所以containerd理所当然需要对镜像进行管理了)。
  • Bundle
    • (在docker的语景里是容器运行的目录集)子系统用于容器存储管理它的作用就是原来的graphdriver,它提供将容器镜像拆解成容器运行时刻需要的Bundle
  • Runtime
    • 子系统用于容器执行和监控,就是它直接操作runtime,传递和接收信号(signal),中转fifo,记录日志
  • Content、Metadata和Snapshots是存储管理组建,Excutor和Supervisor是执行体组建

4.2 containerd的主要责任?

1、执行:容器创建、运行、停止、暂停、恢复,exec,信号传递、和删除。

2、cow 文件系统支持:在overlay,aufs和其他cow文件系统上内置了存储功能

3、度量系统

4、发布:容器镜像的pull和push,镜像的管理和获取

4.3 不是containerd工作范畴的是?

1、网络:网络的创建和管理由高层来完成

2、build:镜像的构建

3、volumes:volume管理:mounts,bind等针对volume的功能应该有高层来完成

4、logging
此处需要说明一下网络曾经作为containerd社区争论的焦点。
但是在16年年底的社区维护者投票中多数人支持网络不留在containerd中,
因为按照大多数维护者的认识网络过于复杂,而且网络设置常常需要跨越节点。
这部分功能由containerd的客户端(Docker Engine 或k8s)做更合适。

这里顺便介绍一下Containerd版本兼容规则:
Containerd同一个大版本下的连续两个小版本是兼容的。
例Containerd1.1.0和1.2.0却是兼容的,1.0.0和1.2.0却不保证兼容
Docker 18.06.1正式将containerd 1.1引入docker。

image

docker-manager是老的kubelet介入docker的方式。

cri从k8s 1.6开始正式进入k8s

cri直接介入containerd是从18年4月,containerd1.1开始

5、PaaS平台选型建议

  • 如果你正在对基于k8s的PaaS平台进行生产环境选型,
  • 我建议你使用Docker17.03,因为它成熟稳定且k8s r9,r10和r11做过稳定、兼容性测试。
  • 如果你喜欢尝试新事物,我建议你跳过Docker17.03之后,直接在kublet上使用containerd1.1。
  • 如果你喜欢docker新版本,那么你可以尝试docker18.06,因为Docker17.12是Docker变化最剧烈的一个版本稳定性不好说,且kuberadm中r12 rc里加入了对18.06的支持所以用最新的好了。
  • 而且更关键的一点docker 18.06.1使用containerd 1.1,它支持一个特性:上层容器控制平台的namespace隔离,简单点说就是docker和k8s均可以在同一个节点上操作同一个containerd,且相互隔离不可见。
  • 如此可以预留选择传统k8s+docker组合时刻,保留将来切换成k8s+containerd组合的可能性,进而为自己的框架保持演进的灵活性。

你可能感兴趣的:(OCI、runc、containerd)