From 2d41f04907e4354e5980533a3794b20c3fdf0797 Mon Sep 17 00:00:00 2001 From: windsonsea Date: Tue, 17 Oct 2023 16:40:30 +0800 Subject: [PATCH] [zh] Sync assign-pod-node.md --- .../scheduling-eviction/assign-pod-node.md | 71 +++++++++++-------- .../dynamic-resource-allocation.md | 18 ++--- .../node-pressure-eviction.md | 40 +++++------ .../pod-scheduling-readiness.md | 2 +- 4 files changed, 73 insertions(+), 58 deletions(-) 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 f1a354cb0bc2c..aaae90cd6c604 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 @@ -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`。 -亲和性规则表示，仅当节点和至少一个已运行且有 `security=S1` 的标签的 -Pod 处于同一区域时，才可以将该 Pod 调度到节点上。 -更确切的说，调度器必须将 Pod 调度到具有 `topology.kubernetes.io/zone=V` -标签的节点上，并且集群中至少有一个位于该可用区的节点上运行着带有 -`security=S1` 标签的 Pod。 - - -反亲和性规则表示，如果节点处于 Pod 所在的同一可用区且至少一个 Pod 具有 -`security=S2` 标签，则该 Pod 不应被调度到该节点上。 -更确切地说， 如果同一可用区中存在其他运行着带有 `security=S2` 标签的 Pod 节点， -并且节点具有标签 `topology.kubernetes.io/zone=R`，Pod 不能被调度到该节点上。 +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. +--> +亲和性规则规定，只有节点属于特定的 +[区域](/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 调度给该区域中的任何节点。 + + +反亲和性规则规定，如果节点属于特定的 +[区域](/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。 -`nodeName` 旨在供自定义调度程序或需要绕过任何已配置调度程序的高级场景使用。 -如果已分配的 Node 负载过重，绕过调度程序可能会导致 Pod 失败。 +`nodeName` 旨在供自定义调度器或需要绕过任何已配置调度器的高级场景使用。 +如果已分配的 Node 负载过重，绕过调度器可能会导致 Pod 失败。 你可以使用[节点亲和性](#node-affinity)或 [`nodeselector` 字段](#nodeselector)将 -Pod 分配给特定 Node，而无需绕过调度程序。 +Pod 分配给特定 Node，而无需绕过调度器。 {{}} -## API {#api} +## API + -ResourceClass 和 ResourceClaim 的参数存储在单独的对象中， -通常使用安装资源驱动程序时创建的 {{< glossary_tooltip -term_id="CustomResourceDefinition" text="CRD" >}} 所定义的类型。 +ResourceClass 和 ResourceClaim 的参数存储在单独的对象中，通常使用安装资源驱动程序时创建的 +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}} 所定义的类型。 -## 预调度的 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)。 \ No newline at end of file + 参阅[动态资源分配 KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/3063-dynamic-resource-allocation/README.md)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md index 086e35092af80..0a6e99b939019 100644 --- 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. -### 静态 Pod 的自我修复 +### 静态 Pod 的自我修复 {#self-healing-for-static-pods} 你可以使用以下标志来配置软驱逐条件： -* `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 时使用的最大允许宽限期（以秒为单位）。 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 节点） -* 了解 [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/{{}}/#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/{{}}/#create-eviction-pod-v1-core) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md index 7bd495a507951..1df056b6c7827 100644 --- 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 -{{< feature-state for_k8s_version="v1.26" state="alpha" >}} +{{< feature-state for_k8s_version="v1.27" state="beta" >}}