Merge pull request #29423 from mengjiao-liu/sync-scheduling-1.22

[zh] Concept files to sync for 1.22 - (9) Scheduling

content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md

@@ -579,7 +579,7 @@ must be satisfied for the pod to be scheduled onto a node.
 -->
 #### 名字空间选择算符
 
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
 
 <!--
 Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
@@ -595,14 +595,14 @@ null `namespaceSelector` means "this pod's namespace".
 `namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
 
 <!--
-This feature is alpha and disabled by default. You can enable it by setting the
+This feature is beta and enabled by default. You can disable it via the
 [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
 `PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler.
 -->
-此功能特性是 Alpha 版本的，默认是被禁用的。你可以通过针对 kube-apiserver 和
+此功能特性是 Beta 版本的，默认是被启用的。你可以通过针对 kube-apiserver 和
 kube-scheduler 设置
 [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 来启用此特性。
+`PodAffinityNamespaceSelector` 来禁用此特性。
 
 <!--
 #### More Practical Use-cases

content/zh/docs/concepts/scheduling-eviction/kube-scheduler.md

@@ -95,7 +95,7 @@ the API server about this decision in a process called _binding_.
 kube-apiserver，这个过程叫做 _绑定_。
 
 <!--
-Factors that need taken into account for scheduling decisions include
+Factors that need to be taken into account for scheduling decisions include
 individual and collective resource requirements, hardware / software /
 policy constraints, affinity and anti-affinity specifications, data
 locality, inter-workload interference, and so on.
@@ -173,15 +173,15 @@ of the scheduler:
 * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler
-* Read the [kube-scheduler config (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference
+* Read the [kube-scheduler config (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference
 * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
 * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/)
 * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
 -->
 * 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
 * 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
 * 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/)
-* 阅读 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* 阅读 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 * 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式
 * 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)
 * 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)

content/zh/docs/concepts/scheduling-eviction/pod-priority-preemption.md

@@ -432,17 +432,17 @@ the Node is not considered for preemption.
 {{< /note >}}
 
 <!-- 
-If a pending Pod has inter-pod affinity to one or more of the lower-priority
-Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence
-of those lower-priority Pods. In this case, the scheduler does not preempt any
-Pods on the Node. Instead, it looks for another Node. The scheduler might find a
-suitable Node or it might not. There is no guarantee that the pending Pod can be
-scheduled.
+If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}}
+to one or more of the lower-priority Pods on the Node, the inter-Pod affinity
+rule cannot be satisfied in the absence of those lower-priority Pods. In this case, 
+the scheduler does not preempt any Pods on the Node. Instead, it looks for another
+Node. The scheduler might find a suitable Node or it might not. There is no 
+guarantee that the pending Pod can be scheduled.
 
 Our recommended solution for this problem is to create inter-Pod affinity only
 towards equal or higher priority Pods.
 -->
-如果悬决 Pod 与节点上的一个或多个较低优先级 Pod 具有 Pod 间亲和性，
+如果悬决 Pod 与节点上的一个或多个较低优先级 Pod 具有 Pod 间{{< glossary_tooltip text="亲和性" term_id="affinity" >}}，
 则在没有这些较低优先级 Pod 的情况下，无法满足 Pod 间亲和性规则。
 在这种情况下，调度程序不会抢占节点上的任何 Pod。
 相反，它寻找另一个节点。调度程序可能会找到合适的节点，
@@ -620,33 +620,34 @@ Pod 优先级和 {{<glossary_tooltip text="QoS 类" term_id="qos-class" >}}
 或者最低优先级的 Pod 受 PodDisruptionBudget 保护时，才会考虑优先级较高的 Pod。
 
 <!-- 
