Tidy RuntimeClass page for v1.18 (#19578)

* Tidy RuntimeClass page for v1.18

* Reword heading

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 is a feature for selecting the container runtime configuration. The container runtime
-RuntimeClass includes *breaking* changes in the beta upgrade in v1.14. If you were using
+configuration is used to run a Pod's containers.
-RuntimeClass prior to v1.14, see [Upgrading RuntimeClass from Alpha to
-Beta](#upgrading-runtimeclass-from-alpha-to-beta).
-{{< /warning >}}
 
 {{% /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
+{{% /capture %}}
-
+{{% capture whatsnext %}}
-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
 
 - [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)