Skip to content

Commit

Permalink
[zh] Sync taint-and-toleration.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@windsonsea
windsonsea committed Oct 12, 2023
1 parent 14f30b5 commit 39d9d0a
Show file tree
Hide file tree
Showing 2 changed files with 84 additions and 37 deletions.
85 changes: 54 additions & 31 deletions content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md
View file
Expand Up @@ -142,13 +142,51 @@ An empty `effect` matches all effects with key `key1`.

<!--
The above example used `effect` of `NoSchedule`. Alternatively, you can use `effect` of `PreferNoSchedule`.
This is a "preference" or "soft" version of `NoSchedule` -- the system will *try* to avoid placing a
pod that does not tolerate the taint on the node, but it is not required. The third kind of `effect` is
`NoExecute`, described later.
-->
上述例子中 `effect` 使用的值为 `NoSchedule`，你也可以使用另外一个值 `PreferNoSchedule`。
这是“优化”或“软”版本的 `NoSchedule` —— 系统会 **尽量** 避免将 Pod 调度到存在其不能容忍污点的节点上，
但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。

<!--
The allowed values for the `effect` field are:
-->
`effect` 字段的允许值包括：

<!--
`NoExecute`
: This affects pods that are already running on the node as follows:
* Pods that do not tolerate the taint are evicted immediately
* Pods that tolerate the taint without specifying `tolerationSeconds` in
their toleration specification remain bound forever
* Pods that tolerate the taint with a specified `tolerationSeconds` remain
bound for the specified amount of time. After that time elapses, the node
lifecycle controller evicts the Pods from the node.
-->
`NoExecute`
: 这会影响已在节点上运行的 Pod，具体影响如下：
* 如果 Pod 不能容忍这类污点，会马上被驱逐。
* 如果 Pod 能够容忍这类污点，但是在容忍度定义中没有指定 `tolerationSeconds`，
则 Pod 还会一直在这个节点上运行。
* 如果 Pod 能够容忍这类污点，而且指定了 `tolerationSeconds`，
则 Pod 还能在这个节点上继续运行这个指定的时间长度。
这段时间过去后，节点生命周期控制器从节点驱除这些 Pod。

<!--
`NoSchedule`
: No new Pods will be scheduled on the tainted node unless they have a matching
toleration. Pods currently running on the node are **not** evicted.
-->
`NoSchedule`
: 除非具有匹配的容忍度规约，否则新的 Pod 不会被调度到带有污点的节点上。
当前正在节点上运行的 Pod **不会**被驱逐。

<!--
`PreferNoSchedule`
: `PreferNoSchedule` is a "preference" or "soft" version of `NoSchedule`.
The control plane will *try* to avoid placing a Pod that does not tolerate
the taint on the node, but it is not guaranteed.
-->
`PreferNoSchedule`
: `PreferNoSchedule` 是“偏好”或“软性”的 `NoSchedule`。
控制平面将**尝试**避免将不能容忍污点的 Pod 调度到的节点上，但不能保证完全避免。

<!--
You can put multiple taints on the same node and multiple tolerations on the same pod.
Expand Down Expand Up @@ -225,7 +263,7 @@ an optional `tolerationSeconds` field that dictates how long the pod will stay b
to the node after the taint is added. For example,
-->
通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的污点，
则任何不能忍受这个污点的 Pod 都会马上被驱逐，任何可以忍受这个污点的 Pod 都不会被驱逐。
则任何不能容忍这个污点的 Pod 都会马上被驱逐，任何可以容忍这个污点的 Pod 都不会被驱逐。
但是，如果 Pod 存在一个 effect 值为 `NoExecute` 的容忍度指定了可选属性
`tolerationSeconds` 的值，则表示在给节点添加了上述污点之后，
Pod 还能继续在节点上运行的时间。例如，
Expand Down Expand Up @@ -327,7 +365,7 @@ manually add tolerations to your pods.
* **Taint based Evictions**: A per-pod-configurable eviction behavior
when there are node problems, which is described in the next section.
-->
* **基于污点的驱逐**: 这是在每个 Pod 中配置的在节点出现问题时的驱逐行为，
* **基于污点的驱逐**：这是在每个 Pod 中配置的在节点出现问题时的驱逐行为，
接下来的章节会描述这个特性。

<!--
Expand All @@ -337,24 +375,6 @@ when there are node problems, which is described in the next section.

{{< feature-state for_k8s_version="v1.18" state="stable" >}}

<!--
The `NoExecute` taint effect, mentioned above, affects pods that are already
running on the node as follows
* pods that do not tolerate the taint are evicted immediately
* pods that tolerate the taint without specifying `tolerationSeconds` in
their toleration specification remain bound forever
* pods that tolerate the taint with a specified `tolerationSeconds` remain
bound for the specified amount of time
-->
前文提到过污点的效果值 `NoExecute` 会影响已经在节点上运行的如下 Pod：

