K8s 高级调度

K8s 高级调度

CronJob

在 k8s 中周期性运行计划任务，与 linux 中的 crontab 相同

注意点：CronJob 执行的时间是 controller-manager 的时间，所以一定要确保 controller-manager 时间是准确的，另外 cronjob

apiVersion: batch/v1
kind: CronJob
metadata:name: cron-job-test
spec:concurrencyPolicy: Allow # 并发调度策略：Allow 允许并发调度，Forbid：不允许并发执行，Replace：如果之前的任务还没执行完，就直接执行新的，放弃上一个任务failedJobsHistoryLimit: 1 # 保留多少个失败的任务successfulJobsHistoryLimit: 3 # 保留多少个成功的任务suspend: falsestartingDeadlineSeconds: 30 # 间隔多长时间检测失败的任务并重新执行，时间不能小于 10schedule: "* * * * *" # 调度策略jobTemplate:spec:template:spec:containers:- name: cron-jobimage: busybox:1.28imagePullPolicy: IfNotPresentcommand:- /bin/sh- -c- date; echo Hello from the Kubernetes clusterrestartPolicy: OnFailure

initContainer

在真正的容器启动之前，先启动 InitContainer，在初始化容器中完成真实容器所需的初始化操作，完成后再启动真实的容器。

相对于 postStart 来说，首先 InitController 能够保证一定在 EntryPoint 之前执行，而 postStart 不能，其次 postStart 更适合去执行一些命令操作，而 InitController 实际就是一个容器，可以在其他基础容器环境下执行更复杂的初始化功能。

# 在 pod 创建的模板中配置 initContainers 参数：
spec:initContainers:- image: nginximagePullPolicy: IfNotPresentcommand: ["sh", "-c", "echo 'inited;' >> ~/.init"]name: init-test

Taint 和 Toleration

k8s 集群中可能管理着非常庞大的服务器，这些服务器可能是各种各样不同类型的，比如机房、地理位置、配置等，有些是计算型节点，有些是存储型节点，此时我们希望能更好的将 pod 调度到与之需求更匹配的节点上。

此时就需要用到污点（Taint）和容忍（Toleration），这些配置都是 key: value 类型的。

官网地址

污点（Taint）

污点：是标注在节点上的，当我们在一个节点上打上污点以后，k8s 会认为尽量不要将 pod 调度到该节点上，除非该 pod 上面表示可以容忍该污点，且一个节点可以打多个污点，此时则需要 pod 容忍所有污点才会被调度该节点。

# 为节点打上污点
kubectl taint node k8s-master key=value:NoSchedule# 移除污点
kubectl taint node k8s-master key=value:NoSchedule-节点名称   污点的k，v  污点描述    - 删除# 查看污点
kubectl describe no k8s-master污点的描述：
NoSchedule：不能容忍的 pod 不能被调度到该节点，但是已经存在的节点不会被驱逐
NoExecute：不能容忍的节点会被立即清除，能容忍且没有配置 tolerationSeconds 属性，则可以一直运行，设置了 tolerationSeconds: 3600 属性，则该 pod 还能继续在该节点运行 3600 秒
PreferNoSchedule：尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度

容忍（Toleration）

容忍：是标注在 pod 上的，当 pod 被调度时，如果没有配置容忍，则该 pod 不会被调度到有污点的节点上，只有该 pod 上标注了满足某个节点的所有污点，则会被调度到这些节点

污点就是拒绝，容忍就是忽略，Node通过污点拒绝pod调度上去，Pod通过容忍忽略拒绝

# pod 的 spec 下面配置容忍
tolerations:
- key: "污点的 key"value: "污点的 value"offect: "NoSchedule" # 污点产生的影响operator: "Equal" # 表是 value 与污点的 value 要相等，也可以设置为 Exists 表示存在 key 即可，此时可以不用配置 value

Affinity

NodeAffinity

节点亲和力：进行 pod 调度时，优先调度到符合条件的亲和力节点上

• requiredDuringSchedulingIgnoredDuringExecution： 调度器只有在规则被满足的时候才能执行调度。此功能类似于 nodeSelector， 但其语法表达能力更强。
• preferredDuringSchedulingIgnoredDuringExecution： 调度器会尝试寻找满足对应规则的节点。如果找不到匹配的节点，调度器仍然会调度该 Pod。

