24. RuntimeClass与多容器运行时

最新推荐文章于 2024-01-16 08:33:07 发布

最爱喝酸奶

最新推荐文章于 2024-01-16 08:33:07 发布

阅读量274

点赞数

分类专栏：云原生文章标签： kubernetes

原文链接：https://edu.aliyun.com/roadmap/cloudnative?spm=5176.13345299.1392477.3.3001f153M16rpD#suit

版权

云原生专栏收录该内容

24 篇文章 4 订阅

订阅专栏

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

RuntimeClass 需求

容器运行时的演进过程：

在这里插入图片描述

与此同时，越来越多的容器运行时也想接入到 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 的能力。

在这里插入图片描述

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 的结构体定义：

在这里插入图片描述

以 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 的调度。

在这里插入图片描述

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 不会对它们造成影响。

多容器运行时示例

在这里插入图片描述

上图有两个 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 默认放在 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 等行为更准确。

最爱喝酸奶

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
24. RuntimeClass与多容器运行时

本文由 CNCF + Alibaba 云原生技术公开课整理而来RuntimeClass 需求容器运行时的演进过程：与此同时，越来越多的容器运行时也想接入到 Kubernetes 中。如果还是按 rkt 和 Docker 一样内置支持的话，会给 Kubernetes 的代码维护和质量保障带来严重挑战。社区也意识到了这一点，所以在 1.5 版本时推出了 CRI，它的全称是 Container Runtime Interface。这样做的好处是：实现了运行时和 Kubernetes 的解耦，社.
复制链接

扫一扫