Merge pull request #27741 from tengqm/zh-sync-concepts-2

[zh] Resync concepts files (2)

Author: k8s-ci-robot

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

@@ -1,7 +1,7 @@
 ---
 title: 将 Pod 分配给节点
 content_type: concept
-weight: 50
+weight: 20
 ---
 
 <!--
@@ -11,24 +11,24 @@ reviewers:
 - bsalamat
 title: Assigning Pods to Nodes
 content_type: concept
-weight: 50
+weight: 20
 -->
 
 <!-- overview -->
 
 <!--
-You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} to only be able to run on particular
-{{< glossary_tooltip text="Node(s)" term_id="node" >}}, or to prefer to run on particular nodes.
+You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
+{{< glossary_tooltip text="Node(s)" term_id="node" >}}.
 There are several ways to do this, and the recommended approaches all use
-[label selectors](/docs/concepts/overview/working-with-objects/labels/) to make the selection.
+[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
 Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
-(e.g. spread your pods across nodes, not place the pod on a node with insufficient free resources, etc.)
+(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
 but there are some circumstances where you may want more control on a node where a pod lands, for example to ensure
 that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
 services that communicate a lot into the same availability zone.
 -->
 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的
-{{< glossary_tooltip text="节点" term_id="node" >}} 上运行，或者优先运行在特定的节点上。
+{{< glossary_tooltip text="节点" term_id="node" >}} 上运行。
 有几种方法可以实现这点，推荐的方法都是用
 [标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。
 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上，
@@ -132,22 +132,12 @@ Pod 将会调度到将标签添加到的节点上。
 ## Interlude: built-in node labels {#built-in-node-labels}
 
 In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
-with a standard set of labels. These labels are
+with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) for a list of these.
 -->
 ## 插曲：内置的节点标签 {#built-in-node-labels}
 
 除了你[添加](#attach-labels-to-node)的标签外，节点还预先填充了一组标准标签。
-这些标签有：
-
-* [`kubernetes.io/hostname`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname)
-* [`failure-domain.beta.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone)
-* [`failure-domain.beta.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion)
-* [`topology.kubernetes.io/zone`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`topology.kubernetes.io/region`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone)
-* [`beta.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type)
-* [`node.kubernetes.io/instance-type`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type)
-* [`kubernetes.io/os`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os)
-* [`kubernetes.io/arch`](/zh/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch)
+参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。
 
 {{< note >}}
 <!--
@@ -247,12 +237,12 @@ Pod 可以调度到哪些节点。
 <!--
 There are currently two types of node affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
 `preferredDuringSchedulingIgnoredDuringExecution`. You can think of them as "hard" and "soft" respectively,
-in the sense that the former specifies rules that *must* be met for a pod to be scheduled onto a node (just like
+in the sense that the former specifies rules that *must* be met for a pod to be scheduled onto a node (similar to
 `nodeSelector` but using a more expressive syntax), while the latter specifies *preferences* that the scheduler
 will try to enforce but will not guarantee. The "IgnoredDuringExecution" part of the names means that, similar
 to how `nodeSelector` works, if labels on a node change at runtime such that the affinity rules on a pod are no longer
-met, the pod will still continue to run on the node. In the future we plan to offer
-`requiredDuringSchedulingRequiredDuringExecution` which will be just like `requiredDuringSchedulingIgnoredDuringExecution`
+met, the pod continues to run on the node. In the future we plan to offer
+`requiredDuringSchedulingRequiredDuringExecution` which will be identical to `requiredDuringSchedulingIgnoredDuringExecution`
 except that it will evict pods from nodes that cease to satisfy the pods' node affinity requirements.
 -->
 目前有两种类型的节点亲和性，分别为 `requiredDuringSchedulingIgnoredDuringExecution` 和
@@ -264,8 +254,8 @@ except that it will evict pods from nodes that cease to satisfy the pods' node a
 如果节点的标签在运行时发生变更，从而不再满足 Pod 上的亲和性规则，那么 Pod
 将仍然继续在该节点上运行。
 将来我们计划提供 `requiredDuringSchedulingRequiredDuringExecution`，
-它将类似于 `requiredDuringSchedulingIgnoredDuringExecution`，
-除了它会将 pod 从不再满足 pod 的节点亲和性要求的节点上驱逐。
+它将与 `requiredDuringSchedulingIgnoredDuringExecution` 完全相同，
+只是它会将 Pod 从不再满足 Pod 的节点亲和性要求的节点上驱逐。
 
 <!--
 Thus an example of `requiredDuringSchedulingIgnoredDuringExecution` would be "only run the pod on nodes with Intel CPUs"
@@ -538,22 +528,23 @@ Pod 亲和性与反亲和性的合法操作符有 `In`，`NotIn`，`Exists`，`D
 然而，出于性能和安全原因，topologyKey 受到一些限制：
 
 <!--
-1. For affinity and for `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity,
-empty `topologyKey` is not allowed.
-2. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or simply disable it.
-3. For `preferredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, empty `topologyKey` is interpreted as "all topologies" ("all topologies" here is now limited to the combination of `kubernetes.io/hostname`, `topology.kubernetes.io/zone` and `topology.kubernetes.io/region`).
+1. For pod affinity, empty `topologyKey` is not allowed in both
+`requiredDuringSchedulingIgnoredDuringExecution`
+and `preferredDuringSchedulingIgnoredDuringExecution`.
+2. For pod anti-affinity, empty `topologyKey` is also not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
+and `preferredDuringSchedulingIgnoredDuringExecution`.
+3. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or disable it.
 4. Except for the above cases, the `topologyKey` can be any legal label-key.
 -->
-1. 对于亲和性与 `requiredDuringSchedulingIgnoredDuringExecution` 要求的
-   Pod 反亲和性，`topologyKey` 不允许为空。
-2. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
-   准入控制器 `LimitPodHardAntiAffinityTopology` 被引入来限制 `topologyKey`
-   为 `kubernetes.io/hostname`。
-   如果你想设置topologyKey为其他值来用于自定义拓扑结构，你必须修改准入控制器或者禁用它。
-3. 对于 `preferredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
-   空的 `topologyKey` 被解释为“所有拓扑结构”（这里的“所有拓扑结构”限制为
-   `kubernetes.io/hostname`，`topology.kubernetes.io/zone` 和
-   `topology.kubernetes.io/region` 的组合）。
+1. 对于 Pod 亲和性而言，在 `requiredDuringSchedulingIgnoredDuringExecution`
+   和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey` 不允许为空。
+2. 对于 Pod 反亲和性而言，`requiredDuringSchedulingIgnoredDuringExecution`
+   和 `preferredDuringSchedulingIgnoredDuringExecution` 中，`topologyKey`
+   都不可以为空。
+3. 对于 `requiredDuringSchedulingIgnoredDuringExecution` 要求的 Pod 反亲和性，
+   准入控制器 `LimitPodHardAntiAffinityTopology` 被引入以确保 `topologyKey`
+   只能是 `kubernetes.io/hostname`。如果你希望 `topologyKey` 也可用于其他定制
+   拓扑逻辑，你可以更改准入控制器或者禁用之。
 4. 除上述情况外，`topologyKey` 可以是任何合法的标签键。
 
 <!--
@@ -573,6 +564,36 @@ must be satisfied for the pod to be scheduled onto a node.
 所有与 `requiredDuringSchedulingIgnoredDuringExecution` 亲和性与反亲和性
 关联的 `matchExpressions` 必须满足，才能将 pod 调度到节点上。
 
+<!--
+#### Namespace selector
+-->
+#### 名字空间选择算符
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+<!--
+Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
+The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field.
+Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and 
+null `namespaceSelector` means "this pod's namespace".
+-->
+用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector`
+是对名字空间集合进行标签查询的机制。
+亲和性条件会应用到 `namespaceSelector` 所选择的名字空间和 `namespaces` 字段中
+所列举的名字空间之上。
+注意，空的 `namespaceSelector`（{}）会匹配所有名字空间，而 null 或者空的
+`namespaces` 列表以及 null 值 `namespaceSelector` 意味着“当前 Pod 的名字空间”。
+
+<!--
+This feature is alpha and disabled by default. You can enable it by setting the
+[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler.
+-->
+此功能特性是 Alpha 版本的，默认是被禁用的。你可以通过针对 kube-apiserver 和
+kube-scheduler 设置
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
+`PodAffinityNamespaceSelector` 来启用此特性。
+
 <!--
 #### More Practical Use-cases
 

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

@@ -1,13 +1,13 @@
 ---
 title: Kubernetes 调度器
 content_type: concept
-weight: 50
+weight: 10
 ---
 
 <!--
 title: Kubernetes Scheduler
 content_type: concept
-weight: 50
+weight: 10
 -->
 <!-- overview -->
 
@@ -173,13 +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
 * 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/)
 * 了解关于 [配置多个调度器](/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/resource-bin-packing.md

@@ -1,12 +1,16 @@
 ---
 title: 扩展资源的资源装箱
 content_type: concept
-weight: 50
+weight: 30
 ---
 <!--
+reviewers:
+- bsalamat
+- k82cn
+- ahg-g
 title: Resource Bin Packing for Extended Resources
 content_type: concept
-weight: 50
+weight: 30
 -->
 
 <!-- overview -->

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

@@ -78,12 +78,14 @@ had set a value of 100.
 kube-scheduler 的表现等价于设置值为 100。
 
 <!-- 
-To change the value, edit the kube-scheduler configuration file (this is likely
-to be `/etc/kubernetes/config/kube-scheduler.yaml`), then restart the scheduler.
- -->
-要修改这个值，编辑 kube-scheduler 的配置文件
-（通常是 `/etc/kubernetes/config/kube-scheduler.yaml`），
-然后重启调度器。
+To change the value, edit the
+[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+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/)，
+之后重启调度器。
+在很多场合下，配置文件位于 `/etc/kubernetes/config/kube-scheduler.yaml`。
 
 <!-- 
 After you have made this change, you can run
@@ -193,8 +195,8 @@ minimum value of 50 nodes.
 另外，还有一个 50 个 Node 的最小值是硬编码在程序中。
 
 <!--
-{{< note >}} In clusters with less than 50 feasible nodes, the scheduler still
-checks all the nodes, simply because there are not enough feasible nodes to stop
+In clusters with less than 50 feasible nodes, the scheduler still
+checks all the nodes because there are not enough feasible nodes to stop
 the scheduler's search early. 
 
 In a small cluster, if you set a low value for `percentageOfNodesToScore`, your
@@ -203,7 +205,6 @@ change will have no or little effect, for a similar reason.
 If your cluster has several hundred Nodes or fewer, leave this configuration option
 at its default value. Making changes is unlikely to improve the
 scheduler's performance significantly.
-{{< /note >}}
 -->
 {{< note >}}
 当集群中的可调度节点少于 50 个时，调度器仍然会去检查所有的 Node，
@@ -293,3 +294,8 @@ After going over all the Nodes, it goes back to Node 1.
 -->
 在评估完所有 Node 后，将会返回到 Node 1，从头开始。
 
+
+## {{% heading "whatsnext" %}}
+
+* 查阅 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+

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

@@ -1,6 +1,4 @@
 ---
-reviewers:
-- ahg-g
 title: 调度框架
 content_type: concept
 weight: 70
@@ -11,24 +9,25 @@ reviewers:
 - ahg-g
 title: Scheduling Framework
 content_type: concept
-weight: 60
+weight: 70
 -->
 
 <!-- overview -->
 
 {{< feature-state for_k8s_version="1.15" state="alpha" >}}
 
 <!--
-The scheduling framework is a plugable architecture for Kubernetes Scheduler
-that makes scheduler customizations easy. It adds a new set of "plugin" APIs to
-the existing scheduler. Plugins are compiled into the scheduler. The APIs
-allow most scheduling features to be implemented as plugins, while keeping the
+The scheduling framework is a plugable architecture for the Kubernetes Scheduler.
+It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled
+into the scheduler. The APIs allow most scheduling features to be implemented as
+plugins, while keeping the
 scheduling "core" simple and maintainable. Refer to the [design proposal of the
 scheduling framework][kep] for more technical information on the design of the
 framework.
 -->
-调度框架是 Kubernetes Scheduler 的一种可插入架构，可以简化调度器的自定义。
-它向现有的调度器增加了一组新的“插件” API。插件被编译到调度器程序中。
+调度框架是 Kubernetes 调度器的一种可插入架构。
+调度框架向现有的调度器增加了一组新的“插件（Plugin）” API。
+插件被编译到调度器程序中。
 这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。
 请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md)
 获取框架设计的更多技术信息。
@@ -328,15 +327,15 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟
 
 <!-- 
 While any plugin can access the list of "waiting" Pods and approve them
-(see [`FrameworkHandle`](#frameworkhandle)), we expect only the permit
+(see [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)), we expect only the permit
 plugins to approve binding of reserved Pods that are in "waiting" state. Once a Pod
 is approved, it is sent to the [PreBind](#pre-bind) phase.
  -->
 {{< note >}}
 尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 
-(查看 [`FrameworkHandle`](#frameworkhandle))。
-我们希望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。
-一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。
+（参阅 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)）。
+我们希望只有被允许的插件可以批准处于“等待中”状态的预留 Pod 的绑定。
+一旦 Pod 被批准了，它将进入到[预绑定](#pre-bind) 阶段。
 {{< /note >}}
 
 <!--

content/zh/docs/tasks/manage-gpus/scheduling-gpus.md

@@ -54,7 +54,7 @@ When the above conditions are true, Kubernetes will expose `amd.com/gpu` or
 `nvidia.com/gpu` as a schedulable resource.
 
 You can consume these GPUs from your containers by requesting
-`<vendor>.com/gpu` just like you request `cpu` or `memory`.
+`<vendor>.com/gpu` the same way you request `cpu` or `memory`.
 However, there are some limitations in how you specify the resource requirements
 when using GPUs:
 -->