Merge master into dev-1.22 to keep in sync

Signed-off-by: Ritu Panjwani <panjwaniritu45@gmail.com>

content/en/docs/concepts/cluster-administration/flow-control.md

@@ -526,6 +526,6 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves
 
 
 For background information on design details for API priority and fairness, see
-the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md).
+the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness).
 You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) 
 or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness).

content/en/docs/concepts/policy/pod-security-policy.md

@@ -464,12 +464,12 @@ allowed prefix, and a `readOnly` field indicating it must be mounted read-only.
 For example:
 
 ```yaml
-allowedHostPaths:
-  # This allows "/foo", "/foo/", "/foo/bar" etc., but
-  # disallows "/fool", "/etc/foo" etc.
-  # "/foo/../" is never valid.
-  - pathPrefix: "/foo"
-    readOnly: true # only allow read-only mounts
+  allowedHostPaths:
+    # This allows "/foo", "/foo/", "/foo/bar" etc., but
+    # disallows "/fool", "/etc/foo" etc.
+    # "/foo/../" is never valid.
+    - pathPrefix: "/foo"
+      readOnly: true # only allow read-only mounts
 ```
 
 {{< warning >}}There are many ways a container with unrestricted access to the host

content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md

@@ -26,40 +26,41 @@ each resource to score nodes based on the request to capacity ratio. This
 allows users to bin pack extended resources by using appropriate parameters
 and improves the utilization of scarce resources in large clusters. The
 behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
-can be controlled by a configuration option called
-`requestedToCapacityRatioArguments`. This argument consists of two parameters
-`shape` and `resources`. The `shape` parameter allows the user to tune the
-function as least requested or most requested based on `utilization` and
-`score` values.  The `resources` parameter consists of `name` of the resource
-to be considered during scoring and `weight` specify the weight of each
-resource.
+can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. 
+This argument consists of two parameters `shape` and `resources`. The `shape` 
+parameter allows the user to tune the function as least requested or most 
+requested based on `utilization` and `score` values.  The `resources` parameter 
+consists of `name` of the resource to be considered during scoring and `weight` 
+specify the weight of each resource.
 
 Below is an example configuration that sets
 `requestedToCapacityRatioArguments` to bin packing behavior for extended
 resources `intel.com/foo` and `intel.com/bar`.
 
 ```yaml
-apiVersion: v1
-kind: Policy
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+profiles:
 # ...
-priorities:
-  # ...
-  - name: RequestedToCapacityRatioPriority
-    weight: 2
-    argument:
-      requestedToCapacityRatioArguments:
-        shape:
-          - utilization: 0
-            score: 0
-          - utilization: 100
-            score: 10
-        resources:
-          - name: intel.com/foo
-            weight: 3
-          - name: intel.com/bar
-            weight: 5
+  pluginConfig:
+  - name: RequestedToCapacityRatio
+    args: 
+      shape:
+      - utilization: 0
+        score: 10
+      - utilization: 100
+        score: 0
+      resources:
+      - name: intel.com/foo
+        weight: 3
+      - name: intel.com/bar
+        weight: 5
 ```
 
+Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler 
+flag `--config=/path/to/config/file` will pass the configuration to the 
+scheduler.
+
 **This feature is disabled by default**
 
 ### Tuning the Priority Function

content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md

@@ -10,7 +10,7 @@ weight: 40
 
 
 <!-- overview -->
-[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity),
+[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
 is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to
 a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a
 hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods.

content/en/docs/concepts/services-networking/topology-aware-hints.md

@@ -13,7 +13,7 @@ weight: 45
 
 _Topology Aware Hints_ enable topology aware routing by including suggestions
 for how clients should consume endpoints. This approach adds metadata to enable
-consumers of EndpointSlice and / or and Endpoints objects, so that traffic to
+consumers of EndpointSlice and / or Endpoints objects, so that traffic to
 those network endpoints can be routed closer to where it originated.
 
 For example, you can route traffic within a locality to reduce