解析 Kubernetes 容器运行时

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 容器运行时

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!