[zh] Sync assign-pod-node.md

2023-10-17 16:40:30 +08:00 · 2023-10-17 16:40:30 +08:00 · 2d41f04907
parent e703cd91a0
commit 2d41f04907
4 changed files with 69 additions and 54 deletions
--- a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md
@ -59,8 +59,10 @@ specific Pods:
 ## Node labels {#built-in-node-labels}

 Like many other Kubernetes objects, nodes have
-[labels](/docs/concepts/overview/working-with-objects/labels/). You can [attach labels manually](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node).
-Kubernetes also populates a [standard set of labels](/docs/reference/node/node-labels/) on all nodes in a cluster.
+[labels](/docs/concepts/overview/working-with-objects/labels/). You can
+[attach labels manually](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node).
+Kubernetes also populates a [standard set of labels](/docs/reference/node/node-labels/)
+on all nodes in a cluster.
 -->
 ## 节点标签     {#built-in-node-labels}

@ -539,7 +541,7 @@ specified.

 如果当前正被调度的 Pod 在具有自我亲和性的 Pod 序列中排在第一个，
 那么只要它满足其他所有的亲和性规则，它就可以被成功调度。
-这是通过以下方式确定的：确保集群中没有其他 Pod 与此 Pod 的命名空间和标签选择器匹配；
+这是通过以下方式确定的：确保集群中没有其他 Pod 与此 Pod 的名字空间和标签选择算符匹配；
 该 Pod 满足其自身定义的条件，并且选定的节点满足所指定的所有拓扑要求。
 这确保即使所有的 Pod 都配置了 Pod 间亲和性，也不会出现调度死锁的情况。