apiVersion: v1
kind: Pod
metadata:name: with-node-affinity
spec:affinity: # 亲和力配置nodeAffinity: # 节点亲和力requiredDuringSchedulingIgnoredDuringExecution: # 节点必须匹配下方配置nodeSelectorTerms: # 选择器- matchExpressions: # 匹配表达式- key: topology.kubernetes.io/zone # 匹配 label 的 keyoperator: In # 匹配方式，只要匹配成功下方的一个 value 即可values:- antarctica-east1 # 匹配的 value- antarctica-west1 # 匹配的 valuepreferredDuringSchedulingIgnoredDuringExecution: # 节点尽量匹配下方配置- weight: 1 # 权重[1,100]，按照匹配规则对所有节点累加权重，最终之和会加入优先级评分，优先级越高被调度的可能性越高preference:matchExpressions: # 匹配表达式- key: another-node-label-key # label 的 keyoperator: In # 匹配方式，满足一个即可values:- another-node-label-value # 匹配的 value
#      - weight: 20......containers:- name: with-node-affinityimage: pause:2.0

在这一示例中，所应用的规则如下：

• 节点必须包含一个键名为 topology.kubernetes.io/zone 的标签， 并且该标签的取值必须为 antarctica-east1 或 antarctica-west1。
• 节点最好具有一个键名为 another-node-label-key 且取值为 another-node-label-value 的标签。

你可以使用 operator 字段来为 Kubernetes 设置在解释规则时要使用的逻辑操作符。 你可以使用 In、NotIn、Exists、DoesNotExist、Gt 和 Lt 之一作为操作符。 详情可以参考官网

补充：如果你同时指定了 nodeSelector 和 nodeAffinity，两者必须都要满足， 才能将 Pod 调度到候选节点上。

如果你在与 nodeAffinity 类型关联的 nodeSelectorTerms 中指定多个条件， 只要其中一个 nodeSelectorTerms 满足（各个条件按逻辑或操作组合）的话，Pod 就可以被调度到节点上。

如果你在与 nodeSelectorTerms 中的条件相关联的单个 matchExpressions 字段中指定多个表达式， 则只有当所有表达式都满足（各表达式按逻辑与操作组合）时，Pod 才能被调度到节点上。

PodAnffinity 和 PodAntiAffinity

PodAnffinity ：Pod 亲和力将与指定 pod 亲和力相匹配的 pod 部署在同一节点。

PodAntiAffinity： Pod 反亲和力 根据策略尽量部署或不部署到一块

Pod 的亲和性与反亲和性也有两种类型：

• requiredDuringSchedulingIgnoredDuringExecution
• preferredDuringSchedulingIgnoredDuringExecution

apiVersion: v1
kind: Pod
metadata:name: with-pod-affinity
spec:affinity: # 亲和力配置podAffinity: # pod 亲和力配置requiredDuringSchedulingIgnoredDuringExecution: # 当前 pod 必须匹配到对应条件 pod 所在的 node 上- labelSelector: # 标签选择器matchExpressions: # 匹配表达式- key: security # 匹配的 keyoperator: In # 匹配方式values: # 匹配其中的一个 value- S1topologyKey: topology.kubernetes.io/zonepodAntiAffinity: # pod 反亲和力配置preferredDuringSchedulingIgnoredDuringExecution: # 尽量不要将当前节点部署到匹配下列参数的 pod 所在的 node 上- weight: 100 # 权重podAffinityTerm: # pod 亲和力配置条件labelSelector: # 标签选择器matchExpressions: # 匹配表达式- key: security # 匹配的 keyoperator: In # 匹配的方式values:- S2 # 匹配的 valuetopologyKey: topology.kubernetes.io/zonecontainers:- name: with-pod-affinityimage: pause:2.0

总结

默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，我们想控制某些Pod到达某些节点上，就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式：

**自动调度：**运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
**定向调度：**NodeName、NodeSelector
**亲和性调度：**NodeAffinity、PodAffinity、PodAntiAffinity
**污点（容忍）调度：**Taints、Toleration