-The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
+The kubelet uses Priority to determine pod order for [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
 You can use the QoS class to estimate the order in which pods are most likely
 to get evicted. The kubelet ranks pods for eviction based on the following factors:
 
   1. Whether the starved resource usage exceeds requests
   1. Pod Priority
   1. Amount of resource usage relative to requests 
 
-See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
+See [evicting end-user pods](/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)
 for more details.
 
-kubelet out-of-resource eviction does not evict Pods when their
+kubelet node-pressure eviction does not evict Pods when their
 usage does not exceed their requests. If a Pod with lower priority is not
 exceeding its requests, it won't be evicted. Another Pod with higher priority
 that exceeds its requests may be evicted.
 -->
 kubelet 使用优先级来确定
-[资源不足时驱逐](/zh/docs/tasks/administer-cluster/out-of-resource/) Pod 的顺序。
+[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) Pod 的顺序。
 你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名：
 
   1. 对紧俏资源的使用是否超过请求值
   1. Pod 优先级
   1. 相对于请求的资源使用量
 
-有关更多详细信息，请参阅[驱逐最终用户的 Pod](/zh/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)。
+有关更多详细信息，请参阅
+[kubelet 驱逐时 Pod 的选择](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。
 
-当某 Pod 的资源用量未超过其请求时，kubelet 资源不足驱逐不会驱逐该 Pod。
+当某 Pod 的资源用量未超过其请求时，kubelet 节点压力驱逐不会驱逐该 Pod。
 如果优先级较低的 Pod 没有超过其请求，则不会被驱逐。
 另一个优先级高于其请求的 Pod 可能会被驱逐。
 

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

@@ -32,60 +32,70 @@ The kube-scheduler can be configured to enable bin packing of resources along wi
 <!--
 ## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
 
-Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for 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`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
-consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
+Kubernetes allows the users to specify the resources along with weights for
+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 `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.
+
 -->
 
 ## 使用 RequestedToCapacityRatioResourceAllocation 启用装箱
 
-在 Kubernetes 1.15 之前，Kube-scheduler 通常允许根据对主要资源（如 CPU 和内存）
-的请求数量和可用容量 之比率对节点评分。
-Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许用户指定资源以及每类资源的权重，
+Kubernetes 允许用户指定资源以及每类资源的权重，
 以便根据请求数量与可用容量之比率为节点评分。
 这就使得用户可以通过使用适当的参数来对扩展资源执行装箱操作，从而提高了大型集群中稀缺资源的利用率。
 `RequestedToCapacityRatioResourceAllocation` 优先级函数的行为可以通过名为
-`requestedToCapacityRatioArguments` 的配置选项进行控制。
+`RequestedToCapacityRatioArgs` 的配置选项进行控制。
 该标志由两个参数 `shape` 和 `resources` 组成。
-`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为最少请求
-（least requested）或
-最多请求（most requested）计算。
+`shape` 允许用户根据 `utilization` 和 `score` 值将函数调整为
+最少请求（least requested）或最多请求（most requested）计算。
 `resources` 包含由 `name` 和  `weight` 组成，`name` 指定评分时要考虑的资源，
 `weight` 指定每种资源的权重。
 
 <!--
-Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
+Below is an example configuration that sets
+`requestedToCapacityRatioArguments` to bin packing behavior for extended
+resources `intel.com/foo` and `intel.com/bar`.
 -->
 
 以下是一个配置示例，该配置将 `requestedToCapacityRatioArguments` 设置为对扩展资源
 `intel.com/foo` 和 `intel.com/bar` 的装箱行为
 
-```json
-{
-  "kind": "Policy",
-  "apiVersion": "v1",
-  ...
-  "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}
-          ]
-        }
-      }
-    }
-  ],
-}
+```yaml
+apiVersion: kubescheduler.config.k8s.io/v1beta1
+kind: KubeSchedulerConfiguration
+profiles:
+# ...
+  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.
+-->
+使用 kube-scheduler 标志 `--config=/path/to/config/file` 
+引用 `KubeSchedulerConfiguration` 文件将配置传递给调度器。
+
 <!--
 **This feature is disabled by default**
 -->

content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -81,11 +81,11 @@ kube-scheduler 的表现等价于设置值为 100。
 
 <!--
 To change the value, edit the
-[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 and then restart the scheduler.
 In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`
  -->
-要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)
 然后重启调度器。
 大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。
 
@@ -298,6 +298,6 @@ After going over all the Nodes, it goes back to Node 1.
 
 ## {{% heading "whatsnext" %}}
 
-<!-- * Check the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) -->
+<!-- * Check the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) -->
 
-* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/)

content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md

@@ -16,7 +16,7 @@ weight: 90
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="1.15" state="alpha" >}}
+{{< feature-state for_k8s_version="1.19" state="stable" >}}
 
 <!--
 The scheduling framework is a pluggable architecture for the Kubernetes scheduler.