diff --git a/content/zh-cn/blog/_posts/2018-10-10-runtimeclass.md b/content/zh-cn/blog/_posts/2018-10-10-runtimeclass.md index 09e6d9b387..20185edbb3 100644 --- a/content/zh-cn/blog/_posts/2018-10-10-runtimeclass.md +++ b/content/zh-cn/blog/_posts/2018-10-10-runtimeclass.md @@ -19,11 +19,11 @@ date: 2018-10-10 Kubernetes originally launched with support for Docker containers running native applications on a Linux host. Starting with [rkt](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/) in Kubernetes 1.3 more runtimes were coming, which lead to the development of the [Container Runtime Interface](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) (CRI). Since then, the set of alternative runtimes has only expanded: projects like [Kata Containers](https://katacontainers.io/) and [gVisor](https://github.com/google/gvisor) were announced for stronger workload isolation, and Kubernetes' Windows support has been [steadily progressing](https://kubernetes.io/blog/2018/01/kubernetes-v19-beta-windows-support/). --> Kubernetes 最初是为了支持在 Linux 主机上运行本机应用程序的 Docker 容器而创建的。 -从 Kubernetes 1.3中的 [rkt](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/) 开始，更多的运行时间开始涌现， +从 Kubernetes 1.3 中的 [rkt](https://kubernetes.io/blog/2016/07/rktnetes-brings-rkt-container-engine-to-kubernetes/) 开始，更多的运行时间开始涌现， 这导致了[容器运行时接口（Container Runtime Interface）](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)（CRI）的开发。 从那时起，备用运行时集合越来越大： 为了加强工作负载隔离，[Kata Containers](https://katacontainers.io/) 和 [gVisor](https://github.com/google/gvisor) 等项目被发起， -并且 Kubernetes 对 Windows 的支持正在 [稳步发展](https://kubernetes.io/blog/2018/01/kubernetes-v19-beta-windows-support/) 。 +并且 Kubernetes 对 Windows 的支持正在[稳步发展](https://kubernetes.io/blog/2018/01/kubernetes-v19-beta-windows-support/)。 最近，RuntimeClass 在 Kubernetes 1.12 中作为 alpha 功能引入。 -最初的实现侧重于提供运行时选择 API ，并为解决其他未解决的问题铺平道路。 +最初的实现侧重于提供运行时选择 API，并为解决其他未解决的问题铺平道路。 RuntimeClass 资源是将运行时属性显示到控制平面的重要基础。 例如，要对具有支持不同运行时间的异构节点的集群实施调度程序支持，我们可以在 RuntimeClass 定义中添加 -[NodeAffinity](/zh-cn/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。 +[NodeAffinity](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 条件。 另一个需要解决的领域是管理可变资源需求以运行不同运行时的 Pod。 -[Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) -是一项较早的尝试，与 RuntimeClass 设计非常吻合，并且可能会进一步推广。 +[Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview)是一项较早的尝试，与 +RuntimeClass 设计非常吻合，并且可能会进一步推广。 -至少要到2019年，RuntimeClass 才会得到积极的开发，我们很高兴看到从 Kubernetes 1.12 中的 RuntimeClass alpha 开始，此功能得以形成。 +至少要到 2019 年，RuntimeClass 才会得到积极的开发，我们很高兴看到从 Kubernetes 1.12 中的 RuntimeClass alpha 开始，此功能得以形成。 -- 试试吧！ 作为Alpha功能，还有一些其他设置步骤可以使用RuntimeClass。 - 有关如何使其运行，请参考 [RuntimeClass文档](/zh-cn/docs/concepts/containers/runtime-class/#runtime-class) 。 -- 查看 [RuntimeClass Kubernetes 增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) 以获取更多细节设计细节。 -- [沙盒隔离级别决策](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) - 记录了最初使 RuntimeClass 成为 Pod 级别选项的思考过程。 -- 加入讨论，并通过 [SIG-Node社区](https://github.com/kubernetes/community/tree/master/sig-node) 帮助塑造 RuntimeClass 的未来。 - +- 试试吧！作为 Alpha 功能，还有一些其他设置步骤可以使用 RuntimeClass。 + 有关如何使其运行，请参考 [RuntimeClass 文档](/zh-cn/docs/concepts/containers/runtime-class/#runtime-class)。 +- 查看 [RuntimeClass Kubernetes 增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md)以获取更多细节设计细节。 +- [沙盒隔离级别决策](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview)记录了最初使 + RuntimeClass 成为 Pod 级别选项的思考过程。 +- 加入讨论，并通过 [SIG-Node 社区](https://github.com/kubernetes/community/tree/master/sig-node)帮助塑造 RuntimeClass 的未来。 diff --git a/content/zh-cn/docs/concepts/containers/runtime-class.md b/content/zh-cn/docs/concepts/containers/runtime-class.md index 808db309ea..f528d81e28 100644 --- a/content/zh-cn/docs/concepts/containers/runtime-class.md +++ b/content/zh-cn/docs/concepts/containers/runtime-class.md @@ -16,7 +16,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.20" state="stable" >}} - - 你还可以使用 RuntimeClass 运行具有相同容器运行时但具有不同设置的 Pod。 - @@ -77,12 +77,12 @@ CRI implementation for how to configure. RuntimeClass 的配置依赖于 运行时接口（CRI）的实现。 根据你使用的 CRI 实现，查阅相关的文档（[下方](#cri-configuration)）来了解如何配置。 +{{< note >}} -{{< note >}} RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的节点在容器运行时方面的配置是相同的）。 如果需要支持异构节点，配置方法请参阅下面的 [调度](#scheduling)。 {{< /note >}} @@ -102,7 +102,7 @@ the configuration. For each handler, create a corresponding RuntimeClass object. --> ### 2. 创建相应的 RuntimeClass 资源 -在上面步骤 1 中，每个配置都需要有一个用于标识配置的 `handler`。 +在上面步骤 1 中，每个配置都需要有一个用于标识配置的 `handler`。 针对每个 handler 需要创建一个 RuntimeClass 对象。 +RuntimeClass 对象的名称必须是有效的 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + +{{< note >}} -{{< note >}} 建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。 通常这是默认配置。参阅[授权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)了解更多信息。 {{< /note >}} @@ -172,9 +179,9 @@ error message. If no `runtimeClassName` is specified, the default RuntimeHandler will be used, which is equivalent to the behavior when the RuntimeClass feature is disabled. --> -如果未指定 `runtimeClassName` ，则将使用默认的 RuntimeHandler，相当于禁用 RuntimeClass 功能特性。 +如果未指定 `runtimeClassName`，则将使用默认的 RuntimeHandler，相当于禁用 RuntimeClass 功能特性。 - 通过 containerd 的 `/etc/containerd/config.toml` 配置文件来配置运行时 handler。 -handler 需要配置在 runtimes 块中： +handler 需要配置在 runtimes 块中： ``` [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] @@ -203,17 +210,16 @@ for more details: --> 更详细信息，请查阅 containerd 的[配置指南](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) -#### [cri-o](https://cri-o.io/) +#### {{< glossary_tooltip term_id="cri-o" >}} -通过 cri-o 的 `/etc/crio/crio.conf` 配置文件来配置运行时 handler。 +通过 CRI-O 的 `/etc/crio/crio.conf` 配置文件来配置运行时 handler。 handler 需要配置在 -[crio.runtime 表](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) -下面： +[crio.runtime 表](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)之下： ``` [crio.runtime.runtimes.${HANDLER_NAME}] @@ -225,9 +231,9 @@ See CRI-O's [config documentation](https://github.com/cri-o/cri-o/blob/master/do --> 更详细信息，请查阅 CRI-O [配置文档](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md)。 - +--> ## 调度 {#scheduling} {{< feature-state for_k8s_version="v1.16" state="beta" >}} @@ -240,7 +246,7 @@ If `scheduling` is not set, this RuntimeClass is assumed to be supported by all 通过为 RuntimeClass 指定 `scheduling` 字段， 你可以通过设置约束，确保运行该 RuntimeClass 的 Pod 被调度到支持该 RuntimeClass 的节点上。 -如果未设置 `scheduling`，则假定所有节点均支持此 RuntimeClass 。 +如果未设置 `scheduling`，则假定所有节点均支持此 RuntimeClass。 -为了确保 pod 会被调度到支持指定运行时的 node 上，每个 node 需要设置一个通用的 label 用于被 +为了确保 pod 会被调度到支持指定运行时的 node 上，每个 node 需要设置一个通用的 label 用于被 `runtimeclass.scheduling.nodeSelector` 挑选。在 admission 阶段，RuntimeClass 的 nodeSelector 将会与 pod 的 nodeSelector 合并，取二者的交集。如果有冲突，pod 将会被拒绝。 @@ -263,22 +269,22 @@ by each. 与 `nodeSelector` 一样，tolerations 也在 admission 阶段与 pod 的 tolerations 合并，取二者的并集。 -更多有关 node selector 和 tolerations 的配置信息，请查阅 +更多有关 node selector 和 tolerations 的配置信息，请查阅 [将 Pod 分派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。 - +--> ### Pod 开销 {#pod-overhead} {{< feature-state for_k8s_version="v1.24" state="stable" >}} 你可以指定与运行 Pod 相关的 _开销_ 资源。声明开销即允许集群（包括调度器）在决策 Pod 和资源时将其考虑在内。