Kubernetes 设计模式笔记 —— Automated Placement

Automated Placement 是 Kubernetes 中 scheduler 的核心功能，负责将新的 Pod 分配给合适的节点，满足容器的资源需求，同时遵守设定好的调度策略。

基于微服务的系统通常会包含数十个甚至数百个隔离的进程，容器和 Pod 为它们提供了很好的打包和部署机制，但并没有解决将众多的进程分配给适当的节点这项工作。
容器之间存在依赖关系，有些还需要关联到特定的节点，容器自身也有一定的资源需求。这些都会随着时间发生变化。同时集群本身的资源也不是恒定的，它会执行缩容或者扩容，其特定时刻下的容量也取决于已经放置的容器数量。
这些因素都会左右容器的调度。

Available Node Resources

首先需要考虑的就是节点上是否有足够的可用资源。Scheduler 会确保 Pod 申请的资源总和小于可分配节点上的可用容量。节点可用容量的计算公式：

Allocatable [capacity for application pods] =
    Node Capacity [available capacity on a node]
        - Kube-Reserved [Kubernetes daemons like kubelet, container runtime]
        - System-Reserved [OS system daemons like sshd, udev]

Container Resource Demands

Pod 在调度时，另一个重要的考虑因素就是容器有着自己的运行时依赖和资源需求。
比如：

apiVersion: v1
kind: Pod
metadata:
  name: random-generator
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
      limits:
        cpu: 200m
        memory: 200Mi

Placement Policies

Scheduler 配置了一组默认的优先级策略，适用于绝大多数场景。这个策略可以在 scheduler 启动时被替换掉。

scheduler 策略示例：

{
    "kind" : "Policy",
    "apiVersion" : "v1",
    "predicates" : [
        {"name" : "PodFitsHostPorts"},
        {"name" : "PodFitsResources"},
        {"name" : "NoDiskConflict"},
        {"name" : "NoVolumeZoneConflict"},
        {"name" : "MatchNodeSelector"},
        {"name" : "HostName"}
    ],
    "priorities" : [
        {"name" : "LeastRequestedPriority", "weight" : 2},
        {"name" : "BalancedResourceAllocation", "weight" : 1},
        {"name" : "ServiceSpreadingPriority", "weight" : 2},
        {"name" : "EqualPriority", "weight" : 1}
    ]
}

其中 Predicate 规则用于过滤掉不合格的节点。比如 PodFitsHostsPorts 关注特定的固定主机端口，只有在这些端口可用时对应的节点才会作为候选。
Priorities 用于根据一些偏好设置来对候选的节点进行排序。比如 LeastRequestedPriority 会赋予请求了较少资源的节点更高的优先级。

可以同时运行多个 scheduler，让 Pod 自己去指定使用哪一个。只需要在 Pod 的配置中添加一条 .spec.schedulerName，其值为自定义 scheduler 的名字。

调度流程

A Pod-to-node assignment

只要 Pod 创建完成且还没有被分配给任何节点，scheduler 就会挑选出该 Pod，连同所有可用的节点及优先级策略。第一阶段借助过滤策略移除所有不满足要求的节点，剩余的节点在第二阶段有权重地排序。最后一个阶段得到最终的胜出节点。

在绝大多数情况下，最好都只让 scheduler 去做 Pod-to-Node 的分配工作，不要去尝试“微操”调度逻辑。
在某些特殊场景下，如果需要强制某个 Pod 只能分配给特定的一个或一组节点，可以借助 Pod 的 .spec.nodeSelector 字段。
该字段可以指定一些键值对，对应节点身上的标签。比如想要 Pod 运行在拥有 SSD 磁盘的硬件上：

apiVersion: v1
kind: Pod
metadata:
  name: random-generator
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
  nodeSelector:
    disktype: ssd

除了通过自定义标签指定节点，还可以通过每个节点上都有的默认标签来筛选，比如 kubernetes.io/hostname。

