diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md index 00247efae0260..57bddeaa99162 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -153,7 +153,7 @@ information. ## Affinity and anti-affinity `nodeSelector` is the simplest way to constrain Pods to nodes with specific -labels. Affinity and anti-affinity expands the types of constraints you can +labels. Affinity and anti-affinity expand the types of constraints you can define. Some of the benefits of affinity and anti-affinity include: --> ## 亲和性与反亲和性 {#affinity-and-anti-affinity} @@ -233,6 +233,7 @@ your Pod spec. For example, consider the following Pod spec: --> 你可以使用 Pod 规约中的 `.spec.affinity.nodeAffinity` 字段来设置节点亲和性。 + 例如,考虑下面的 Pod 规约: {{% code_sample file="pods/pod-with-node-affinity.yaml" %}} @@ -432,22 +433,26 @@ DaemonSet 控制器创建 Pod 时,默认的 Kubernetes 调度器负责放置 P ### Inter-pod affinity and anti-affinity Inter-pod affinity and anti-affinity allow you to constrain which nodes your -Pods can be scheduled on based on the labels of **Pods** already running on that +Pods can be scheduled on based on the labels of Pods already running on that node, instead of the node labels. --> ### Pod 间亲和性与反亲和性 {#inter-pod-affinity-and-anti-affinity} -Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 **Pod** 的标签来约束 +Pod 间亲和性与反亲和性使你可以基于已经在节点上运行的 Pod 的标签来约束 Pod 可以调度到的节点,而不是基于节点上的标签。 -Pod 间亲和性与反亲和性的规则格式为“如果 X 上已经运行了一个或多个满足规则 Y 的 Pod, +#### Pod 间亲和性与反亲和性的类型 + +Pod 间亲和性与反亲和性的格式为“如果 X 上已经运行了一个或多个满足规则 Y 的 Pod, 则这个 Pod 应该(或者在反亲和性的情况下不应该)运行在 X 上”。 这里的 X 可以是节点、机架、云提供商可用区或地理区域或类似的拓扑域, Y 则是 Kubernetes 尝试满足的规则。 @@ -496,13 +501,9 @@ Pod 反亲和性需要节点上存在一致性的标签。换言之, {{< /note >}} -#### Pod 间亲和性与反亲和性的类型 - 与[节点亲和性](#node-affinity)类似,Pod 的亲和性与反亲和性也有两种类型: - `requiredDuringSchedulingIgnoredDuringExecution` @@ -530,13 +531,54 @@ spec. 对于 Pod 间反亲和性,可以使用 Pod 规约中的 `.affinity.podAntiAffinity` 字段。 +#### 调度行为 + +在调度新 Pod 时,Kubernetes 调度器会根据当前集群状态评估 Pod 的亲和性/反亲和性规则: + +1. 硬约束(节点过滤): + - `podAffinity.requiredDuringSchedulingIgnoredDuringExecution` 和 + `podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution`: + - 调度器基于现有 Pod,确保新 Pod 被分配到满足这些必需的亲和性和反亲和性规则的节点上。 + + +2. 软约束(评分): + - `podAffinity.preferredDuringSchedulingIgnoredDuringExecution` 和 + `podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution`: + - 调度器根据节点满足这些优选的亲和性和反亲和性规则的程度来评分,以优化 Pod 的放置。 + + +3. 忽略的字段: + - 现有 Pod 的 `podAffinity.preferredDuringSchedulingIgnoredDuringExecution`: + - 在为新 Pod 做调度决策时,不会考虑这些优选的亲和性规则。 + - 现有 Pod 的 `podAntiAffinity.preferredDuringSchedulingIgnoredDuringExecution`: + - 同样,在调度时会忽略现有 Pod 的优选反亲和性规则。 + + #### 调度一组具有 Pod 间亲和性的 Pod {#scheduling-a-group-of-pods-with-inter-pod-affinity-to-themselves} @@ -548,7 +590,7 @@ specified. 这确保即使所有的 Pod 都配置了 Pod 间亲和性,也不会出现调度死锁的情况。 @@ -613,8 +655,7 @@ refer to the [design proposal](https://git.k8s.io/design-proposals-archive/sched You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the `operator` field for Pod affinity and anti-affinity. --> -你可以针对 Pod 间亲和性与反亲和性为其 `operator` 字段使用 `In`、`NotIn`、`Exists`、 -`DoesNotExist` 等值。 +你可以针对 Pod 间亲和性与反亲和性为其 `operator` 字段使用 `In`、`NotIn`、`Exists`、`DoesNotExist` 等值。 #### 名字空间选择算符 {#namespace-selector} @@ -695,17 +736,18 @@ When you want to disable it, you have to disable it explicitly via the Kubernetes 在 Pod 亲和性或反亲和性中包含一个可选的 `matchLabelKeys` 字段。 此字段指定了应与传入 Pod 的标签匹配的标签键,以满足 Pod 的(反)亲和性。 -这些键用于从 Pod 的标签中查找值;这些键值标签与使用 `labelSelector` 字段定义的匹配限制组合(使用 `AND` 操作)。 +这些键用于从 Pod 的标签中查找值;这些键值标签与使用 `labelSelector` +字段定义的匹配限制组合(使用 `AND` 操作)。 这种组合的过滤机制选择将用于 Pod(反)亲和性计算的现有 Pod 集合。 {{< caution >}} @@ -803,11 +845,11 @@ When you want to disable it, you have to disable it explicitly via the Kubernetes 为 Pod 亲和性或反亲和性提供了一个可选的 `mismatchLabelKeys` 字段。 -此字段指定了在满足 Pod(反)亲和性时,**不**应与传入 Pod 的标签匹配的键。 +此字段指定了在满足 Pod(反)亲和性时,不应与传入 Pod 的标签匹配的键。 {{< caution >}} `Gt` 和 `Lt` 操作符不能与非整数值一起使用。