从零开始入门 K8s | 理解 RuntimeClass 与使用多容器运行时

做者 | 贾之光  阿里巴巴高级开发工程师

本文整理自《CNCF x Alibaba 云原生技术公开课》第 30 讲，点击直达课程页面。 关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，便可下载从零入门 K8s 系列文章 PPT。

1、RuntimeClass 需求来源

容器运行时的演进过程

咱们首先了解一下容器运行时的演进过程，整个过程大体分为三个阶段：

 

• 第一个阶段：2014 年 6 月

Kubernetes 正式开源，Docker 是当时惟一的、也是默认的容器运行时；

• 第二个阶段：Kubernetes v1.3

rkt 合入 Kubernetes 主干，成为了第二个容器运行时。

• 第三个阶段：Kubernetes v.15

与此同时，愈来愈多的容器运行时也想接入到 Kubernetes 中。若是仍是按 rkt 和 Docker 同样内置支持的话，会给 Kubernetes 的代码维护和质量保障带来严重挑战。

社区也意识到了这一点，因此在 1.5 版本时推出了 CRI，它的全称是 Container Runtime Interface。这样作的好处是：实现了运行时和 Kubernetes 的解耦，社区没必要再为各类运行时作适配工做，也不用担忧运行时和 Kubernetes 迭代周期不一致所带来的版本维护问题。比较典型的，好比 containerd 中的 cri-plugin 就实现了 CRI、kata-containers、gVisor 这样的容器运行时只须要对接 containerd 就能够了。

随着愈来愈多的容器运行时的出现，不一样的容器运行时也有不一样的需求场景，因而就有了多容器运行时的需求。可是，如何来运行多容器运行时还须要解决如下几个问题：

• 集群里有哪些可用的容器运行时？
• 如何为 Pod 选择合适的容器运行时？
• 如何让 Pod 调度到装有指定容器运行时的节点上？
• 容器运行时在运行容器时会产生有一些业务运行之外的额外开销，这种「额外开销」须要怎么统计？

RuntimeClass 的工做流程

为了解决上述提到的问题，社区推出了 RuntimeClass。它其实在 Kubernetes v1.12 中就已被引入，不过最初是以 CRD 的形式引入的。v1.14 以后，它又做为一种内置集群资源对象 RuntimeClas 被引入进来。v1.16 又在 v1.14 的基础上扩充了 Scheduling 和 Overhead 的能力。

下面以 v1.16 版本为例，讲解一下 RuntimeClass 的工做流程。如上图所示，左侧是它的工做流程图，右侧是一个 YAML 文件。

YAML 文件包含两个部分：上部分负责建立一个名字叫 runv 的 RuntimeClass 对象，下部分负责建立一个 Pod，该Pod 经过 spec.runtimeClassName 引用了 runv 这个 RuntimeClass。

RuntimeClass 对象中比较核心的是 handler，它表示一个接收建立容器请求的程序，同时也对应一个容器运行时。好比示例中的 Pod 最终会被 runv 容器运行时建立容器；scheduling 决定 Pod 最终会被调度到哪些节点上。

结合左图来讲明一下 RuntimeClass 的工做流程：

1. K8s-master 接收到建立 Pod 的请求；
2. 方格部分表示三种类型的节点。每一个节点上都有 Label 标识当前节点支持的容器运行时，节点内会有一个或多个 handler，每一个 handler 对应一种容器运行时。好比第二个方格表示节点内有支持 runc 和 runv 两种容器运行时的 handler；第三个方格表示节点内有支持 runhcs 容器运行时的 handler；
3. 根据 scheduling.nodeSelector, Pod 最终会调度到中间方格节点上，并最终由 runv handler 来建立 Pod。

2、RuntimeClass 功能介绍

RuntimeClass 的结构体定义

咱们仍是以 Kubernetes v1.16 版本中的 RuntimeClass 为例。首先介绍一下 RuntimeClass 的结构体定义。

