From 22ddf4f82e7052bb64ff041822b92d6d88313d2e Mon Sep 17 00:00:00 2001 From: yuanhao Date: Tue, 22 Sep 2020 22:32:45 +0800 Subject: [PATCH] translate content/zh/docs/reference/scheduling/policies.md --- .../zh/docs/reference/scheduling/_index.md | 5 + .../zh/docs/reference/scheduling/policies.md | 233 ++++++++++++++++++ 2 files changed, 238 insertions(+) create mode 100644 content/zh/docs/reference/scheduling/_index.md create mode 100644 content/zh/docs/reference/scheduling/policies.md diff --git a/content/zh/docs/reference/scheduling/_index.md b/content/zh/docs/reference/scheduling/_index.md new file mode 100644 index 0000000000..438ac7ede3 --- /dev/null +++ b/content/zh/docs/reference/scheduling/_index.md @@ -0,0 +1,5 @@ +--- +title: 调度 +weight: 70 +toc-hide: true +--- diff --git a/content/zh/docs/reference/scheduling/policies.md b/content/zh/docs/reference/scheduling/policies.md new file mode 100644 index 0000000000..248e3a7f84 --- /dev/null +++ b/content/zh/docs/reference/scheduling/policies.md @@ -0,0 +1,233 @@ +--- +title: 调度策略 +content_type: concept +weight: 10 +--- + + + + + +{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} +根据调度策略指定的*断言(predicates)*和*优先级(priorities)* +分别对节点进行[过滤和打分](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 + + +你可以通过执行 `kube-scheduler --policy-config-file ` 或 +`kube-scheduler --policy-configmap ` +设置并使用[调度策略](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)。 + + + + + +## 断言 {#predicates} + + + +以下*断言*实现了过滤接口: + + +- `PodFitsHostPorts`:检查 Pod 请求的端口(网络协议类型)在节点上是否可用。 + + +- `PodFitsHost`:检查 Pod 是否通过主机名指定了 Node。 + + +- `PodFitsResources`:检查节点的空闲资源(例如,CPU和内存)是否满足 Pod 的要求。 + + +- `MatchNodeSelector`:检查 Pod 的节点{{< glossary_tooltip text="选择算符" term_id="selector" >}} + 和节点的 {{< glossary_tooltip text="标签" term_id="label" >}} 是否匹配。 + + +- `NoVolumeZoneConflict`:给定该存储的故障区域限制, + 评估 Pod 请求的{{< glossary_tooltip text="卷" term_id="volume" >}}在节点上是否可用。 + + +- `NoDiskConflict`:根据 Pod 请求的卷是否在节点上已经挂载,评估 Pod 和节点是否匹配。 + + +- `MaxCSIVolumeCount`:决定附加 {{< glossary_tooltip text="CSI" term_id="csi" >}} 卷的数量,判断是否超过配置的限制。 + + +- `CheckNodeMemoryPressure`:如果节点正上报内存压力,并且没有异常配置,则不会把 Pod 调度到此节点上。 + + +- `CheckNodePIDPressure`:如果节点正上报进程 ID 稀缺,并且没有异常配置,则不会把 Pod 调度到此节点上。 + + +- `CheckNodeDiskPressure`:如果节点正上报存储压力(文件系统已满或几乎已满),并且没有异常配置,则不会把 Pod 调度到此节点上。 + + +- `CheckNodeCondition`:节点可用上报自己的文件系统已满,网络不可用或者 kubelet 尚未准备好运行 Pod。 + 如果节点上设置了这样的状况,并且没有异常配置,则不会把 Pod 调度到此节点上。 + + +- `PodToleratesNodeTaints`:检查 Pod 的{{< glossary_tooltip text="容忍" term_id="toleration" >}} + 是否能容忍节点的{{< glossary_tooltip text="污点" term_id="taint" >}}。 + + +- `CheckVolumeBinding`:基于 Pod 的卷请求,评估 Pod 是否适合节点,这里的卷包括绑定的和未绑定的 + {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} 都适用。 + + + +## 优先级 {#priorities} + + +以下*优先级*实现了打分接口: + + +- `SelectorSpreadPriority`:属于同一 {{< glossary_tooltip text="Service" term_id="service" >}}、 + {{< glossary_tooltip term_id="statefulset" >}} 或 + {{< glossary_tooltip term_id="replica-set" >}} 的 Pod,跨主机部署。 + + +- `InterPodAffinityPriority`:实现了 [Pod 间亲和性与反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)的优先级。 + + +- `LeastRequestedPriority`:偏向最少请求资源的节点。 + 换句话说,节点上的 Pod 越多,使用的资源就越多,此策略给出的排名就越低。 + + +- `MostRequestedPriority`:支持最多请求资源的节点。 + 该策略将 Pod 调度到整体工作负载所需的最少的一组节点上。 + + +- `RequestedToCapacityRatioPriority`:使用默认的打分方法模型,创建基于 ResourceAllocationPriority 的 requestedToCapacity。 + + +- `BalancedResourceAllocation`:偏向平衡资源使用的节点。 + + +- `NodePreferAvoidPodsPriority`:根据节点的注解 `scheduler.alpha.kubernetes.io/preferAvoidPods` 对节点进行优先级排序。 + 你可以使用它来暗示两个不同的 Pod 不应在同一节点上运行。 + + +- `NodeAffinityPriority`:根据节点亲和中 PreferredDuringSchedulingIgnoredDuringExecution 字段对节点进行优先级排序。 + 你可以在[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)中了解更多。 + + +- `TaintTolerationPriority`:根据节点上无法忍受的污点数量,给所有节点进行优先级排序。 + 此策略会根据排序结果调整节点的等级。 + + +- `ImageLocalityPriority`:偏向已在本地缓存 Pod 所需容器镜像的节点。 + + +- `ServiceSpreadingPriority`:对于给定的 Service,此策略旨在确保该 Service 关联的 Pod 在不同的节点上运行。 + 它偏向把 Pod 调度到没有该服务的节点。 + 整体来看,Service 对于单个节点故障变得更具弹性。 + + +- `EqualPriority`:给予所有节点相等的权重。 + + +- `EvenPodsSpreadPriority`:实现了 [Pod 拓扑扩展约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)的优先级排序。 + + + +## {{% heading "whatsnext" %}} + + +* 了解[调度](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) +* 了解 [kube-scheduler 配置](/zh/docs/reference/scheduling/config/) \ No newline at end of file