Update based on feedback

Signed-off-by: Anshuman Tripathi <[email protected]>

content/en/docs/concepts/security/hardening-guide/scheduler.md

@@ -11,20 +11,20 @@ The Kubernetes {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}
 one of the critical components of the
 {{< glossary_tooltip text="control plane" term_id="control-plane" >}}.
 
-This document covers how to improve the security posture of the Schduler.
+This document covers how to improve the security posture of the Scheduler.
 
 A misconfigured scheduler can have security implications. Such a scheduler can target specific nodes and evict the workloads or applications that are sharing the node and its resources. This can aid an attacker with a [Yo-Yo attack](https://arxiv.org/abs/2105.00542): an attack on a vulnerable autoscaler.
 <!-- body -->
 ## kube-scheduler configuration
 
 ### Scheduler authentication & authorization command line options
 {{<table caption="Security advice for kube-scheduler command line options relating to authentication or authorization" >}}
-| Command line argument                    | Security hardening advice                                                                                                           |
-| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
-| `authentication-kubeconfig`              | Make sure to provide a proper kubeconfig so that the server calls are secure. This kubeconfig file should also maintained securely. |
-| `authentication-tolerate-lookup-failure` | Set to `false` to make sure invalid authentication configurations do not lead to requests passing off as anonymous                  |
-| `authentication-skip-lookup`             | This should be set to `false` to make sure all missing authentication configuration falls back to the authentication kubeconfig.    |
-| `authorization-always-allow-paths`       | These paths should respond with data that is appropriate for anonymous authorization. Defaults to `/healthz,/readyz,/livez`.        |
+| Command line argument                    | Security hardening advice                                                                                                              |
+| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| `authentication-kubeconfig`              | Make sure to provide a proper kubeconfig so that the server calls are secure. This kubeconfig file should also be maintained securely. |
+| `authentication-tolerate-lookup-failure` | Set to `false` to make sure invalid authentication configurations do not lead to requests passing off as anonymous                     |
+| `authentication-skip-lookup`             | This should be set to `false` to make sure all missing authentication configuration falls back to the authentication kubeconfig.       |
+| `authorization-always-allow-paths`       | These paths should respond with data that is appropriate for anonymous authorization. Defaults to `/healthz,/readyz,/livez`.           |
 {{</table>}}
 
 ### Scheduler networking command line options
@@ -47,20 +47,20 @@ A misconfigured scheduler can have security implications. Such a scheduler can t
 ## Scheduling configurations for custom schedulers
 This section covers security hardening when using custom schedulers based on the Kubernetes
 scheduling code.
-The cluster administrator needs be careful with the plugins that use the `queueSort`, `filter`, or permit [extension points](https://github.com/docs/reference/scheduling/config/#extension-points).
+The cluster administrator needs be careful with the plugins that use the `queueSort`, `prefilter`, `filter`, or permit [extension points](https://github.com/docs/reference/scheduling/config/#extension-points).
 Scheduling happens in a series of stages that are exposed through the extension points.
 As a cluster administrator, you can enable plugins that define their own extension points.
 Doing so can affect the defined scheduling behaviors of the kube-scheduler in your cluster.
 
-When using a custom scheduler, plugin extension points such as `queueSort`, `filter` and `permit` should be used with care.
+When using a custom scheduler, plugin extension points such as `queueSort`, `prefilter`, `filter` and `permit` should be used with care.
 
 Exactly one plugin that uses the `queueSort` extension point can be enabled at a time. Any plugins that use `queueSort` should be scrutinized.
 
-Plugins that implement the `filter` extension point can potentially mark all nodes as unschedulable. This can bring scheduling of new pods to a halt.
+Plugins that implement the `prefilter` or `filter` extension point can potentially mark all nodes as unschedulable. This can bring scheduling of new pods to a halt.
 
 Plugins that implement the `permit` extension point  can prevent or delay the binding of a Pod. Such plugins should be thoroughly reviewed by the cluster administrator.
 
-When using a plugin that is not one of the [default plugins](https://kubernetes.io/docs/reference/scheduling/config/#scheduling-plugins), consider disabling the `queueSort`, `filter` and `permit` extension points as follows:
+When using a plugin that is not one of the [default plugins](/docs/reference/scheduling/config/#scheduling-plugins), consider disabling the `queueSort`, `filter` and `permit` extension points as follows:
 
 ```yaml
 apiVersion: kubescheduler.config.k8s.io/v1
@@ -81,11 +81,10 @@ profiles:
 ```
 This creates two scheduler profiles: `default-scheduler` and ` my-custom-scheduler`.
 Whenever the `.spec` of a Pod does not have a value for `.spec.schedulerName`,
-the kube-scheduler runs for that Pod, using its main configuration, and default plugin.
+the kube-scheduler runs for that Pod, using its main configuration, and default plugins.
 If you define a Pod with `.spec.schedulerName` set to `my-custom-scheduler`, the
 kube-scheduler also runs but with a custom configuration; in that custom configuration,
 the  `queueSort`, `filter` and `permit` extension points are disabled.
 If you use this kube-scheduler configuration, and don't run any custom scheduler, and
 you then define a Pod with  `.spec.schedulerName` set to `nonexistent-scheduler` (or
-any other scheduler name that doesn't exist in your cluster), then the Pod stays pending scheduling. You would see a `FailedScheduling` event for the Pod and could manually
-remove that Pod using `kubectl delete`.
+any other scheduler name that doesn't exist in your cluster), no events would be generated for a pod.