一个 RuntimeClass 对象表明了一个容器运行时，它的结构体中主要包含 Handler、Overhead、Scheduling 三个字段。

• 在以前的例子中咱们也提到过 Handler，它表示一个接收建立容器请求的程序，同时也对应一个容器运行时；
• Overhead 是 v1.16 中才引入的一个新的字段，它表示 Pod 中的业务运行所需资源之外的额外开销；
• 第三个字段Scheduling 也是在 v1.16 中被引入的，该 Scheduling 配置会被自动注入到 Pod 的 nodeSelector 中。

RuntimeClass 资源定义例子

在 Pod 中引用 RuntimeClass 的用法很是简单，只要在 runtimeClassName 字段中配置好 RuntimeClass 的名字，就能够把这个 RuntimeClass 引入进来。<br />

Scheduling 结构体的定义

顾名思义，Scheduling 表示调度，但这里的调度不是说 RuntimeClass 对象自己的调度，而是会影响到引用了 RuntimeClass 的 Pod 的调度。

Scheduling 中包含了两个字段，NodeSelector 和 Tolerations。这两个和 Pod 自己所包含的 NodeSelector 和 Tolerations 是极为类似的。

NodeSelector 表明的是支持该 RuntimeClass 的节点上应该有的 label 列表。一个 Pod 引用了该 RuntimeClass 后，RuntimeClass admission 会把该 label 列表与 Pod 中的 label 列表作一次合并。若是这两个 label 中有冲突的，会被 admission 拒绝。这里的冲突是指它们的 key 相同，可是 value 不相同，这种状况就会被 admission 拒绝。另外须要注意的是，RuntimeClass 并不会自动为 Node 设置 label，须要用户在使用前提早设置好。

Tolerations 表示 RuntimeClass 的容忍列表。一个 Pod 引用该 RuntimeClass 以后，admission 也会把 toleration 列表与 Pod 中的 toleration 列表作一个合并。若是这两处的 Toleration 有相同的容忍配置，就会将其合并成一个。

为何引入 Pod Overhead？

上图左边是一个 Docker Pod，右边是一个 Kata Pod。咱们知道，Docker Pod 除了传统的 container 容器以外，还有一个 pause 容器，但咱们在计算它的容器开销的时候会忽略 pause 容器。对于 Kata Pod，除了 container 容器以外，kata-agent, pause, guest-kernel 这些开销都是没有被统计进来的。像这些开销，多的时候甚至能超过 100MB，这些开销咱们是无法忽略的。

这就是咱们引入 Pod Overhead 的初衷。它的结构体定义以下：

它的定义很是简单，只有一个字段 PodFixed。它这里面也是一个映射，它的 key 是一个 ResourceName，value 是一个 Quantity。每个 Quantity 表明的是一个资源的使用量。所以 PodFixed 就表明了各类资源的占用量，好比 CPU、内存的占用量，均可以经过 PodFixed 进行设置。

Pod Overhead 的使用场景与限制

Pod Overhead 的使用场景主要有三处：

• Pod 调度

在没有引入 Overhead 以前，只要一个节点的资源可用量大于等于 Pod 的 requests 时，这个 Pod 就能够被调度到这个节点上。引入 Overhead 以后，只有节点的资源可用量大于等于 Overhead 加上 requests 的值时才能被调度上来。

• ResourceQuota

它是一个 namespace 级别的资源配额。假设咱们有这样一个 namespace，它的内存使用量是 1G，咱们有一个 requests 等于 500 的 Pod，那么这个 namespace 之下，最多能够调度两个这样的 Pod。而若是咱们为这两个 Pod 增添了 200MB 的 Overhead 以后，这个 namespace 下就最多只可调度一个这样的 Pod。

• Kubelet Pod 驱逐

引入 Overhead 以后，Overhead 就会被统计到节点的已使用资源中，从而增长已使用资源的占比，最终会影响到 Kubelet Pod 的驱逐。

以上是 Pod Overhead 的使用场景。除此以外，Pod Overhead 还有一些使用限制和注意事项：

