Kubernetes容器运行时类-Kubernetes中文教程(二)

当前位置:　首页>> 技术小册>> Kubernetes中文教程(二)

RuntimeClass 是一个用于选择容器运行时配置的特性，容器运行时配置用于运行 Pod 中的容器。

## 动机

你可以在不同的 Pod 设置不同的 RuntimeClass，以提供性能与安全性之间的平衡。
例如，如果你的部分工作负载需要高级别的信息安全保证，你可以决定在调度这些 Pod
时尽量使它们在使用硬件虚拟化的容器运行时中运行。
这样，你将从这些不同运行时所提供的额外隔离中获益，代价是一些额外的开销。

你还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的 Pod。

## 设置

1. 在节点上配置 CRI 的实现（取决于所选用的运行时）
2. 创建相应的 RuntimeClass 资源

### 1. 在节点上配置 CRI 实现

RuntimeClass 的配置依赖于运行时接口（CRI）的实现。
根据你使用的 CRI 实现，查阅相关的文档（[下方]）来了解如何配置。

RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。
如果需要支持异构节点，配置方法请参阅下面的[调度]。

所有这些配置都具有相应的 `handler` 名，并被 RuntimeClass 引用。
handler 必须是有效的 [DNS 标签名]。

### 2. 创建相应的 RuntimeClass 资源

在上面步骤 1 中，每个配置都需要有一个用于标识配置的 `handler`。
针对每个 handler 需要创建一个 RuntimeClass 对象。

RuntimeClass 资源当前只有两个重要的字段：RuntimeClass 名  和 handler 。
对象定义如下所示：

```yaml
# RuntimeClass 定义于 node.k8s.io API 组
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  # 用来引用 RuntimeClass 的名字
  # RuntimeClass 是一个集群层面的资源
  name: myclass
# 对应的 CRI 配置的名称
handler: myconfiguration
```

RuntimeClass 对象的名称必须是有效的
[DNS 子域名]。

建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。
通常这是默认配置。参阅[授权概述]了解更多信息。

## 使用说明

一旦完成集群中 RuntimeClasses 的配置，
你可以在 Pod spec 中指定 `runtimeClassName` 来使用它。例如:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...
```

这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 Pod。
如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler，
那么 Pod 将会进入 `Failed` 终止[阶段]。
你可以查看相应的[事件]，
获取执行过程中的错误信息。

如果未指定 `runtimeClassName`，则将使用默认的 RuntimeHandler，相当于禁用 RuntimeClass 功能特性。

### CRI 配置

关于如何安装 CRI 运行时，请查阅
[CRI 安装]。

####

通过 containerd 的 `/etc/containerd/config.toml` 配置文件来配置运行时 handler。
handler 需要配置在 runtimes 块中：

```
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```

更详细信息，请查阅 containerd 的[配置指南]

####

通过 CRI-O 的 `/etc/crio/crio.conf` 配置文件来配置运行时 handler。
handler 需要配置在
[crio.runtime 表]之下：

```
[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"
```

更详细信息，请查阅 CRI-O [配置文档]。

## 调度

通过为 RuntimeClass 指定 `scheduling` 字段，
你可以通过设置约束，确保运行该 RuntimeClass 的 Pod 被调度到支持该 RuntimeClass 的节点上。
如果未设置 `scheduling`，则假定所有节点均支持此 RuntimeClass。

为了确保 pod 会被调度到支持指定运行时的 node 上，每个 node 需要设置一个通用的 label 用于被
`runtimeclass.scheduling.nodeSelector` 挑选。在 admission 阶段，RuntimeClass 的 nodeSelector 将会与
Pod 的 nodeSelector 合并，取二者的交集。如果有冲突，Pod 将会被拒绝。

如果 node 需要阻止某些需要特定 RuntimeClass 的 Pod，可以在 `tolerations` 中指定。
与 `nodeSelector` 一样，tolerations 也在 admission 阶段与 Pod 的 tolerations 合并，取二者的并集。

更多有关 node selector 和 tolerations 的配置信息，请查阅
[将 Pod 分派到节点]。

### Pod 开销

你可以指定与运行 Pod 相关的**开销**资源。声明开销即允许集群（包括调度器）在决策 Pod 和资源时将其考虑在内。

Pod 开销通过 RuntimeClass 的 `overhead` 字段定义。
通过使用这个字段，你可以指定使用该 RuntimeClass 运行 Pod 时的开销并确保 Kubernetes 将这些开销计算在内。

- [RuntimeClass 设计]
- [RuntimeClass 调度设计]
- 阅读关于 [Pod 开销]的概念
- [PodOverhead 特性设计]

该分类下的相关小册推荐：

Kubernets合辑3-kubernetes介绍

Kubernets合辑2-部署Ingress

Kubernets合辑15-持续部署

Kubernetes中文教程(五)

Kubernets合辑5-Pod控制器

Kubernets合辑8-权限控制

Kubernets合辑6-服务发现

Kubernetes中文教程(六)

Kubernets合辑7-存储

Kubernets合辑10-网络

Kubernets合辑11-持续集成

云原生-K8S入门实战