目录
一、K8S调度
调度器通过kubernetes的list-watch机制来发现集群中新创建且尚未被调度到Node上的Pod。调度器会将发现的每一个未调度的Pod调度到一个合适的Node上来运行。
kube-scheduler是Kubernetes集群的默认调度器,并且是集群控制面的一部分。如果你真的希望或者有这方面的需求,kube-scheduler在设计上是允许你自己写一个调度组件并替换原有的kube-scheduler。
在做调度决定时需要考虑的因素包括:单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。
二、亲和与反亲和
1.pod和node
一般情况下,我们部署的pod是通过的自动调度策略来选择节点的,默认情况下调度器考虑的是资源足够,并且负载尽量平衡,但是有的时候需要能够更加细粒度的去控制Pod的调度,比如我们内部的一些服务gitlab 之类的也是跑在kubernetes集群上的,我们就不希望对外的的一些服务和内部的服务跑在同一节点上了,担心内部服务对外部服务产生影响;但是有的时候我们的服务之间交流比较频繁,有希望能够将这两个服务的pod调度到同一节点上,这就需要用到kubernetes李面的一个概念:亲和性和反亲和性。
亲和性有分为节点亲和性(nodeAffinity和nodeAntiAffinity)和pod亲和性(podAffinity和podAntiAffinity)
亲和性,in代表要调度到有这个标签的位置
反亲和性,in代表不要调度到有这个标签的位置
2.硬亲和和软亲和
preferredDuringSchedulingIgnoredDuringExecution 软亲和
软策略:意思就是尽量不要讲pod调度到匹配到的节点,但是如果没有不匹配的节点的话,也可以调度到匹配到的节点。
requiredDuringSchedulingIgnoredDuringExecution 硬亲和
硬策略:意思就是必须调度到满足条件的节点上,否则就会pending。
不管是使用那种方式,最终还是要依赖label标签
kubectl get pods -n company ai-action-statistic-gray-86465f9c4b-hdfk4 -oyaml | grep nodeSelector -B 5 -A 5
uid: ed47f094-f70a-45ed-b7dd-d46f2d01986f
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution: 硬策略
nodeSelectorTerms:
- matchExpressions:
- key: node-role.kubernetes.io/gray
operator: In
values:
- gray
preferredDuringSche