From 27354f8dceadb1bfb180b1d98e1eb2d3526a216b Mon Sep 17 00:00:00 2001 From: GeorgeSen Date: Mon, 21 Oct 2019 15:12:14 +0800 Subject: [PATCH 1/6] Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen Add Chinese translation for kube-scheduler Signed-off-by: GeorgeSen --- .../concepts/scheduling/kube-scheduler.md | 319 ++++++++++++++++++ 1 file changed, 319 insertions(+) create mode 100644 content/zh/docs/concepts/scheduling/kube-scheduler.md diff --git a/content/zh/docs/concepts/scheduling/kube-scheduler.md b/content/zh/docs/concepts/scheduling/kube-scheduler.md new file mode 100644 index 0000000000000..532d3a73141fe --- /dev/null +++ b/content/zh/docs/concepts/scheduling/kube-scheduler.md @@ -0,0 +1,319 @@ +--- +title: Kubernetes 调度器 +content_template: templates/concept +weight: 60 +--- + + +{{% capture overview %}} + + +在 Kubernetes 中，_调度_ 是指将 {{< glossary_tooltip text="Pod" term_id="pod" >}} 放置到合适的 +{{< glossary_tooltip text="Node" term_id="node" >}} 上，然后对应 Node 上的 {{< glossary_tooltip term_id="kubelet" >}} 才能够运行这些 pod。 + +{{% /capture %}} + +{{% capture body %}} + +## 调度概览 {#scheduling} + + +调度器通过 kubernetes 的 watch 机制来发现集群中新创建且尚未被调度到 Node 上的 Pod。调度器会将发现的每一个未调度的 Pod 调度到一个合适的 Node 上来运行。调度器会依据下文的调度原则来做出调度选择。 + + +如果你想要理解 Pod 为什么会被调度到特定的 Node 上，或者你想要尝试实现一个自定义的调度器，这篇文章将帮助你了解调度。 + + +## kube-scheduler + + +[kube-scheduler](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许你自己写一个调度组件并替换原有的 kube-scheduler。 + + +对每一个新创建的 Pod 或者是未被调度的 Pod，kube-scheduler 会选择一个最优的 Node 去运行这个 Pod。然而，Pod 内的每一个容器对资源都有不同的需求，而且 Pod 本身也有不同的资源需求。因此，Pod 在被调度到 Node 上之前，根据这些特定的资源调度需求，需要对集群中的 Node 进行一次过滤。 + + +在一个集群中，满足一个 Pod 调度请求的所有 Node 称之为 _可调度节点_。如果没有任何一个 Node 能满足 Pod 的资源请求，那么这个 Pod 将一直停留在未调度状态直到调度器能够找到合适的 Node。 + + +调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做绑定。 + + +在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。 + + +## kube-scheduler 调度流程 {#kube-scheduler-implementation} + + +kube-scheduler 给一个 pod 做调度选择包含两个步骤： + +1. 过滤 + +2. 打分 + + +过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。例如，PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后，得出一个 Node 列表，里面包含了所有可调度节点；通常情况下，这个 Node 列表包含不止一个 Node。如果这个列表是空的，代表这个 Pod 不可调度。 + + +在打分阶段，调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则，调度器会给每一个可调度节点进行打分。 + + +最后，kube-scheduler 会将 Pod 调度到得分最高的 Node 上。如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。 + + +### 默认策略 + + +kube-scheduler 有一系列的默认调度策略。 + + +### 过滤策略 + +- `PodFitsHostPorts`：如果 Pod 中定义了 hostPort 属性，那么需要先检查这个指定端口是否 + 已经被 Node 上其他服务占用了。 + +- `PodFitsHost`：若 pod 对象拥有 hostname 属性，则检查 Node 名称字符串与此属性是否匹配。 + +- `PodFitsResources`：检查 Node 上是否有足够的资源（如，cpu 和内存）来满足 pod 的资源请求。 + +- `PodMatchNodeSelector`：检查 Node 的 {{< glossary_tooltip text="label(s)" term_id="label" >}} 是否能匹配 + Pod 属性上 Node 的 {{< glossary_tooltip text="label(s)" term_id="label" >}} 值。 + +- `NoVolumeZoneConflict`：检测 pod 请求的 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 在 + Node 上是否可用，因为某些存储卷存在区域调度约束。 + +- `NoDiskConflict`：检查 Pod 对象请求的存储卷在 Node 上是否可用，若不存在冲突则通过检查。 + +- `MaxCSIVolumeCount`：检查 Node 上已经挂载的 {{< glossary_tooltip text="CSI" term_id="csi" >}} + 存储卷数量是否超过了指定的最大值。 + +- `CheckNodeMemoryPressure`：如果 Node 上报了内存资源压力过大，而且没有配置异常，那么 Pod 将不会被调度到这个 Node 上。 + +- `CheckNodePIDPressure`：如果 Node 上报了 PID 资源压力过大，而且没有配置异常，那么 Pod 将不会被调度到这个 Node 上。 + +- `CheckNodeDiskPressure`：如果 Node 上报了磁盘资源压力过大（文件系统满了或者将近满了）， + 而且配置异常，那么 Pod 将不会被调度到这个 Node 上。 + +- `CheckNodeCondition`：Node 可以上报其自身的状态，如磁盘、网络不可用，表明 kubelet 未准备好运行 pod。 + 如果 Node 被设置成这种状态，那么 pod 将不会被调度到这个 Node 上。 + +- `PodToleratesNodeTaints`：检查 pod 属性上的 {{< glossary_tooltip text="tolerations" term_id="toleration" >}} 能否容忍 + Node 的 {{< glossary_tooltip text="taints" term_id="taint" >}}。 + +- `CheckVolumeBinding`：检查 Node 上已经绑定的和未绑定的 {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} + 能否满足 Pod 对象的存储卷需求。 + + +### 打分策略 + +- `SelectorSpreadPriority`：尽量将归属于同一个 {{< glossary_tooltip text="Service" term_id="service" >}}、{{< glossary_tooltip term_id="statefulset" >}} 或 {{< glossary_tooltip term_id="replica-set" >}} 的 Pod 资源分散到不同的 Node 上。 + +- `InterPodAffinityPriority`：遍历 Pod 对象的亲和性条目，并将那些能够匹配到给定 Node 的条目的权重相加，结果值越大的 Node 得分越高。 + +- `LeastRequestedPriority`：空闲资源比例越高的 Node 得分越高。换句话说，Node 上的 Pod 越多，并且资源被占用的越多，那么这个 Node 的得分就会越少。 + +- `MostRequestedPriority`：空闲资源比例越低的 Node 得分越高。这个调度策略将会把你所有的工作负载（Pod）调度到尽量少的 Node 上。 + +- `RequestedToCapacityRatioPriority`：为每个 Node 资源使用比例设定得分值用来给资源打分函数使用。 + +- `BalancedResourceAllocation`：Node 上各种资源的占用比例越接近的 Node 越得分越高。 + +- `NodePreferAvoidPodsPriority`：这个策略将根据 Node 的注解信息中是否含有 `scheduler.alpha.kubernetes.io/preferAvoidPods` 来 + 计算其优先级。使用这个策略可以将两个不同 Pod 运行在不同的 Node 上。 + +- `NodeAffinityPriority`：基于 Pod 属性中 PreferredDuringSchedulingIgnoredDuringExecution 来进行 Node 亲和性调度。你可以通过这篇文章 + [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) 来了解到更详细的内容。 + +- `TaintTolerationPriority`：基于 Pod 中对每个 Node 上污点容忍程度进行优先级评估，这个策略能够调整待选 Node 的排名。 + +- `ImageLocalityPriority`：Node 上已经拥有Pod需要的 {{< glossary_tooltip text="container images" term_id="image" >}} 的 Node 会有较高的优先级。 + +- `ServiceSpreadingPriority`：这个调度策略的主要目的是确保将归属于同一个 Service 的 Pod 调度到不同的 Node 上。如果 Node 上 + 没有归属于同一个 Service 的 Pod，这个策略更倾向于将 Pod 调度到这类 Node 上。最终的目的：即使在一个 Node 宕机之后 Service 也具有很强容灾能力。 + +- `CalculateAntiAffinityPriorityMap`：这个策略主要是用来实现[pod反亲和] + (https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)。 + +- `EqualPriorityMap`：将所有的 Node 设置成相同的权重为 1。 + +{{% /capture %}} +{{% capture whatsnext %}} +* Read about [scheduler performance tuning](/docs/concepts/scheduling/scheduler-perf-tuning/) +* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler +* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) +* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) +* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/) +{{% /capture %}} From d2fa44d09315bae6487c718807dee3b1a8c6f382 Mon Sep 17 00:00:00 2001 From: senwang <841470897@qq.com> Date: Wed, 23 Oct 2019 21:13:00 +0800 Subject: [PATCH 2/6] Update kube-scheduler.md --- content/zh/docs/concepts/scheduling/kube-scheduler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/scheduling/kube-scheduler.md b/content/zh/docs/concepts/scheduling/kube-scheduler.md index 532d3a73141fe..587e21e73eeb0 100644 --- a/content/zh/docs/concepts/scheduling/kube-scheduler.md +++ b/content/zh/docs/concepts/scheduling/kube-scheduler.md @@ -298,7 +298,7 @@ kube-scheduler 有一系列的默认调度策略。 - `TaintTolerationPriority`：基于 Pod 中对每个 Node 上污点容忍程度进行优先级评估，这个策略能够调整待选 Node 的排名。 -- `ImageLocalityPriority`：Node 上已经拥有Pod需要的 {{< glossary_tooltip text="container images" term_id="image" >}} 的 Node 会有较高的优先级。 +- `ImageLocalityPriority`：Node 上已经拥有Pod需要的 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 的 Node 会有较高的优先级。 - `ServiceSpreadingPriority`：这个调度策略的主要目的是确保将归属于同一个 Service 的 Pod 调度到不同的 Node 上。如果 Node 上 没有归属于同一个 Service 的 Pod，这个策略更倾向于将 Pod 调度到这类 Node 上。最终的目的：即使在一个 Node 宕机之后 Service 也具有很强容灾能力。 From 3bdddfa3351eb3986dac58d32c844a17e3d78493 Mon Sep 17 00:00:00 2001 From: senwang <841470897@qq.com> Date: Thu, 24 Oct 2019 09:19:27 +0800 Subject: [PATCH 3/6] Add Chinese translation for kube-scheduler --- .../docs/concepts/scheduling/kube-scheduler.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/zh/docs/concepts/scheduling/kube-scheduler.md b/content/zh/docs/concepts/scheduling/kube-scheduler.md index 587e21e73eeb0..092a531f7fe30 100644 --- a/content/zh/docs/concepts/scheduling/kube-scheduler.md +++ b/content/zh/docs/concepts/scheduling/kube-scheduler.md @@ -286,9 +286,9 @@ kube-scheduler 有一系列的默认调度策略。 - `MostRequestedPriority`：空闲资源比例越低的 Node 得分越高。这个调度策略将会把你所有的工作负载（Pod）调度到尽量少的 Node 上。 -- `RequestedToCapacityRatioPriority`：为每个 Node 资源使用比例设定得分值用来给资源打分函数使用。 +- `RequestedToCapacityRatioPriority`：为 Node 上每个资源占用比例设定得分值，给资源打分函数在打分时使用。 -- `BalancedResourceAllocation`：Node 上各种资源的占用比例越接近的 Node 越得分越高。 +- `BalancedResourceAllocation`：Node 上与调度有关的多种资源的占用比例越接近，得分越高。 - `NodePreferAvoidPodsPriority`：这个策略将根据 Node 的注解信息中是否含有 `scheduler.alpha.kubernetes.io/preferAvoidPods` 来 计算其优先级。使用这个策略可以将两个不同 Pod 运行在不同的 Node 上。 @@ -310,10 +310,10 @@ kube-scheduler 有一系列的默认调度策略。 {{% /capture %}} {{% capture whatsnext %}} -* Read about [scheduler performance tuning](/docs/concepts/scheduling/scheduler-perf-tuning/) -* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) -* Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler -* Learn about [configuring multiple schedulers](/docs/tasks/administer-cluster/configure-multiple-schedulers/) -* Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) -* Learn about [Pod Overhead](/docs/concepts/configuration/pod-overhead/) +* 阅读关于 [调度器性能调优](/docs/concepts/scheduling/scheduler-perf-tuning/) +* 阅读关于 [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* 阅读关于kube-scheduler的 [参考文档](/docs/reference/command-line-tools-reference/kube-scheduler/) +* 了解关于 [配置多个调度器](/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式 +* 了解关于 [topology management policies](/docs/tasks/administer-cluster/topology-manager/) +* 了解关于 [Pod Overhead](/docs/concepts/configuration/pod-overhead/) {{% /capture %}} From 47cdd0f1d5670801f97bbd15c7ad171447c31aa6 Mon Sep 17 00:00:00 2001 From: senwang <841470897@qq.com> Date: Thu, 24 Oct 2019 09:20:51 +0800 Subject: [PATCH 4/6] Update kube-scheduler.md --- content/zh/docs/concepts/scheduling/kube-scheduler.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/scheduling/kube-scheduler.md b/content/zh/docs/concepts/scheduling/kube-scheduler.md index 092a531f7fe30..2bfe985e9e592 100644 --- a/content/zh/docs/concepts/scheduling/kube-scheduler.md +++ b/content/zh/docs/concepts/scheduling/kube-scheduler.md @@ -312,7 +312,7 @@ kube-scheduler 有一系列的默认调度策略。 {{% capture whatsnext %}} * 阅读关于 [调度器性能调优](/docs/concepts/scheduling/scheduler-perf-tuning/) * 阅读关于 [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) -* 阅读关于kube-scheduler的 [参考文档](/docs/reference/command-line-tools-reference/kube-scheduler/) +* 阅读关于 kube-scheduler 的 [参考文档](/docs/reference/command-line-tools-reference/kube-scheduler/) * 了解关于 [配置多个调度器](/docs/tasks/administer-cluster/configure-multiple-schedulers/) 的方式 * 了解关于 [topology management policies](/docs/tasks/administer-cluster/topology-manager/) * 了解关于 [Pod Overhead](/docs/concepts/configuration/pod-overhead/) From 931b17471189ec5913b0c883647bec7bcc71f54a Mon Sep 17 00:00:00 2001 From: senwang <841470897@qq.com> Date: Thu, 24 Oct 2019 23:05:19 +0800 Subject: [PATCH 5/6] Update kube-scheduler.md --- content/zh/docs/concepts/scheduling/kube-scheduler.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/zh/docs/concepts/scheduling/kube-scheduler.md b/content/zh/docs/concepts/scheduling/kube-scheduler.md index 2bfe985e9e592..e2980ec23ebd6 100644 --- a/content/zh/docs/concepts/scheduling/kube-scheduler.md +++ b/content/zh/docs/concepts/scheduling/kube-scheduler.md @@ -81,7 +81,7 @@ functions to score the feasible Nodes and picks a Node with the highest score among the feasible ones to run the Pod. The scheduler then notifies the API server about this decision in a process called _binding_. --> -调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做绑定。 +调度器先在集群中找到一个 Pod 的所有可调度节点，然后根据一系列函数对这些可调度节点打分，然后选出其中得分最高的 Node 来运行 Pod。之后，调度器将这个调度决定通知给 kube-apiserver，这个过程叫做 _绑定_。