@ -565,29 +567,40 @@ uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`.
 `preferredDuringSchedulingIgnoredDuringExecution`。

 <!--
-The affinity rule says that the scheduler can only schedule a Pod onto a node if
-the node is in the same zone as one or more existing Pods with the label
-`security=S1`. More precisely, the scheduler must place the Pod on a node that has the
-`topology.kubernetes.io/zone=V` label, as long as there is at least one node in
-that zone that currently has one or more Pods with the Pod label `security=S1`.
+The affinity rule specifies that the scheduler is allowed to place the example Pod 
+on a node only if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
+where other Pods have been labeled with `security=S1`. 
+For instance, if we have a cluster with a designated zone, let's call it "Zone V," 
+consisting of nodes labeled with `topology.kubernetes.io/zone=V`, the scheduler can 
+assign the Pod to any node within Zone V, as long as there is at least one Pod within 
+Zone V already labeled with `security=S1`. Conversely, if there are no Pods with `security=S1` 
+labels in Zone V, the scheduler will not assign the example Pod to any node in that zone.
 -->
-亲和性规则表示，仅当节点和至少一个已运行且有 `security=S1` 的标签的
-Pod 处于同一区域时，才可以将该 Pod 调度到节点上。
-更确切的说，调度器必须将 Pod 调度到具有 `topology.kubernetes.io/zone=V`
-标签的节点上，并且集群中至少有一个位于该可用区的节点上运行着带有
-`security=S1` 标签的 Pod。
+亲和性规则规定，只有节点属于特定的
+[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
+且该区域中的其他 Pod 已打上 `security=S1` 标签时，调度器才可以将示例 Pod 调度到此节点上。
+例如，如果我们有一个具有指定区域（称之为 "Zone V"）的集群，此区域由带有 `topology.kubernetes.io/zone=V`
+标签的节点组成，那么只要 Zone V 内已经至少有一个 Pod 打了 `security=S1` 标签，
+调度器就可以将此 Pod 调度到 Zone V 内的任何节点。相反，如果 Zone V 中没有带有 `security=S1` 标签的 Pod，
+则调度器不会将示例 Pod 调度给该区域中的任何节点。

 <!--
-The anti-affinity rule says that the scheduler should try to avoid scheduling
-the Pod onto a node that is in the same zone as one or more Pods with the label
-`security=S2`. More precisely, the scheduler should try to avoid placing the Pod on a node that has the
-`topology.kubernetes.io/zone=R` label if there are other nodes in the
-same zone currently running Pods with the `Security=S2` Pod label.
+The anti-affinity rule specifies that the scheduler should try to avoid scheduling the Pod 
+on a node if that node belongs to a specific [zone](/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
+where other Pods have been labeled with `security=S2`. 
+For instance, if we have a cluster with a designated zone, let's call it "Zone R," 
+consisting of nodes labeled with `topology.kubernetes.io/zone=R`, the scheduler should avoid 
+assigning the Pod to any node within Zone R, as long as there is at least one Pod within 
+Zone R already labeled with `security=S2`. Conversely, the anti-affinity rule does not impact 
+scheduling into Zone R if there are no Pods with `security=S2` labels.
 -->
-反亲和性规则表示，如果节点处于 Pod 所在的同一可用区且至少一个 Pod 具有
-`security=S2` 标签，则该 Pod 不应被调度到该节点上。
-更确切地说， 如果同一可用区中存在其他运行着带有 `security=S2` 标签的 Pod 节点，
-并且节点具有标签 `topology.kubernetes.io/zone=R`，Pod 不能被调度到该节点上。
+反亲和性规则规定，如果节点属于特定的
+[区域](/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/topology-spread-constraints/)
+且该区域中的其他 Pod 已打上 `security=S2` 标签，则调度器应尝试避免将 Pod 调度到此节点上。
+例如，如果我们有一个具有指定区域（我们称之为 "Zone R"）的集群，此区域由带有 `topology.kubernetes.io/zone=R`
+标签的节点组成，只要 Zone R 内已经至少有一个 Pod 打了 `security=S2` 标签，
+调度器应避免将 Pod 分配给 Zone R 内的任何节点。相反，如果 Zone R 中没有带有 `security=S2` 标签的 Pod，
+则反亲和性规则不会影响将 Pod 调度到 Zone R。

 <!--
 To get yourself more familiar with the examples of Pod affinity and anti-affinity,
@ -847,10 +860,10 @@ Some of the limitations of using `nodeName` to select nodes are:
 you need to bypass any configured schedulers. Bypassing the schedulers might lead to
 failed Pods if the assigned Nodes get oversubscribed. You can use [node affinity](#node-affinity) or a the [`nodeselector` field](#nodeselector) to assign a Pod to a specific Node without bypassing the schedulers.
 -->
-`nodeName` 旨在供自定义调度程序或需要绕过任何已配置调度程序的高级场景使用。
-如果已分配的 Node 负载过重，绕过调度程序可能会导致 Pod 失败。
+`nodeName` 旨在供自定义调度器或需要绕过任何已配置调度器的高级场景使用。
+如果已分配的 Node 负载过重，绕过调度器可能会导致 Pod 失败。
 你可以使用[节点亲和性](#node-affinity)或 [`nodeselector` 字段](#nodeselector)将
-Pod 分配给特定 Node，而无需绕过调度程序。
+Pod 分配给特定 Node，而无需绕过调度器。
 {{</ note >}}

 <!--
--- a/content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md
+++ b/content/zh-cn/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md
@ -46,7 +46,8 @@ Kubernetes v{{< skew currentVersion >}} 包含用于动态资源分配的集群

 <!-- body -->

-## API {#api}
+## API
+
 <!-- 
 The `resource.k8s.io/v1alpha2` {{< glossary_tooltip text="API group"
 term_id="api-group" >}} provides four types:
@ -101,9 +102,8 @@ typically using the type defined by a {{< glossary_tooltip
 term_id="CustomResourceDefinition" text="CRD" >}} that was created when
 installing a resource driver.
 -->
-ResourceClass 和 ResourceClaim 的参数存储在单独的对象中，
-通常使用安装资源驱动程序时创建的 {{< glossary_tooltip
-term_id="CustomResourceDefinition" text="CRD" >}} 所定义的类型。
+ResourceClass 和 ResourceClaim 的参数存储在单独的对象中，通常使用安装资源驱动程序时创建的
+{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}} 所定义的类型。

 <!-- 
 The `core/v1` `PodSpec` defines ResourceClaims that are needed for a Pod in a
@ -274,7 +274,7 @@ or not reserved for the Pod, then the kubelet will fail to run the Pod and
 re-check periodically because those requirements might still get fulfilled
 later.
 -->
-## 预调度的 Pod
+## 预调度的 Pod   {#pre-scheduled-pods}

 当你（或别的 API 客户端）创建设置了 `spec.nodeName` 的 Pod 时，调度器将被绕过。
 如果 Pod 所需的某个 ResourceClaim 尚不存在、未被分配或未为该 Pod 保留，那么 kubelet
@ -335,8 +335,8 @@ kube-scheduler, kube-controller-manager and kubelet also need the feature gate.
 -->
 动态资源分配是一个 **alpha 特性**，只有在启用 `DynamicResourceAllocation`
 [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
-和 `resource.k8s.io/v1alpha1` {{< glossary_tooltip text="API 组"
-term_id="api-group" >}} 时才启用。
+和 `resource.k8s.io/v1alpha1`
+{{< glossary_tooltip text="API 组" term_id="api-group" >}} 时才启用。
 有关详细信息，参阅 `--feature-gates` 和 `--runtime-config`
 [kube-apiserver 参数](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)。
 kube-scheduler、kube-controller-manager 和 kubelet 也需要设置该特性门控。
@ -356,6 +356,7 @@ If your cluster supports dynamic resource allocation, the response is either a
 list of ResourceClass objects or:
 -->
 如果你的集群支持动态资源分配，则响应是 ResourceClass 对象列表或：
+
 ```
 No resources found
 ```
@ -364,6 +365,7 @@ No resources found
 If not supported, this error is printed instead:
 -->
 如果不支持，则会输出如下错误：
+
 ```
 error: the server doesn't have a resource type "resourceclasses"
 ```
@ -391,4 +393,4 @@ be installed. Please refer to the driver's documentation for details.
 [Dynamic Resource Allocation KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md).
 -->
 - 了解更多该设计的信息，
-  参阅[动态资源分配 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)。
+  参阅[动态资源分配 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)。
--- a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md
+++ b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md
@ -19,7 +19,7 @@ kubelet can proactively fail one or more pods on the node to reclaim resources
 and prevent starvation.

 During a node-pressure eviction, the kubelet sets the [phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) for the
-selected pods to `Failed`. This terminates the Pods.
+selected pods to `Failed`, and terminates the Pod.

 Node-pressure eviction is not the same as
 [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/).
@ -30,7 +30,7 @@ Node-pressure eviction is not the same as
 kubelet 可以主动地使节点上一个或者多个 Pod 失效，以回收资源防止饥饿。

 在节点压力驱逐期间，kubelet 将所选 Pod 的[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)
-设置为 `Failed`。这将终止 Pod。
+设置为 `Failed` 并终止 Pod。

 节点压力驱逐不同于 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。

@ -55,7 +55,7 @@ The kubelet attempts to [reclaim node-level resources](#reclaim-node-resources)
 before it terminates end-user pods. For example, it removes unused container
 images when disk resources are starved.
 -->
-## 自我修复行为
+## 自我修复行为   {#self-healing-behavior}

 kubelet 在终止最终用户 Pod 之前会尝试[回收节点级资源](#reclaim-node-resources)。
 例如，它会在磁盘资源不足时删除未使用的容器镜像。
@ -75,7 +75,7 @@ pods in place of the evicted pods.
 <!--
 ### Self healing for static pods
 -->
-### 静态 Pod 的自我修复
+### 静态 Pod 的自我修复   {#self-healing-for-static-pods}

 <!--
 If you are running a [static pod](/docs/concepts/workloads/pods/#static-pods)
@ -237,10 +237,10 @@ Eviction thresholds have the form `[eviction-signal][operator][quantity]`, where

 驱逐条件的形式为 `[eviction-signal][operator][quantity]`，其中：

-* `eviction-signal` 是要使用的[驱逐信号](#eviction-signals)。
-* `operator` 是你想要的[关系运算符](https://en.wikipedia.org/wiki/Relational_operator#Standard_relational_operators)，
+- `eviction-signal` 是要使用的[驱逐信号](#eviction-signals)。
+- `operator` 是你想要的[关系运算符](https://en.wikipedia.org/wiki/Relational_operator#Standard_relational_operators)，
  比如 `<`（小于）。
-* `quantity` 是驱逐条件数量，例如 `1Gi`。
+- `quantity` 是驱逐条件数量，例如 `1Gi`。
  `quantity` 的值必须与 Kubernetes 使用的数量表示相匹配。
  你可以使用文字值或百分比（`%`）。

@ -295,11 +295,11 @@ You can use the following flags to configure soft eviction thresholds:
 -->
 你可以使用以下标志来配置软驱逐条件：

-* `eviction-soft`：一组驱逐条件，如 `memory.available<1.5Gi`，
+- `eviction-soft`：一组驱逐条件，如 `memory.available<1.5Gi`，
  如果驱逐条件持续时长超过指定的宽限期，可以触发 Pod 驱逐。
-* `eviction-soft-grace-period`：一组驱逐宽限期，
+- `eviction-soft-grace-period`：一组驱逐宽限期，
  如 `memory.available=1m30s`，定义软驱逐条件在触发 Pod 驱逐之前必须保持多长时间。
-* `eviction-max-pod-grace-period`：在满足软驱逐条件而终止 Pod 时使用的最大允许宽限期（以秒为单位）。
+- `eviction-max-pod-grace-period`：在满足软驱逐条件而终止 Pod 时使用的最大允许宽限期（以秒为单位）。

 <!--
 #### Hard eviction thresholds {#hard-eviction-thresholds}
@ -329,10 +329,10 @@ The kubelet has the following default hard eviction thresholds:
 -->
 kubelet 具有以下默认硬驱逐条件：

-* `memory.available<100Mi`
-* `nodefs.available<10%`
-* `imagefs.available<15%`
-* `nodefs.inodesFree<5%`（Linux 节点）
+- `memory.available<100Mi`
+- `nodefs.available<10%`
+- `imagefs.available<15%`
+- `nodefs.inodesFree<5%`（Linux 节点）

 <!--
 These default values of hard eviction thresholds will only be set if none
@ -852,11 +852,11 @@ to estimate or measure an optimal memory limit value for that container.
 - Learn about [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/)
 - Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
 - Learn about [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
- Learn about [Q**uality of Servic**e](/docs/tasks/configure-pod-container/quality-service-pod/) (QoS)
+- Learn about [Quality of Service](/docs/tasks/configure-pod-container/quality-service-pod/) (QoS)
 - Check out the [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
 -->
-* 了解 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)
-* 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
-* 了解 [PodDisruptionBudgets](/zh-cn/docs/tasks/run-application/configure-pdb/)
-* 了解[服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)（QoS）
-* 查看[驱逐 API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
+- 了解 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)
+- 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+- 了解 [PodDisruptionBudgets](/zh-cn/docs/tasks/run-application/configure-pdb/)
+- 了解[服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)（QoS）
+- 查看[驱逐 API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core)
--- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md
+++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md
@ -11,7 +11,7 @@ weight: 40

 <!-- overview -->

-{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.27" state="beta" >}}

 <!--
 Pods were considered ready for scheduling once created. Kubernetes scheduler