• Pod Overhead 最终会永久注入到 Pod 内而且不可手动更改。即使是将 RuntimeClass 删除或者更新，Pod Overhead 依然存在而且有效；
• Pod Overhead 只能由 RuntimeClass admission 自动注入（至少目前是这样的），不可手动添加或更改。若是这么作，会被拒绝；
• HPA 和 VPA 是基于容器级别指标数据作聚合，Pod Overhead 不会对它们形成影响。

3、多容器运行时示例

目前阿里云 ACK 安全沙箱容器已经支持了多容器运行时，咱们以上图所示环境为例来讲明一下多容器运行时是怎么工做的。

如上图所示有两个 Pod，左侧是一个 runc 的 Pod，对应的 RuntimeClass 是 runc，右侧是一个 runv 的Pod，引用的 RuntimeClass 是 runv。对应的请求已用不一样的颜色标识了出来，蓝色的表明是 runc 的，红色的表明是 runv 的。图中下半部分，其中比较核心的部分是 containerd，在 containerd 中能够配置多个容器运行时，最终上面的请求也会到达这里进行请求的转发。

咱们先来看一下 runc 的请求，它先到达 kube-apiserver，而后 kube-apiserver 请求转发给 kubelet，最终 kubelet 将请求发至 cri-plugin（它是一个实现了 CRI 的插件），cri-plugin 在 containerd 的配置文件中查询 runc 对应的 Handler，最终查到是经过 Shim API runtime v1 请求 containerd-shim，而后由它建立对应的容器。这是 runc 的流程。

runv 的流程与 runc 的流程相似。也是先将请求到达 kube-apiserver，而后再到达 kubelet，再把请求到达 cri-plugin，cri-plugin 最终还回去匹配 containerd 的配置文件，最终会找到经过 Shim API runtime v2 去建立 containerd-shim-kata-v2，而后由它建立一个 Kata Pod。

下面咱们再看一下 containerd 的具体配置。

containerd 默认放在 file:///etc/containerd/config.toml 这个位置下。比较核心的配置是在 plugins.cri.containerd 目录下。其中 runtimes 的配置都有相同的前缀 plugins.cri.containerd.runtimes，后面有 runc, runv 两种 RuntimeClass。这里面的 runc 和 runv 和前面 RuntimeClass 对象中 Handler 的名字是相对应的。除此以外，还有一个比较特殊的配置 plugins.cri.containerd.runtimes.default_runtime，它的意思是说，若是一个 Pod 没有指定 RuntimeClass，可是被调度到当前节点的话，那么就默认使用 runc 容器运行时。

下面的例子是建立 runc 和 runv 这两个 RuntimeClass 对象，咱们能够经过 kubectl get runtimeclass 看到当前全部可用的容器运行时。

下图从左至右分别是一个 runc 和 runv 的 Pod，比较核心的地方就是在 runtimeClassName 字段中分别引用了 runc 和 runv 的容器运行时。

最终将 Pod 建立起来以后，咱们能够经过 kubectl 命令来查看各个 Pod 容器的运行状态以及 Pod 所使用的容器运行时。咱们能够看到如今集群中有两个 Pod：一个是 runc-pod，另外一个是 runv-pod，分别引用的是 runc 和 runv 的 RuntimeClass，而且它们的状态都是 Running。

4、本文总结

本文的主要内容就到此为止了，这里为你们简单总结一下：

• RuntimeClass 是 Kubernetes 一种内置的集群资源，主要用来解决多个容器运行时混用的问题；
• RuntimeClass 中配置 Scheduling 可让 Pod 自动调度到运行了指定容器运行时的节点上。但前提是须要用户提早为这些 Node 设置好 label；
• RuntimeClass 中配置 Overhead，能够把 Pod 中业务运行所需之外的开销统计进来，让调度、ResourceQuota、Kubelet Pod 驱逐等行为更准确。

活动报名连接：https://yqh.aliyun.com/live/CloudNative

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”