Node Affinity

Kubernetes 还支持更为灵活的配置调度流程的方式，比如 node affinity。其实它相当于 nodeSelector 机制的泛化，其规则可以被指定为“必需”或者“优先”。
“必需”表示相应的规则必须被满足，否则节点无法作为候选；“优先”则并不强制，只是提高匹配节点的权重。
此外，node affinity 支持多种操作符，如 In、NotIn、Exists、DoesNotExist、Gt、Lt 等，从而获得更强的表达能力。

apiVersion: v1
kind: Pod
metadata:
  name: random-generator
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: numberCores
            operator: Gt
            values: [ "3" ]
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchFields:
          - key: metadata.name
            operator: NotIn
            values: [ "master" ]
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator

其中 requiredDuringSchedulingIgnoredDuringExecution 用来指定节点必须具备的条件，此规则不会在执行过程中重新计算。结合后面的 nodeSelectorTerms 配置，筛选出核心数大于 3 的节点。
preferredDuringSchedulingIgnoredDuringExecution 用于指定非必须的条件，表现为一个带有权重的 selector 列表。对于每一个节点，计算出所有匹配项的权重总和，结果最高的节点被选中，只要该节点已经满足了前面的“必需”条件。

PS：matchFields 只支持 In 和 NotIn 操作符，values 指定的列表中也只允许有一个值。

诚然，node affinity 相比于 nodeSelector 功能更为强大。它允许通过标签或者字段为 Pod 选择合适的节点，但不能够用来表达 Pod 之间的依赖关系，比如无法根据某个节点上已经部署的 Pod 判断某个新 Pod 是否也应该部署到该节点。这类需求可以通过 Pod affinity 实现。

Pod Affinity

Node affinity 工作在节点层级上，Pod affinity 则可以在多个拓扑层级上表达规则，达到粒度更细的控制。

apiVersion: v1
kind: Pod
metadata:
  name: random-generator
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            confidential: high
        topologyKey: security-zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              confidential: none
          topologyKey: kubernetes.io/hostname
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator

其中 podAffinity 部分的配置表示，符合条件的节点上必须有带有 confidential=high 标签的 Pod 在运行，且该节点有 security-zone 标签。
podAntiAffinity 定义的规则用于过滤掉匹配的节点。结合其配置，即节点上有带 confidential=none 标签的 Pod 在运行时，该节点不会用来部署当前 Pod。

Taints and Tolerations

Taints 和 Tolerations 是一类更高级的用于控制调度策略的特性。简单来说，node affinity 允许 Pod 根据规则选择合适的节点，taints 和 tolerations 则正相反，它允许节点自身去控制 Pod 是否应该分配给自己。
Taint 是节点自身的一种属性，当它存在时，会阻止 Pod 分配给自己，除非该 Pod 拥有针对 taint 的 tolerations。

Taint 可以使用 kubectl 命令添加。如 kubectl taint nodes master noderole.kubernetes.io/master="true":NoSchedule，等效于下面的配置。

Tainted 节点：

apiVersion: v1
kind: Node
metadata:
  name: master
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master

拥有此 taint 的节点不会被分配任何 Pod，除非有 Pod 指定了对应的 toleration。比如：

apiVersion: v1
kind: Pod
metadata:
  name: random-generator
spec:
  containers:
  - image: k8spatterns/random-generator:1.0
    name: random-generator
  tolerations:
  - key: node-role.kubernetes.io/master
    operator: Exists
    effect: NoSchedule

在生产级别的集群中，带有 noderole.kubernetes.io/master 配置的 taint 一般会指定给 master 节点，阻止 Pod 部署到 master 上。
这里给 Pod 添加的 toleration 会覆盖 taint 的 NoSchedule 效果，即无论如何都允许此 Pod 分配给 master 节点。

