From 6e1ac284daa688475304fc4cbb867b69167a2d61 Mon Sep 17 00:00:00 2001 From: Rui Chen Date: Sun, 30 May 2021 12:06:29 -0400 Subject: [PATCH] zh: sync concepts/scheduling-eviction files zh: sync docs/concepts/scheduling-eviction/_index zh: sync docs/concepts/scheduling-eviction/assign-pod-node zh: sync docs/concepts/scheduling-eviction/pod-overhead zh: sync docs/concepts/scheduling-eviction/resource-bin-packing zh: sync docs/concepts/scheduling-eviction/scheduler-perf-tuning zh: sync docs/concepts/scheduling-eviction/scheduling-framework zh: sync docs/concepts/scheduling-eviction/taint-and-toleration zh: remove glossary_definition for concepts/scheduling-eviction Signed-off-by: Rui Chen --- .../concepts/scheduling-eviction/_index.md | 52 ++++++++++++++- .../scheduling-eviction/assign-pod-node.md | 23 ++++--- .../scheduling-eviction/pod-overhead.md | 63 ++++++++++++------- .../resource-bin-packing.md | 13 ++-- .../scheduler-perf-tuning.md | 58 ++++++++--------- .../scheduling-framework.md | 45 +++++++------ .../taint-and-toleration.md | 8 +-- 7 files changed, 168 insertions(+), 94 deletions(-) diff --git a/content/zh/docs/concepts/scheduling-eviction/_index.md b/content/zh/docs/concepts/scheduling-eviction/_index.md index f7388ba108..01265f3a05 100644 --- a/content/zh/docs/concepts/scheduling-eviction/_index.md +++ b/content/zh/docs/concepts/scheduling-eviction/_index.md @@ -1,5 +1,53 @@ --- -title: 调度和驱逐 (Scheduling and Eviction) +title: 调度，抢占和驱逐 weight: 90 -description: 在Kubernetes中，调度 (Scheduling) 指的是确保 Pods 匹配到合适的节点，以便 kubelet 能够运行它们。驱逐 (Eviction) 是在资源匮乏的节点上，主动让一个或多个 Pods 失效的过程。 +content_type: concept +description: > + 在Kubernetes中，调度 (scheduling) 指的是确保 Pods 匹配到合适的节点， + 以便 kubelet 能够运行它们。抢占 (Preemption) 指的是终止低优先级的 Pods 以便高优先级的 Pods 可以 + 调度运行的过程。驱逐 (Eviction) 是在资源匮乏的节点上，主动让一个或多个 Pods 失效的过程。 --- + + + + + + + +## 调度 + +* [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) +* [将 Pods 指派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) +* [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) +* [污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [调度框架](/zh/docs/concepts/scheduling-eviction/scheduling-framework) +* [调度器的性能调试](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [扩展资源的资源装箱](/zh/docs/concepts/scheduling-eviction/resource-bin-packing/) + + + +## Pod 干扰 + +* [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md index c237281776..7f93a31186 100644 --- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -75,9 +75,9 @@ Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the o 执行 `kubectl get nodes` 命令获取集群的节点名称。 选择一个你要增加标签的节点，然后执行 -`kubectl label nodes =` +`kubectl label nodes =` 命令将标签添加到你所选择的节点上。 -例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' +例如，如果你的节点名称为 'kubernetes-foo-node-1.c.a-robinson.internal' 并且想要的标签是 'disktype=ssd'，则可以执行 `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 命令。 @@ -136,8 +136,18 @@ with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/ --> ## 插曲：内置的节点标签 {#built-in-node-labels} -除了你[添加](#attach-labels-to-node)的标签外，节点还预先填充了一组标准标签。 -参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。 +除了你[添加](#step-one-attach-label-to-the-node)的标签外，节点还预制了一组标准标签。 +参见这些[常用的标签，注解以及污点](/zh/docs/reference/labels-annotations-taints/)： + +* [`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) {{< note >}} 1. 检查是否在使用 Kubernetes v1.11+，以便 NodeRestriction 功能可用。 -2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_ +2. 确保你在使用[节点授权](/zh/docs/reference/access-authn-authz/node/)并且已经_启用_ [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 3. 将 `node-restriction.kubernetes.io/` 前缀下的标签添加到 Node 对象， 然后在节点选择器中使用这些标签。 @@ -574,7 +584,7 @@ must be satisfied for the pod to be scheduled onto a node. 用户也可以使用 `namespaceSelector` 选择匹配的名字空间，`namespaceSelector` @@ -828,4 +838,3 @@ resource allocation decisions. 一旦 Pod 分配给 节点，kubelet 应用将运行该 pod 并且分配节点本地资源。 [拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) 可以参与到节点级别的资源分配决定中。 - diff --git a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md index 40684ff11c..998a2c3327 100644 --- a/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,9 +1,21 @@ --- title: Pod 开销 content_type: concept -weight: 20 +weight: 30 --- + + {{< feature-state for_k8s_version="v1.18" state="beta" >}} @@ -58,7 +70,7 @@ across your cluster, and a `RuntimeClass` is utilized which defines the `overhea 您需要确保在集群中启用了 `PodOverhead` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) （在 1.18 默认是开启的），以及一个用于定义 `overhead` 字段的 `RuntimeClass`。 - ## 使用示例 @@ -85,7 +97,7 @@ overhead: cpu: "250m" ``` - 在 RuntimeClass 准入控制器之后，可以检验一下已更新的 PodSpec: @@ -138,7 +150,7 @@ After the RuntimeClass admission controller, you can check the updated PodSpec: kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` - 输出： @@ -146,25 +158,25 @@ The output is: map[cpu:250m memory:120Mi] ``` - 如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。 - 当 kube-scheduler 决定在哪一个节点调度运行新的 Pod 时，调度器会兼顾该 Pod 的 `overhead` 以及该 Pod 的容器请求总量。在这个示例中，调度器将资源请求和开销相加，然后寻找具备 2.25 CPU 和 320 MiB 内存可用的节点。 - 一旦 Pod 调度到了某个节点， 该节点上的 kubelet 将为该 Pod 新建一个 {{< glossary_tooltip text="cgroup" term_id="cgroup" >}}. 底层容器运行时将在这个 pod 中创建容器。 - 对于 CPU, 如果 Pod 的 QoS 是 Guaranteed 或者 Burstable, kubelet 会基于容器请求总量与 PodSpec 中定义的 `overhead` 之和设置 `cpu.shares`. - 请看这个例子，验证工作负载的容器请求： @@ -187,7 +199,7 @@ Looking at our example, verify the container requests for the workload: kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` - 容器请求总计 2000m CPU 和 200MiB 内存： @@ -195,7 +207,7 @@ The total container requests are 2000m CPU and 200MiB of memory: map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` - 对照从节点观察到的情况来检查一下： @@ -203,7 +215,7 @@ Check this against what is observed by the node: kubectl describe node | grep test-pod -B2 ``` - 该输出显示请求了 2250m CPU 以及 320MiB 内存，包含了 PodOverhead 在内： @@ -226,8 +238,9 @@ cgroups directly on the node. First, on the particular node, determine the Pod identifier: --> -在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中，将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 [`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md). -这是一个展示 PodOverhead 行为的进阶示例，用户并不需要直接在该节点上检查 cgroups. +在工作负载所运行的节点上检查 Pod 的内存 cgroups. 在接下来的例子中， +将在该节点上使用具备 CRI 兼容的容器运行时命令行工具 +[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。 首先在特定的节点上确定该 Pod 的标识符： @@ -240,7 +253,7 @@ First, on the particular node, determine the Pod identifier: POD_ID="$(sudo crictl pods --name test-pod -q)" ``` - 可以依此判断该 Pod 的 cgroup 路径： @@ -254,7 +267,7 @@ From this, you can determine the cgroup path for the Pod: sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` - 执行结果的 cgroup 路径中包含了该 Pod 的 `pause` 容器。Pod 级别的 cgroup 即上面的一个目录。 @@ -262,7 +275,7 @@ The resulting cgroup path includes the Pod's `pause` container. The Pod level cg "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` - 在这个例子中，该 pod 的 cgroup 路径是 `kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`。验证内存的 Pod 级别 cgroup 设置： @@ -278,7 +291,7 @@ In this specific case, the pod cgroup path is `kubepods/podd7f4b509-cf94-4951-94 cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` - 和预期的一样是 320 MiB @@ -286,7 +299,7 @@ This is 320 MiB, as expected: 335544320 ``` - ### 可观察性 @@ -298,8 +311,11 @@ running with a defined Overhead. This functionality is not available in the 1.9 kube-state-metrics, but is expected in a following release. Users will need to build kube-state-metrics from source in the meantime. --> -在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 `kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定开销运行的工作负载的稳定性。 -该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。在此之前，用户需要从源代码构建 kube-state-metrics. +在 [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) 中可以通过 +`kube_pod_overhead` 指标来协助确定何时使用 PodOverhead 以及协助观察以一个既定 +开销运行的工作负载的稳定性。 +该特性在 kube-state-metrics 的 1.9 发行版本中不可用，不过预计将在后续版本中发布。 +在此之前，用户需要从源代码构建 kube-state-metrics。 ## {{% heading "whatsnext" %}} @@ -310,4 +326,3 @@ from source in the meantime. * [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) * [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) - diff --git a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md index a08539b1a0..b8c097e5df 100644 --- a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -1,16 +1,18 @@ --- title: 扩展资源的资源装箱 content_type: concept -weight: 30 +weight: 80 --- @@ -18,7 +20,7 @@ weight: 30 {{< feature-state for_k8s_version="1.16" state="alpha" >}} 使用 `RequestedToCapacityRatioResourceAllocation` 优先级函数，可以将 kube-scheduler @@ -48,7 +50,7 @@ Kubernetes 1.16 在优先级函数中添加了一个新参数，该参数允许 （least requested）或 最多请求（most requested）计算。 `resources` 包含由 `name` 和 `weight` 组成，`name` 指定评分时要考虑的资源， -`weight` 指定每种资源的权重。 +`weight` 指定每种资源的权重。 它可以用来添加扩展资源，如下所示： @@ -249,4 +251,3 @@ CPU = resourceScoringFunction((2+6),8) NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) = 7 ``` - diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 42894aca1e..8a43385d13 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -1,14 +1,16 @@ --- title: 调度器性能调优 content_type: concept -weight: 80 +weight: 100 --- @@ -45,7 +47,7 @@ large Kubernetes clusters. - ### 设置阈值 - -要修改这个值，编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/)， -之后重启调度器。 -在很多场合下，配置文件位于 `/etc/kubernetes/config/kube-scheduler.yaml`。 +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`。 - 修改完成后，你可以执行 @@ -96,17 +98,17 @@ After you have made this change, you can run kubectl get pods -n kube-system | grep kube-scheduler ``` - 来检查该 kube-scheduler 组件是否健康。 - ## 节点打分阈值 {#percentage-of-nodes-to-score} - -你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 +你可以使用整个集群节点总数的百分比作为阈值来指定需要多少节点就足够。 kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量， kube-scheduler 将停止继续查找可调度节点并继续进行 [打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 - [调度器如何遍历节点](#how-the-scheduler-iterates-over-nodes) 详细介绍了这个过程。 - ### 默认阈值 - 这意味着，调度器至少会对集群中 5% 的节点进行打分，除非用户将该参数设置的低于 5。 - 如果你想让调度器对集群内所有节点进行打分，则将 `percentageOfNodesToScore` 设置为 100。 - ## 示例 @@ -189,15 +191,15 @@ percentageOfNodesToScore: 50 `percentageOfNodesToScore` 的值必须在 1 到 100 之间，而且其默认值是通过集群的规模计算得来的。 另外，还有一个 50 个 Node 的最小值是硬编码在程序中。 在评估完所有 Node 后，将会返回到 Node 1，从头开始。 - ## {{% heading "whatsnext" %}} -* 查阅 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) + +* 参见 [kube-scheduler 配置参考 (v1beta1)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta1/) diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md index 5927a4c8f3..1107c19565 100644 --- a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -1,15 +1,17 @@ --- title: 调度框架 content_type: concept -weight: 70 +weight: 90 --- @@ -17,17 +19,15 @@ weight: 70 {{< feature-state for_k8s_version="1.15" state="alpha" >}} -调度框架是 Kubernetes 调度器的一种可插入架构。 -调度框架向现有的调度器增加了一组新的“插件（Plugin）” API。 -插件被编译到调度器程序中。 + +调度框架是面向 Kubernetes 调度器的一种插件架构， +它为现有的调度器添加了一组新的“插件” API。插件会被编译到调度器之中。 这些 API 允许大多数调度功能以插件的形式实现，同时使调度“核心”保持简单且可维护。 请参考[调度框架的设计提案](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/624-scheduling-framework/README.md) 获取框架设计的更多技术信息。 @@ -98,7 +98,7 @@ stateful tasks. --> 一个插件可以在多个扩展点处注册，以执行更复杂或有状态的任务。 - {{< figure src="/images/docs/scheduling-framework-extensions.png" title="调度框架扩展点" >}} @@ -163,12 +163,12 @@ tries to make the pod schedulable by preempting other Pods. 则其余的插件不会调用。典型的后筛选实现是抢占，试图通过抢占其他 Pod 的资源使该 Pod 可以调度。 - ### 前置评分 {#pre-score} - ### 评分 {#scoring} @@ -325,17 +325,17 @@ _Permit_ 插件在每个 Pod 调度周期的最后调用，用于防止或延迟 将返回调度队列，从而触发 [Unreserve](#unreserve) 插件。 - {{< note >}} -尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 -（参阅 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle)）。 -我们希望只有被允许的插件可以批准处于“等待中”状态的预留 Pod 的绑定。 -一旦 Pod 被批准了，它将进入到[预绑定](#pre-bind) 阶段。 +尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 +(查看 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle))。 +我们期望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。 +一旦 Pod 被批准了，它将发送到[预绑定](#pre-bind) 阶段。 {{< /note >}} # 插件配置 - @@ -498,7 +498,7 @@ DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍 * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` - * `node.kubernetes.io/out-of-disk` (*只适合关键 Pod*) + * `node.kubernetes.io/pid-pressure` (1.14 或更高版本) * `node.kubernetes.io/unschedulable` (1.10 或更高版本) * `node.kubernetes.io/network-unavailable` (*只适合主机网络配置*)