容器中的 Shim 到底是个什么鬼？-轻识

引导关注

Kubernetes 1.20 版开始废除了对 dockershim 的支持，改用 Containerd^[1] 作为默认的容器运行时。本文将介绍 Containerd 中的 "shim" 接口。

每一个 Containerd 或 Docker 容器都有一个相应的 "shim" 守护进程，这个守护进程会提供一个 API，Containerd 使用该 API 来管理容器基本的生命周期（启动/停止），在容器中执行新的进程、调整 TTY 的大小以及与特定平台相关的其他操作。shim 还有一个作用是向 Containerd 报告容器的退出状态，在容器退出状态被 Containerd 收集之前，shim 会一直存在。这一点和僵尸进程很像，僵尸进程在被父进程回收之前会一直存在，只不过僵尸进程不会占用资源，而 shim 会占用资源。

shim 将 Containerd 进程从容器的生命周期中分离出来，具体的做法是 runc 在创建和运行容器之后退出，并将 shim 作为容器的父进程，即使 Containerd 进程挂掉或者重启，也不会对容器造成任何影响。这样做的好处很明显，你可以高枕无忧地升级或者重启 Containerd，不会对运行中的容器产生任何影响。Docker 的 --live-restore^[2] 特征也实现了类似的功能。

Containerd 支持哪些 shim？

Containerd 目前官方支持的 shim 清单：

io.containerd.runtime.v1.linux

io.containerd.runtime.v1.linux 是最原始的 shim API 和实现的 v1 版本，在 Containerd 1.0 之前被设计出来。该 shim 使用 runc 来执行容器，并且只支持 cgroup v1。目前 v1 版 shim API 已被废弃，并将于 Containerd 2.0 被删除。

io.containerd.runc.v1

io.containerd.runc.v1 与 io.containerd.runtime.v1.linux 的实现类似，唯一的区别是它使用了 v2 版本 shim API。该 shim 仍然只支持 cgroup v1。

io.containerd.runc.v2

该 shim 与 v1 采用了完全不同的实现，并且使用了 v2 版本 shim API，同时支持 cgroup v1 和 v2。该 shim 进程以运行多个容器，用于 Kubernetes 的 CRI 实现，可以在一个 Pod 中运行多个容器。

io.containerd.runhcs.v1

这是 Windows 平台的 shim，使用 Window 的 HCSv2 API 来管理容器。

当然，除了官方正式支持的 shim 之外，任何人都可以编写自己的 shim，并让 Containerd 调用该 shim。Containerd 在调用时会将 shim 的名称解析为二进制文件，并在 $PATH 中查找这个二进制文件。例如 io.containerd.runc.v2 会被解析成二进制文件 containerd-shim-runc-v2，io.containerd.runhcs.v1 会被解析成二进制文件 containerd-shim-runhcs-v1.exe。客户端在创建容器时可以指定使用哪个 shim，如果不指定就使用默认的 shim。

下面是一个示例，用来指定将要使用的 shim：

package main

import (
    "context"

    "github.com/containerd/containerd"
    "github.com/containerd/containerd/namespaces"
    "github.com/containerd/containerd/oci"
    v1opts "github.com/containerd/containerd/pkg/runtimeoptions/v1"
)

func main() {
    ctx := namespaces.WithNamespace(context.TODO(), "default")

    // Create containerd client
    client, err := containerd.New("/run/containerd/containerd.sock")
    if err != nil {
        panic(err)
    }

    // Get the image ref to create the container for
    img, err := client.GetImage(ctx, "docker.io/library/busybox:latest")
    if err != nil {
        panic(err)
    }

    // set options we will pass to the shim (not really setting anything here, but we could)
    var opts v1opts.Options

    // Create a container object in containerd
    cntr, err := client.NewContainer(ctx, "myContainer",
        // All the basic things needed to create the container
        containerd.WithSnapshotter("overlayfs"),
        containerd.WithNewSnapshot("myContainer-snapshot", img),
        containerd.WithImage(img),
        containerd.WithNewSpec(oci.WithImageConfig(img)),

        // Set the option for the shim we want
        containerd.WithRuntime("io.containerd.runc.v1", &opts),
    )
    if err != nil {
        panic(err)
    }

    // cleanup
    cntr.Delete(ctx)
}

⚠️注意：WithRuntime 将 interface{} 作为第二个参数，可以传递任何类型给 shim。只要确保你的 shim 能够识别这个类型的数据，并在 typeurl 包中注册这个类型，以便它能被正确编码。