Taint 可以是硬性的，阻止节点作为候选（effect=NoSchedule），也可以是软性的，尝试避免节点作为候选（effect=PreferNoSchedule），还可以强制移除节点上已经在运行的 Pod（effect=NoExecute）。

当 Pod 已经分配给某个节点，scheduler 的工作就已经算完成了，它不会再对完成的分配进行调整。除非该 Pod 被删除或者重建。随着时间的推移，这一定会导致资源的碎片化，集群利用率降低。
另一个潜在的问题是，Pod 被创建后具体分配给哪一个节点，依赖于当时集群的状态。而集群本身是动态的，节点的资源配置会更改，或者有新的节点加入进来，scheduler 并不会纠正已经存在的部署。此外，节点上的标签也有可能会变动，影响到之后的调度，但之前已经完成的调度依旧保持不变。

以上所有的场景都可以通过 descheduler 去解决。Kubernetes 的 descheduler 是一个可选的特性，通常作为 Job 执行，当管理员觉得是时候通过重新调度 Pod 来整理集群的碎片。
Descheduler 有一些预先定义的策略，可以被启用或者禁用：

RemoveDuplicates：该策略会确保 ReplicaSet 或 Deployment 关联的单一 Pod 只运行在唯一一个节点上。当某个节点不健康时，controller 会在其他健康的节点上启动新的 Pod。此时若之前不健康的节点恢复正常重新加入集群，正在运行的 Pod 就会大于需要的数量。此策略就可以应用于这类的场景。同时 RemoveDuplicates 还可以在策略或集群架构发生变化后，将 Pod 更均匀地分散在更多的节点上
LowNodeUtilization：该策略会找到使用率低的节点，并将高使用率节点上的 Pod 移除掉，希望这些移除的 Pod 可以重新分配到未充分利用的节点上。使用率低指 CPU、内存或 Pod 数量小于 thresholds 配置；使用率高指的是 CPU、内存或 Pod 数量大于 targetThresholds 配置
RemovePodsViolatingInterPodAntiAffinity：该策略会移除违反了 pod antiaffinity 规则的 Pod。这种情况可能发生在，添加规则时一些不符合规则的 Pod 就已经存在了
RemovePodsViolatingNodeAffinity：移除违反了 node affinity 规则的 Pod

不管使用何种配置的策略，descheduler 会避免移除如下类型的 Pod：

在 annotation 中标记为 scheduler.alpha.kubernetes.io/criticalpod 的关键 Pod
不由 ReplicaSet、Deployment 或 Job 管理的 Pod
由 DaemonSet 管理的 Pod
拥有本地存储的 Pod
配置了 PodDisruptionBudget 的 Pod，且移除时会违反此规则
Descheduler Pod 本身

总结

容器调度是一个我们希望尽可能少干预的领域。从简单到复杂，以下方法控制着调度的具体策略：

nodeName：最简单的分配方式，将 Pod 到节点的关系硬编码到配置中。理想的情况下，此字段应该由 scheduler 填充，策略去驱动，而不是手动指定
nodeSelector：键值对映射。符合条件的节点必须包含此键值对指向的标签。在控制调度策略的可接受的方式中，最简单的一种
Default scheduling alteration：必要的情况下，可以修改 default scheduler 的过滤规则和优先级策略、顺序、权重等
Pod affinity 和 antiaffinity：此机制允许 Pod 表达自身对其他 Pod 的依赖关系
Node affinity：允许 Pod 表达自身对节点的依赖关系，比如节点的硬件配置、地理位置等
Taints 和 tolerations：允许节点去控制哪些 Pod 允许哪些不允许分配给自己。比如为一组 Pod 分配一个专用节点，甚至在运行时移除 Pod
Custom scheduler：若上述方案都不能符合需求，还可以编写自定义的 scheduler。自定义 scheduler 可以替换掉标准的 Kubernetes scheduler，也可以两者一起运行

参考资料

Kubernetes Patterns