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 或ｋ8s）做更合适。

这里顺便介绍一下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组合的可能性，进而为自己的框架保持演进的灵活性。