Graduate Pod Priority and Preemption to GA

content/en/docs/concepts/configuration/pod-priority-preemption.md

@@ -9,7 +9,7 @@ weight: 70
 
 {{% capture overview %}}
 
-{{< feature-state for_k8s_version="1.11" state="beta" >}}
+{{< feature-state for_k8s_version="1.14" state="GA" >}}
 
 [Pods](/docs/user-guide/pods) can have _priority_. Priority indicates the
 importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the
@@ -19,8 +19,8 @@ pending Pod possible.
 In Kubernetes 1.9 and later, Priority also affects scheduling order of Pods and
 out-of-resource eviction ordering on the Node.
 
-Pod priority and preemption are moved to beta since Kubernetes 1.11 and are
-enabled by default in this release and later.
+Pod priority and preemption graduated to beta in Kubernetes 1.11 and to GA in
+Kubernetes 1.14. They have been enabled by default since 1.11.
 
 In Kubernetes versions where Pod priority and preemption is still an alpha-level
 feature, you need to explicitly enable it. To use these features in the older
@@ -34,6 +34,7 @@ Kubernetes Version | Priority and Preemption State | Enabled by default
 1.9                | alpha                         | no
 1.10               | alpha                         | no
 1.11               | beta                          | yes
+1.14               | GA                            | yes
 
 {{< warning >}}In a cluster where not all users are trusted, a
 malicious user could create pods at the highest possible priorities, causing
@@ -71,15 +72,15 @@ Pods.
 ## How to disable preemption
 
 {{< note >}}
-In Kubernetes 1.11, critical pods (except DaemonSet pods, which are
-still scheduled by the DaemonSet controller) rely on scheduler preemption to be
-scheduled when a cluster is under resource pressure. For this reason, you will
-need to run an older version of Rescheduler if you decide to disable preemption.
-More on this is provided below.
+In Kubernetes 1.12+, critical pods rely on scheduler preemption to be scheduled
+when a cluster is under resource pressure. For this reason, it is not
+recommended to disable preemption.
 {{< /note >}}
 
 In Kubernetes 1.11 and later, preemption is controlled by a kube-scheduler flag
 `disablePreemption`, which is set to `false` by default.
+If you want to disable preemption despite the above note, you can set
+`disablePreemption` to `true`.
 
 This option is available in component configs only and is not available in
 old-style command line options. Below is a sample component config to disable
@@ -96,20 +97,6 @@ algorithmSource:
 disablePreemption: true
 ```
 
-### Start an older version of Rescheduler in the cluster
-
-When priority or preemption is disabled, we must run Rescheduler v0.3.1 (instead
-of v0.4.0) to ensure that critical Pods are scheduled when nodes or cluster are
-under resource pressure. Since critical Pod annotation is still supported in
-this release, running Rescheduler should be enough and no other changes to the
-configuration of Pods should be needed.
-
-Rescheduler images can be found at:
-[gcr.io/k8s-image-staging/rescheduler](http://gcr.io/k8s-image-staging/rescheduler).
-
-In the code, changing the Rescheduler version back to v.0.3.1 is the reverse of
-[this PR](https://github.com/kubernetes/kubernetes/pull/65454).
-
 ## PriorityClass
 
 A PriorityClass is a non-namespaced object that defines a mapping from a
@@ -364,11 +351,11 @@ Pod priority and
 [QoS](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md)
 are two orthogonal features with few interactions and no default restrictions on
 setting the priority of a Pod based on its QoS classes. The scheduler's
-preemption logic does consider QoS when choosing preemption targets. Preemption
-considers Pod priority and attempts to choose a set of targets with the lowest
-priority. Higher-priority Pods are considered for preemption only if the removal
-of the lowest priority Pods is not sufficient to allow the scheduler to schedule
-the preemptor Pod, or if the lowest priority Pods are protected by
+preemption logic does not consider QoS when choosing preemption targets.
+Preemption considers Pod priority and attempts to choose a set of targets with
+the lowest priority. Higher-priority Pods are considered for preemption only if
+the removal of the lowest priority Pods is not sufficient to allow the scheduler
+to schedule the preemptor Pod, or if the lowest priority Pods are protected by
 `PodDisruptionBudget`.
 
 The only component that considers both QoS and Pod priority is