* 如果 Pod 不能忍受这类污点，Pod 会马上被驱逐。
* 如果 Pod 能够忍受这类污点，但是在容忍度定义中没有指定 `tolerationSeconds`，
则 Pod 还会一直在这个节点上运行。
* 如果 Pod 能够忍受这类污点，而且指定了 `tolerationSeconds`，
则 Pod 还能在这个节点上继续运行这个指定的时间长度。

<!--
The node controller automatically taints a Node when certain conditions
are true. The following taints are built in:
Expand All @@ -380,19 +400,22 @@ are true. The following taints are built in:
的值为 "`Unknown`"。
* `node.kubernetes.io/memory-pressure`：节点存在内存压力。
* `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。
* `node.kubernetes.io/pid-pressure`: 节点的 PID 压力。
* `node.kubernetes.io/pid-pressure`：节点的 PID 压力。
* `node.kubernetes.io/network-unavailable`：节点网络不可用。
* `node.kubernetes.io/unschedulable`: 节点不可调度。
* `node.kubernetes.io/unschedulable`：节点不可调度。
* `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个“外部”云平台驱动，
它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager
的一个控制器初始化这个节点后，kubelet 将删除这个污点。

<!--
In case a node is to be drained, the node controller or the kubelet adds relevant taints
with `NoExecute` effect. If the fault condition returns to normal the kubelet or node
with `NoExecute` effect. This effect is added by default for the
`node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` taints.
If the fault condition returns to normal, the kubelet or node
controller can remove the relevant taint(s).
-->
在节点被排空时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效果的相关污点。
此效果被默认添加到 `node.kubernetes.io/not-ready` 和 `node.kubernetes.io/unreachable` 污点中。
如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。

<!--
Expand Down Expand Up @@ -532,9 +555,9 @@ DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍

* `node.kubernetes.io/memory-pressure`
* `node.kubernetes.io/disk-pressure`
* `node.kubernetes.io/pid-pressure` (1.14 或更高版本)
* `node.kubernetes.io/unschedulable` (1.10 或更高版本)
* `node.kubernetes.io/network-unavailable` (**只适合主机网络配置**)
* `node.kubernetes.io/pid-pressure`（1.14 或更高版本）
* `node.kubernetes.io/unschedulable`（1.10 或更高版本）
* `node.kubernetes.io/network-unavailable`（**只适合主机网络配置**）

<!--
Adding these tolerations ensures backward compatibility. You can also add
Expand Down
36 changes: 30 additions & 6 deletions content/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints.md
View file
Expand Up @@ -3,7 +3,6 @@ title: Pod 拓扑分布约束
content_type: concept
weight: 40
---

<!--
title: Pod Topology Spread Constraints
content_type: concept
Expand Down Expand Up @@ -91,6 +90,27 @@ the following:

Pod API 包括一个 `spec.topologySpreadConstraints` 字段。这个字段的用法如下所示：

<!--
```yaml
---
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
# Configure a topology spread constraint
topologySpreadConstraints:
- maxSkew: <integer>
minDomains: <integer> # optional; beta since v1.25
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
matchLabelKeys: <list> # optional; beta since v1.27
nodeAffinityPolicy: [Honor|Ignore] # optional; beta since v1.26
nodeTaintsPolicy: [Honor|Ignore] # optional; beta since v1.26
### other Pod fields go here
```
-->
```yaml
---
apiVersion: v1
Expand Down Expand Up @@ -164,12 +184,16 @@ your cluster. Those fields are:

{{< note >}}
<!--
The `minDomains` field is a beta field and disabled by default in 1.25. You can enable it by enabling the
`MinDomainsInPodTopologySpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
The `MinDomainsInPodTopologySpread` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
enables `minDomains` for pod topology spread. Starting from v1.28,
the `MinDomainsInPodTopologySpread` gate
is enabled by default. In older Kubernetes clusters it might be explicitly
disabled or the field might not be available.
-->
`minDomains` 字段是一个 Beta 字段，在 1.25 中默认被禁用。
你可以通过启用 `MinDomainsInPodTopologySpread`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来启用该字段。
`MinDomainsInPodTopologySpread`
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)为
Pod 拓扑分布启用 `minDomains`。自 v1.28 起，`MinDomainsInPodTopologySpread` 特性门控默认被启用。
在早期的 Kubernetes 集群中，此特性门控可能被显式禁用或此字段可能不可用。
{{< /note >}}

<!--
Expand Down

0 comments on commit 39d9d0a

Please sign in to comment.