解析 Kubernetes 容器运行时(2)

CRI 的推出为容器社区带来了新的繁荣，cri-o、frakti、cri-containerd 等一些列的容器运行时为不同场景而生：

• cri-containerd——基于 containerd 的容器运行时
• cri-o——基于 OCI 的容器运行时
• frakti——基于虚拟化的容器运行时

而基于这些容器运行时，还可以轻易联结新型的容器引擎，比如可以通过 clear container、gVisor 等新的容器引擎配合 cri-o 或 cri-containerd 等轻易接入 Kubernetes，将 Kubernetes 的应用场景扩展到了传统 IaaS 才能实现的强隔离和多租户场景。

当使用CRI运行时，需要配置kubelet的--container-runtime参数为remote，并设置--container-runtime-endpoint为监听的unix socket位置(Windows上面为 tcp 或 npipe)。

CRI 接口

那么，CRI 接口到底长的什么样呢?

CRI 接口包括 RuntimeService 和 ImageService 两个服务，这两个服务可以在一个 gRPC server 里面实现，当然也可以分开成两个独立服务。目前社区的很多运行时都是将其在一个 gRPC server 里面实现。

管理镜像的 ImageService 提供了 5 个接口，分别是查询镜像列表、拉取镜像到本地、查询镜像状态、删除本地镜像以及查询镜像占用空间等。这些都很容易映射到 docker API 或者 CLI 上面。

而 RuntimeService 则提供了更多的接口，按照功能可以划分为四组：

• PodSandbox 的管理接口：PodSandbox 是对 Kubernete Pod 的抽象，用来给容器提供一个隔离的环境(比如挂载到相同的 cgroup 下面)，并提供网络等共享的命名空间。PodSandbox 通常对应到一个 Pause 容器或者一台虚拟机。
• Container 的管理接口：在指定的 PodSandbox 中创建、启动、停止和删除容器。
• Streaming API 接口：包括 Exec、Attach 和 PortForward 等三个和容器进行数据交互的接口，这三个接口返回的是运行时 Streaming Server 的 URL，而不是直接跟容器交互。
• 状态接口，包括查询 API 版本和查询运行时状态。

Streaming API

Streaming API 用于客户端与容器需要交互的场景，所以采用的是流式接口，包括 Exec、PortForward 和 Attach 等。Kubelet 内置的 docker 通过 nsenter、socat 等方法来支持这些特性，但它们不一定适用于其他的运行时。因而，CRI 也显式定义了这些 API，并且要求容器运行时返回一个 streaming server 的 URL 以便 Kubelet 重定向 API Server 发送过来的流式请求。

这样一个完整的 Exec 流程就是

• 客户端 kubectl exec -i -t ...
• kube-apiserver 向 Kubelet 发送流式请求 /exec/
• Kubelet 通过 CRI 接口向 CRI Shim 请求 Exec 的 URL
• CRI Shim 向 Kubelet 返回 Exec URL
• Kubelet 向 kube-apiserver 返回重定向的响应
• kube-apiserver 重定向流式请求到 Exec URL，接着就是 CRI Shim 内部的 Streaming Server 跟 kube-apiserver 进行数据交互，完成 Exec 的请求和响应

在 v1.10 及更早版本中，容器运行时必需返回一个 API Server 可直接访问的 URL(通常跟 Kubelet 使用相同的监听地址);而从 v1.11 开始，Kubelet 新增了 --redirect-container-streaming(默认为 false)，默认不再转发而是代理 Streaming 请求，这样运行时可以返回一个 localhost 的 URL。通过 Kubelet 代理的好处是由 Kubelet 处理与 API server 通信之间的请求认证。

实际上，各个运行时 streaming server 的处理框架都是类似的，因而 Kubelet 也提供来一个 steaming server 库，方便容器运行时的开发者引用。

容器运行时演进过程

了解了容器运行时接口的基本原理之后，接下来，我们再来看一下容器运行时的演进过程。

容器运行时的演进可以分为三个阶段：

首先，在 Kubernetes v1.5 之前，Kubelet 内置了 Docker 和 rkt 的支持，并且通过 CNI 网络插件给它们配置容器网络。这个阶段的用户如果需要自定义运行时的功能是比较痛苦的，需要修改 Kubelet 的代码，并且很有可能这些修改无法推到上游社区。这样，还需要维护一个自己的 fork 仓库，维护和升级都非常麻烦。

不同用户实现的容器运行时各有所长，许多用户都希望Kubernetes支持自定义的运行时。于是，从v1.5 开始增加了 CRI 接口，通过容器运行时的抽象层消除了这些障碍，使得无需修改 Kubelet 就可以支持运行多种容器运行时。CRI 接口包括了一组 Protocol Buffer、gRPC API 、用于 streaming 接口的库以及用于调试和验证的一系列工具等。在此阶段，内置的 Docker 实现也逐步迁移到了 CRI 的接口之下。但此时 rkt 还未完全迁移，这是因为 rkt 迁移 CRI 的过程将在独立的 repository 完成，方便其维护和管理。

第三阶段，从 v1.11 开始，Kubelet 内置的 rkt 代码删除，CNI 的实现迁移到 dockershim 之内。这样，除了 docker 之外，其他的容器运行时都通过 CRI 接入。外部的容器运行时除了实现 CRI 接口外，也要负责为容器配置网络。一般推荐使用 CNI，因为这样可以支持社区内的众多网络插件，不过这不是必需的，网络插件只需要满足 Kubernetes 网络的基本假设即可，即 IP-per-Pod、所有 Pod 和 Node 都可以直接通过 IP 相互访问。

CRI 容器运行时

（编辑：ASP站长网）