每个 shim 都有自己支持的一组配置选项，可以单独针对每个容器进行配置。例如 io.containerd.runc.v2 可以将容器的 stdout/stderr 转发到一个单独的进程，为 shim 的运行设置自定义的 cgroup 等等。你可以创建自定义的 shim，在容器运行时添加自定义的选项。总的来说，shim 的 API 包含了 RPC 和一些二进制调用用于创建/删除 shim，以及到 Containerd 进程的反向通道。

如果你想实现自己的 shim，下面是相关参考资料：

(v2) shim RPC API 的详细定义^[3]
实现 shim 二进制和RPC API的辅助工具^[4]
shim 的使用方式^[5]

你只需要实现一个接口，shim.Run 会处理剩下的事情。shim 需要重点关注的是内存使用，因为每个容器都有一个 shim 进程，随着容器数量的增加，shim 的内存使用会急剧上升。shim 的 API 是在 protobuf 中定义的，看起来有点像 gRPC 的 API，但实际上 shim 使用的是一个叫做 ttrpc^[6] 的自定义协议，与 gRPC 并不兼容。ttrpc 是一个原 RPC 协议，专为降低内存使用而设计。

创建容器的 RPC 调用流程

Containerd 中有一个 container 对象，当你创建一个 container 对象，只是创建了一些与容器相关的数据，并将这些数据存储到本地数据库中，并不会在系统中启动任何容器。container 对象创建成功后，客户端会从 container 对象中创建一个 task，接下来是调用 shim API。

以下是 RPC 调用的总体流程：

客户端调用 container.NewTask(…)，containerd 根据指定或默认的运行时名称解析 shim 二进制文件，例如：io.containerd.runc.v2 -> containerd-shim-runc-v2。
containerd 通过 start 命令启动 shim 二进制文件，并加上一些额外的参数，用于定义命名空间、OCI bundle 路径、调试模式、返回给 containerd 的 unix socket 路径等。在这一步调用中，当前工作目录设置为 shim 的工作路径。
此时，新创建的 shim 进程会向 stdout 写一个连接字符串，以允许 containerd 连接到 shim ，进行 API 调用。一旦连接字符串初始化完成，shim 开始监听之后，start 命令就会返回。
containerd 使用 shim start 命令返回的连接字符串，打开一个与 shim API 的连接。
containerd 使用 OCI bundle 路径和其他选项，调用 Create shim RPC。这一步会创建所有必要的沙箱，并返回沙箱进程的 pid。以 runc 为例，我们使用 runc create --pid-file= 命令创建容器，runc 会分叉出一个新进程（runc init）用来设置沙箱，然后等待调用 runc start，所有这些都准备好后，runc create 命令就会返回结果。在 runc create 返回结果之前，runc 会将 runc-init 进程的 pid 写入定义的 pid 文件中，客户端可以使用这个 pid 来做一些操作，比如在沙箱中设置网络（网络命名空间可以在 /proc//ns/net 中设置）。
create 调用还会提供一个挂载列表以构建 rootfs，还包含 checkpoint 信息。
下一步客户端调用 task.Wait，触发 containerd 调用 shim Wait API。这是一个持久化的请求，只有在容器退出后才会返回。到这一步仍然不会启动容器。
客户端继续调用 task.Start，触发 containerd 调用 Start shim RPC。这一步才会真正启动容器，并返回容器进程的 pid。
这一步，客户端就可以针对 task 进行一些额外的调用请求。例如，如果 task 包含 TTY，会请求 task.ResizePTY，或者请求 task.Kill 来发送一个信号等等。
task.Exec 比较特殊，它会调用 shim Exec RPC，但并没有在容器中执行某个进程，只是在 shim 中注册了 exec，后面会使用 exec ID 来调用 shim Start RPC。
在容器或 exec 进程退出后，containerd 将会调用 shim Delete RPC，清理 exec 进程或容器的所有资源。例如，对于runc shim，这一步会调用 runc delete。
containerd 调用 Shutdown RPC，此时 shim 将会退出。

shim 的另一个重要部分是将容器的生命周期事件返回给 containerd ，包括：TaskCreate TaskStart TaskDelete TaskExit, TaskOOM, TaskExecAdded, TaskExecStarted, TaskPaused, TaskResumed, TaskCheckpointed。可参考 task 的详细定义^[7]。

总结

Containerd 通过 shim 为底层的容器运行时提供了可插拔能力。虽然这不是使用 Containerd 管理容器的唯一手段，但目前内置的 TaskService 使用了该方式，Kubernetes 通过调用 CRI 来创建 Pod 也是使用的 shim。由此可见 shim 这种方式很受欢迎，它不但增强了 Containerd 的扩展能力，以支持更多平台和基于虚拟机的运行时（firecracker^[8], kata^[9]），而且允许尝试其他 shim 实现（systemd^[10]）。