diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index f0008750a8..0c8b4aad79 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -13,22 +13,14 @@ weight: 20 This page describes the RuntimeClass resource and runtime selection mechanism. -{{< warning >}} -RuntimeClass includes *breaking* changes in the beta upgrade in v1.14. If you were using -RuntimeClass prior to v1.14, see [Upgrading RuntimeClass from Alpha to -Beta](#upgrading-runtimeclass-from-alpha-to-beta). -{{< /warning >}} +RuntimeClass is a feature for selecting the container runtime configuration. The container runtime +configuration is used to run a Pod's containers. {{% /capture %}} {{% capture body %}} -## Runtime Class - -RuntimeClass is a feature for selecting the container runtime configuration. The container runtime -configuration is used to run a Pod's containers. - ## Motivation You can set a different RuntimeClass between different Pods to provide a balance of @@ -41,7 +33,7 @@ additional overhead. You can also use RuntimeClass to run different Pods with the same container runtime but with different settings. -### Set Up +## Setup Ensure the RuntimeClass feature gate is enabled (it is by default). See [Feature Gates](/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling @@ -50,7 +42,7 @@ feature gates. The `RuntimeClass` feature gate must be enabled on apiservers _an 1. Configure the CRI implementation on nodes (runtime dependent) 2. Create the corresponding RuntimeClass resources -#### 1. Configure the CRI implementation on nodes +### 1. Configure the CRI implementation on nodes The configurations available through RuntimeClass are Container Runtime Interface (CRI) implementation dependent. See the corresponding documentation ([below](#cri-configuration)) for your @@ -65,7 +57,7 @@ heterogenous node configurations, see [Scheduling](#scheduling) below. The configurations have a corresponding `handler` name, referenced by the RuntimeClass. The handler must be a valid DNS 1123 label (alpha-numeric + `-` characters). -#### 2. Create the corresponding RuntimeClass resources +### 2. Create the corresponding RuntimeClass resources The configurations setup in step 1 should each have an associated `handler` name, which identifies the configuration. For each handler, create a corresponding RuntimeClass object. @@ -88,7 +80,7 @@ restricted to the cluster administrator. This is typically the default. See [Aut Overview](/docs/reference/access-authn-authz/authorization/) for more details. {{< /note >}} -### Usage +## Usage Once RuntimeClasses are configured for the cluster, using them is very simple. Specify a `runtimeClassName` in the Pod spec. For example: @@ -147,14 +139,14 @@ See CRI-O's [config documentation][100] for more details. [100]: https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md -### Scheduling +## Scheduling {{< feature-state for_k8s_version="v1.16" state="beta" >}} As of Kubernetes v1.16, RuntimeClass includes support for heterogenous clusters through its `scheduling` fields. Through the use of these fields, you can ensure that pods running with this RuntimeClass are scheduled to nodes that support it. To use the scheduling support, you must have -the RuntimeClass [admission controller][] enabled (the default, as of 1.16). +the [RuntimeClass admission controller][] enabled (the default, as of 1.16). To ensure pods land on nodes supporting a specific RuntimeClass, that set of nodes should have a common label which is then selected by the `runtimeclass.scheduling.nodeSelector` field. The @@ -170,7 +162,7 @@ by each. To learn more about configuring the node selector and tolerations, see [Assigning Pods to Nodes](/docs/concepts/configuration/assign-pod-node/). -[admission controller]: /docs/reference/access-authn-authz/admission-controllers/ +[RuntimeClass admission controller]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass ### Pod Overhead @@ -185,34 +177,8 @@ Pod overhead is defined in RuntimeClass through the `overhead` fields. Through t you can specify the overhead of running pods utilizing this RuntimeClass and ensure these overheads are accounted for in Kubernetes. -### Upgrading RuntimeClass from Alpha to Beta - -The RuntimeClass Beta feature includes the following changes: - -- The `node.k8s.io` API group and `runtimeclasses.node.k8s.io` resource have been migrated to a - built-in API from a CustomResourceDefinition. -- The `spec` has been inlined in the RuntimeClass definition (i.e. there is no more - RuntimeClassSpec). -- The `runtimeHandler` field has been renamed `handler`. -- The `handler` field is now required in all API versions. This means the `runtimeHandler` field in - the Alpha API is also required. -- The `handler` field must be a valid DNS label ([RFC 1123](https://tools.ietf.org/html/rfc1123)), - meaning it can no longer contain `.` characters (in all versions). Valid handlers match the - following regular expression: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`. - -**Action Required:** The following actions are required to upgrade from the alpha version of the -RuntimeClass feature to the beta version: - -- RuntimeClass resources must be recreated *after* upgrading to v1.14, and the - `runtimeclasses.node.k8s.io` CRD should be manually deleted: - ``` - kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io - ``` -- Alpha RuntimeClasses with an unspecified or empty `runtimeHandler` or those using a `.` character - in the handler are no longer valid, and must be migrated to a valid handler configuration (see - above). - -### Further Reading +{{% /capture %}} +{{% capture whatsnext %}} - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md)