Drop feature availability from Reserve Compute Resources (#19593)

* Drop feature availability section

This section does not fit with the website style guide.

* State task version requirements

Follow website style guide for stating these.

content/en/docs/tasks/administer-cluster/reserve-compute-resources.md

@@ -5,6 +5,7 @@ reviewers:
 - dashpole
 title: Reserve Compute Resources for System Daemons
 content_template: templates/task
+min-kubernetes-server-version: 1.8
 ---
 
 {{% capture overview %}}
@@ -27,6 +28,9 @@ on each node.
 {{% capture prerequisites %}}
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+Your Kubernetes server must be at or later than version 1.17 to use
+the kubelet command line option `--reserved-cpus` to set an
+[explicitly reserved CPU list](#explicitly-reserved-cpu-list).
 
 {{% /capture %}}
 
@@ -152,9 +156,9 @@ exist. Kubelet will fail if an invalid cgroup is specified.
 - **Kubelet Flag**: `--reserved-cpus=0-3`
 
 `reserved-cpus` is meant to define an explicit CPU set for OS system daemons and
-kubernetes system daemons. This option is added in 1.17 release. `reserved-cpus`
+kubernetes system daemons. `reserved-cpus` is for systems that do not intend to
-is for systems that do not intent to define separate top level cgroups for
+define separate top level cgroups for OS system daemons and kubernetes system daemons
-OS system daemons and kubernetes system daemons with regard to cpuset resource.
+with regard to cpuset resource.
 If the Kubelet **does not** have `--system-reserved-cgroup` and `--kube-reserved-cgroup`,
 the explicit cpuset provided by `reserved-cpus` will take precedence over the CPUs
 defined by `--kube-reserved` and `--system-reserved` options.
@@ -253,36 +257,4 @@ If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
 exceed their reservation, `kubelet` evicts pods whenever the overall node memory
 usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
 
-## Feature Availability
-
-As of Kubernetes version 1.2, it has been possible to **optionally** specify
-`kube-reserved` and `system-reserved` reservations. The scheduler switched to
-using `Allocatable` instead of `Capacity` when available in the same release.
-
-As of Kubernetes version 1.6, `eviction-thresholds` are being considered by
-computing `Allocatable`. To revert to the old behavior set
-`--experimental-allocatable-ignore-eviction` kubelet flag to `true`.
-
-As of Kubernetes version 1.6, `kubelet` enforces `Allocatable` on pods using
-control groups. To revert to the old behavior unset `--enforce-node-allocatable`
-kubelet flag. Note that unless `--kube-reserved`, or `--system-reserved` or
-`--eviction-hard` flags have non-default values, `Allocatable` enforcement does
-not affect existing deployments.
-
-As of Kubernetes version 1.6, `kubelet` launches pods in their own cgroup
-sandbox in a dedicated part of the cgroup hierarchy it manages. Operators are
-required to drain their nodes prior to upgrade of the `kubelet` from prior
-versions in order to ensure pods and their associated containers are launched in
-the proper part of the cgroup hierarchy.
-
-As of Kubernetes version 1.7, `kubelet` supports specifying `storage` as a resource
-for `kube-reserved` and `system-reserved`.
-
-As of Kubernetes version 1.8, the `storage` key name was changed to `ephemeral-storage`
-for the alpha release.
-
-As of Kubernetes version 1.17, you can optionally specify
-explicit cpuset by `reserved-cpus` as CPUs reserved for OS system
-daemons/interrupts/timers and Kubernetes daemons.
-
 {{% /capture %}}