2020 kubernetes讲座（下）- （五）在Pod的Spec中配置调度

2020 kubernetes讲座（下）- （五）在Pod的Spec中配置调度

2. 在Pod的Spec中配置调度

大部分的调度策略可以作为Pod的Spec文件中的一部分来定义。一个Pod的Spec文件包含了相面几个字段可以影响调度的：

nodeNamenodeSelectoraffinityschedulerNametolerations

2.1. 配置的解释：

nodeName and nodeSelector

这个选项允许Pod被分配到特定node或者是一组拥有特定标签的node

affinity and anti-affinity

亲和性和反亲和性是说pod被调度的时候需要或者喜欢被分配到某个节点。如果使用了偏好，首先就需要在已经预选出来的节点中匹配，但是如果不存在匹配的节点，那么就会任意选择一个节点。

taints and tolerations

污点的使用允许对node进行标记，这样Pods就不会由于某些原因而被调度，比如初始化后的主节点。配置容忍度会让Pod忽略污点，并在满足其他要求的情况下进行调度。

schedulerName

如果上面的选项都不能满足集群的需要，那么还可以部署自定义调度程序。然后，每个Pod可以包含一个schedulerName来选择要使用的计划。

2.2. 节点选择器

pod规范中的nodeSelector字段提供了使用一个或多个键值对以node或一组node为调度目标的简单方法。

spec: containers: - name: redis image: redis nodeSelector: net: fast

配置nodeSelector会告诉调度器将pod放置在与标签匹配的节点上。必须满足所有列出的选择器，但节点可能有多个标签。在上面的例子中，任何键为net的node的配置为fast都是调度的候选节点。请记住，标签是管理员创建的标签，与实际资源没有关联。即使节点的网络可能很慢。

在找到具有匹配标签的节点之前，pod将保持挂起状态。

使用affinity/anti-affinity和nodeSelector的表达方式是一样的。

2.3. Pod Affinity Rules

如果位于同一个node，可以进行大量通信或共享数据的Pod可能运行得最好，这就是一种亲和力。为了获得更大的容错性，您可能希望Pods尽可能地分开，这就是反亲和力的。这些配置由调度器根据已经运行的pod的标签来决定。因此，调度器必须询问每个节点并跟踪正在运行的pod的标签。大于几百个节点的集群可能会出现显著的性能损失。Pod关联规则使用In、NotIn、Exists和DoesNotExist运算符。

Pod Affinity规则

requiredDuringSchedulingIgnoredDuringExecution

表示除非下面operator的值为true，否则Pod就不会运行在这里。即使operator将来变成了false，pod也会继续在这个节点上运行。我们可以认为这是一个硬性规定

preferredDuringSchedulingIgnoredDuringExecution

和上面相同，调度器会选择一个最好有下面配置的节点。如果没有节点拥有匹配的标签，pod也会被调度到没有配置的节点。这是一个相对不那么强烈的要求，所以说前缀是preferred，而不是require。

podAffinity

使用Pod的亲和性，调度器会把Pod调度到一起

podAntiAffinity

这个会让调度器去保证pod运行在不同的节点

podAffinity的例子

亲和性和pod亲和性的配置，我们看下面的例子。这个同样需要在pod启动的时候给出一个特殊的标签，但是这个标签即使在后面被删除了也没有关系。

spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - S1 topologyKey: topology.kubernetes.io/zone

podAntiAffinity的例子

使用podAntiAffinity，我们可以防止pod被调度到拥有摸个特定标签的节点上。从这个角度来说，调度器会倾向于避开label的名字为security并且值包含S2的节点。

podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: security operator: In values: - S2 topologyKey: kubernetes.io/hostname

2.4. Node Affinity规则

Where Pod affinity/anti-affinity has to do with other Pods, the use of nodeAffinity allows Pod scheduling based on node labels. This is similar and will some day replace the use of the nodeSelector setting. The scheduler will not look at other Pods on the system, but the labels of the nodes. This should have much less performance impact on the cluster, even with a large number of nodes.

Uses In, NotIn, Exists, DoesNotExist operatorsrequiredDuringSchedulingIgnoredDuringExecutionpreferredDuringSchedulingIgnoredDuringExecutionPlanned for future: requiredDuringSchedulingRequiredDuringExecution.

Until nodeSelector has been fully deprecated, both the selector and required labels must be met for a Pod to be scheduled.

2.5. Node Affinity例子

spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/colo-tx-name operator: In values: - tx-aus - tx-dal preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: disk-speed operator: In values: - fast - quick

第一个nodeAffinity规则需求节点的key是kubernetes.io/colo-tx-name并且值是tx-aus 或者 tx-dal.

第二个规则给出了额外的节点的权重，并且disk-speed的值是fast 或者 quick. Pod会被调度到相同的节点之上。但是为了防止意外，这个配置只是倾向于一个拥有特定标签的节点。