容器运行时runc

---

前言

• docker引擎是用来运行和管理容器的
• 基于开放容器计划（OCI）的要求，Dokcer引擎采用了模块化的设计原则，其组件是可以替换的。
• dokcer引擎的主要组件：Docker客户端(docker client)、Docker 守护进程(Docker daemon)，containerd 和runc

graph LR
A[Docker client]  --> B(Docker 引擎)
B(Docker 引擎)  --> C[daemon]
B(Docker 引擎)  --> E[containerd]
B(Docker 引擎)  --> F[runc]

---

Docker引擎——详解

• docker开始发布时：有两个核心组件：LXC 和 docker daemon

graph TD
A[Docker daemon] -->  B[LXC]
B[LXC]  --> C[Namespace/Capability/CGroup]

• Docker daemon 是一个单一的二进制文件，包含：Docker客户端、Docker API、容器运行时、镜像构建等
• LXC提供了命名空间(Namespace)和控制组(CGrouop)等基础工具的操作能力。

摆脱LXC

• Docker公司开发了Libcontainer的自研工具，来代替LXC
• LIBcontainer可基于不同内核为Docker上层提供必要的容器交互工具。
• 在docker0.9版本，Libcontainer取代LXC称为默认的执行驱动。

摈弃大而全的Docker daemon

• 拆解Docker引擎并将其模块化重构成小而专的工具。

开发容器计划(OCI)的影响

• OCI定义了两个容器规范：

1. 镜像规范
2. 容器运行时规范
   • docker daemon不在包含任何容器运行时的代码——所有容器运行代码在一个单独的OCI兼容层实现的，docker使用runc实现这一点
   • Docker 引擎中的container组件确保了docker 镜像能够以正确的OCI Bundle的格式传递给runc。

runc

• runc是OCI容器运行时规范的参考实现。
• runc是一个轻量级的，针对Libcontainer进行包装的命令行交互工具
• runc所在的层是“OCI层”

container

• container的主要任务：容器生命周期管理——start|stop|pause|rm
• Docker引擎技术栈中：containerd位于daemon 和runc所在的OCI之间。
• Kubernetes也可以通过cri-containerd使用containerd

启动一个新容器

$ docker container run --name ctr1 -it alpine:latest sh
/ # ls
bin    etc    lib    mnt    proc   run    srv    tmp    var
dev    home   media  opt    root   sbin   sys    usr

• 整个命令的执行过程

graph TD 
A[Docker client]  --> B(Docker Daemon)
    B  --> C(container)
    C  --> D(shim/runc)

1.Docker Clinet :想docker API发送docker container run命令
2.docker daemon：在API端接受指令，指示container启动新容器
3.container： 给runc传递OCI bundle(镜像)
4.shim/runc: 创建容器

该模型的优势

• 将所有用于启动、管理容器的逻辑和代码从daemon中移除。
• 容器运行时与daemon是解耦的。
• “无守护进程的容器”，这样对docker daemon进行维护和升级时，不会影响到运行中的容器

shim

• shim是实现无daemon的容器的不可或缺的工具(用于将允许中的容器与daemon进行解耦，已便于对daemon进行升级)
• 一旦容器进程的父进程runc退出，相关联的containerd-shim进程就会成为容器的父进程
• shim 的职责： 1. 保持所有STDIN和STDOUT流是开启状态，从而当daemon重启时,容器不会因为管道(pipe)的关闭而终止。2.将容器的退出状态反馈给daemon

daemon当前主要的功能：镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排。