24. RuntimeClass与多容器运行时

亦凉 2022-10-24 01:37 143阅读 0赞

> 本文由 CNCF + Alibaba 云原生技术公开课 整理而来

### RuntimeClass 需求 ###

*  容器运行时的演进过程：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center]

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

社区也意识到了这一点，所以在 1.5 版本时推出了 `CRI`，它的全称是 `Container Runtime Interface`。这样做的好处是：实现了运行时和 Kubernetes 的解耦，社区不必再为各种运行时做适配工作，也不用担心运行时和 Kubernetes 迭代周期不一致所带来的版本维护问题。比如 `containerd` 中的 `cri-plugin` 就实现了 `CRI, kata, gVisor` 这样的容器运行时只需要对接 `contaienrd` 就可以了。

随着越来越多的容器运行时的出现，不同的容器运行时也有不同的需求场景，于是就有了多容器运行时的需求。但是，如何来运行多容器运行时还需要解决以下几个问题：

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

*  `RuntimeClass` 的大致工作流程：

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 1]

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

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

结合上图来说明一下 `RuntimeClass` 的工作流程：

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

--------------------

### RuntimeClass 功能介绍 ###

*  `RuntimeClass` 的结构体定义：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 2]

以 Kubernetes v1.16 版本中的 RuntimeClass 为例，介绍一下 RuntimeClass 的结构体定义。

一个 `RuntimeClass` 对象代表了一个容器运行时，它的结构体中主要包含 `Handler, Overhead, Scheduling` 三个字段。`Handler` 表示一个接收创建容器请求的程序，同时也对应一个容器运行时；`Overhead` 是 v1.16 中才引入的一个新的字段，它表示 `Pod` 中的业务运行所需资源以外的额外开销；`Scheduling` 也是在 v1.16 中被引入的，该 `Scheduling` 配置会被自动注入到 `Pod` 的 `nodeSelector` 中。

*  `RuntimeClass` 资源定义示例：

apiVersion: node.k8s.io/v1beta1
    kind: RuntimeClass
    metadata:
      name: myclass
    handler: myhandler

文件解析：

apiVersion: node.k8s.io/v1beta1     表示 RuntimeClass 当前所属的组是 node.k8s.io，版本是 v1beta1
    
    kind        表示 Kubernetes 资源类型是 RuntimeClass
    
    metadata    表示 RuntimeClass 的元数据，元数据通常包含 name，表示 RuntimeClass 资源对象名称，Pod 可以引用该字段指定容器运行时
    
    handler     表示 CRI 配置中的容器运行时的 handler 名称，最终由该 handler 来处理 Pod

*  `Pod` 引用 `RuntimeClass` 资源示例：

apiVersion: v1
    kind: Pod
    metadata:
      name: mypod
    spec:
      runtimeClassName: myclass

`Pod` 通过 `spec.runtimeClassName` 字段指定了 `RuntimeClass` 资源，最终 `Pod` 会被对应的容器运行时处理。

*  `Scheduling` 结构体的定义：

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 3]

`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`？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 4]

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

这就是引入 `Pod Overhead` 的初衷。它的结构体定义如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 5]

它的定义非常简单，只有一个字段 `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 不会对它们造成影响。

--------------------

### 多容器运行时示例 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 6]

上图有两个 `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` 的配置：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 7]

`containerd` 默认放在 `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 容器运行时。

apiVersion: node.k8s.io/v1beta1
    kind: RuntimeClass
    metadata:
      name: runc
    handler: runc
    
    ---
    apiVersion: node.k8s.io/v1beta1
    kind: RuntimeClass
    metadata:
      name: runv
    handler: runv

创建好 `RuntimeClass` 之后，可以通过 `kubectl get runtimeclass` 看到当前所有可用的容器运行时。

*  `Pod` 使用 `RuntimeClass`：

apiVersion: v1
    kind: Pod
    metadata:
      name: runc-pod
      namespace: demo
      labels:
        name: runc-pod
    spec:
      runtimeClassName: runc
      containers:
      - name: runc-pod
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          protocol: TCP
      dnsPolicy: ClusterFirst

apiVersion: v1
    kind: Pod
    metadata:
      name: runv-pod
      namespace: demo
      labels:
        name: runv-pod
    spec:
      runtimeClassName: runv
      containers:
      - name: runc-pod
        image: nginx:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          protocol: TCP
      dnsPolicy: ClusterFirst

最终将 `Pod` 创建起来之后，可以通过 `kubectl` 命令来查看各个 `Pod` 容器的运行状态以及 `Pod` 所使用的容器运行时。

kubectl get pod -n demo -o custom-columns=NAME:metadata.name,STATUS:.status.phase,RUNTIME_CLASS:.spec.runtimeClassName

*  总结：

`RuntimeClass` 是 Kubernetes 一种内置的全局域资源，主要用来解决多个容器运行时混用的问题。

`RuntimeClass` 中配置 `Scheduling` 可以让 `Pod` 自动调度到运行了指定容器运行时的节点上。但前提是需要用户提前为这些 `Node` 设置好 `label`。

`RuntimeClass` 中配置 `Overhead`，可以把 `Pod` 中业务运行所需意外的开销统计进来，让调度、`ResourceQuota`、`Kubelet` 驱逐 `Pod` 等行为更准确。

--------------------

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center]: /images/20221024/76102a15ce554aa4ae6420193149ef49.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221024/09e18419a8c44667baf3899baa6c271f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221024/cc18a8f4119e48f7aae36c747ea8e0a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221024/c5970c02c7db4dd19a362ffd5ccf415f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221024/06a7a5d14ead4a85a14e8ab4c88bc42d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221024/a30179d45f4e4aea81e198a4c5e6308c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221024/7078f38f39c341309ba6788795138084.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L21pc3MxMTgxMjQ4OTgz_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221024/18dfd29fa46143dd8fa0a85a10dca39d.png